Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering  (Read 389554 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37626
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #675 on: September 05, 2019, 05:06:05 am »
I'm trying to buy the parts from the BOM file in the github and it seems it's for LCSC, but when I load the CSV into LCSC using their BOM tool it's just a mess.
Anyone know why?
It is because it's semicolon delimited instead of coma delimited?
Thanks.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37626
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #676 on: September 05, 2019, 05:13:57 am »
I'm trying to buy the parts from the BOM file in the github and it seems it's for LCSC, but when I load the CSV into LCSC using their BOM tool it's just a mess.
Anyone know why?
It is because it's semicolon delimited instead of coma delimited?
Thanks.

I downloaded the LCSC BOm template and manually copied everything over and it's still a mess when I import it into LCSC  |O

Turns out there is a bug in the LCSC BOM. It re-loads the previous (incorrect) file even when you try and upload a new one. You have to restart the web page.

XLS BOM attached in LCSC format
« Last Edit: September 05, 2019, 05:41:08 am by EEVblog »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #677 on: September 05, 2019, 12:11:04 pm »
I downloaded the LCSC BOm template and manually copied everything over and it's still a mess when I import it into LCSC  |O

Turns out there is a bug in the LCSC BOM. It re-loads the previous (incorrect) file even when you try and upload a new one. You have to restart the web page.

XLS BOM attached in LCSC format

Hi,

Thanks for bringing this up. Looks like export/import from EasyEDA / LCSC is language dependent (my language uses semicolons in CSVs, so maybe that's why it was working for me).

I added your excel file to the github repository. This should be always working now.


For simplicity I suggest that you order a SOP socket (keep an eye on the spacing of the pin headers, some are narrow, some are wide).
This one should work: https://www.aliexpress.com/item/32890300159.html

This can be used with all SOP versions of PMC150C / PFS154 / PFS173 / ... and fits directly on top of the programmer.

Have fun,

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #678 on: September 05, 2019, 01:10:45 pm »
JS I made progress! I have soldered a 8MHz crystal to the board and now it can Erase the part ok, But when I read it, it says "Could not read data from programmer"
 |O |O


what should I do?
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #679 on: September 05, 2019, 05:27:13 pm »
JS I made progress! I have soldered a 8MHz crystal to the board and now it can Erase the part ok, But when I read it, it says "Could not read data from programmer"

Hi,

It already looks very good!
The read command already executed correctly ("Reading IC... done."). This means the programmer was able to read out the IC into its internal buffer.

The error you get is from USB communication only. The command to get the data from programmer back to your PC failed for some reason (it just sends more data then the previous commands).

Did USB disconnect in this moment (observe in device manager if device disappears when you do the read).
If so, I would suggest to inspect the 8MHz crystal soldering and the 2 small caps next to the crystal. USB is very picky with the 48MHz bus clock speed and possible drifts.

Another possibility could be a bad USB cable / bad USB hub / ... Easiest way to find out is to connect the programmer directly to the computer and / or try it on another computer. Then you know it is either the programmer or something else.

EDIT: A friend of mine reported the same problem on Windows 10... I will have a look later. Maybe your programmer works correct already.


You are almost there.

Update: I was able to reproduce the problem and added a fix for Windows. New development version (and release) will not give this strange error anymore:

https://github.com/free-pdk/easy-pdk-programmer-software/releases

JS
« Last Edit: September 05, 2019, 11:13:48 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #680 on: September 07, 2019, 05:51:58 am »
Dear JS, Thanks for your help and support, big thumbs up :-+
Now it's working, my Design did not have any problem, it was just not soldering the crystal, so you can now add my Altium files to the repo if you want ;)

Also Now is the time to do some programming...

how to get started with SDCC for PFS173, I see your examples and they are for PFS154, is there something that I should change?
« Last Edit: September 07, 2019, 05:56:34 am by ali_asadzadeh »
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #681 on: September 07, 2019, 06:14:32 am »
how to get started with SDCC for PFS173, I see your examples and they are for PFS154, is there something that I should change?

Despite having -pfs154 in the name, both hello-pfs154 and count-pfs154 are written to work on both: When using sdcc -mpdk14 they get compiled for PFS154, when using sdcc -mpdk15 they get compiled for PFS173.

Philipp
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #682 on: September 07, 2019, 07:51:37 am »
Thanks, I have done two project successfuly, JS I think I have found another bug in the PC software

I have modified the Hello example to output the UART on the PA.7 port, so after starting easypdkprog, it should capture the UART data, it can not get the UART data for now, But I have connected an external UART Bridge(FT230x) to it and it's putting data on the line,


here is the Modified code for PFS173.

Code: [Select]
// "Hello, world!" for the Padauk PFS154, to be compiled with SDCC.
// Repeatedly outputs the string "Hello, World!" at 9600 baud on pin 0 of Port A.
// Written by Philipp Klaus Krause in 2019.
// Source code under CC0 1.0.

// Output on PA0 at 1200 baud.

#include <stdbool.h>
#include <stdio.h>

volatile unsigned char sendcounter;
volatile unsigned int senddata;
volatile bool sending;

//PFS173 SFR's
__sfr __at(0x00) flag;
__sfr __at(0x02) sp;
__sfr __at(0x03) clkmd;
__sfr __at(0x04) inten;
__sfr __at(0x05) intrq;
__sfr __at(0x06) t16m;
__sfr __at(0x0a) eoscr;
__sfr __at(0x0b) ihrcr;
__sfr __at(0x0c) integs;
__sfr __at(0x0d) padier;
__sfr __at(0x0e) pbdier;
__sfr __at(0x0f) pcdier;
__sfr __at(0x10) pa;
__sfr __at(0x11) pac;
__sfr __at(0x12) paph;
__sfr __at(0x13) pb;
__sfr __at(0x14) pbc;
__sfr __at(0x15) pbph;
__sfr __at(0x16) pc;
__sfr __at(0x17) pcc;
__sfr __at(0x18) pcph;
__sfr __at(0x19) pbpl;
__sfr __at(0x1a) pcpl;
__sfr __at(0x20) adcc;
__sfr __at(0x21) adcm;
__sfr __at(0x22) adcr;
__sfr __at(0x24) adcrgc;
__sfr __at(0x26) misc;
__sfr __at(0x2b) gpcc;
__sfr __at(0x2c) gpcs;
__sfr __at(0x30) tm2c;
__sfr __at(0x31) tm2ct;
__sfr __at(0x32) tm2s;
__sfr __at(0x33) tm2b;
__sfr __at(0x34) tm3c;
__sfr __at(0x35) tm3ct;
__sfr __at(0x36) tm3s;
__sfr __at(0x37) tm3b;
__sfr __at(0x40) pwmg0c;
__sfr __at(0x41) pwmgclk;
__sfr __at(0x42) pwmg0dth;
__sfr __at(0x43) pwmg0dtl;
__sfr __at(0x44) pwmgcubh;
__sfr __at(0x45) pwmgcubl;
__sfr __at(0x46) pwmg1c;
__sfr __at(0x48) pwmg1dth;
__sfr __at(0x49) pwmg1dtl;
__sfr __at(0x4c) pwmg2c;
__sfr __at(0x4e) pwmg2dth;
__sfr __at(0x4f) pwmg2dtl;

void send_bit(void) __interrupt(0)
{
// Reset interrupt request, proceed only if we had a timer interrupt.
if(!(intrq & 0x40))
{
intrq = 0x00;
return;
}
intrq = 0x00;

if(!sending)
return;

if(senddata & 1)
pa = 0x80;
else
pa = 0x00;

senddata >>= 1;

if(!--sendcounter)
{
sending = false;

inten &= ~0x40;
}
}

int putchar(int c)
{
while(sending);

senddata = (c << 1) | 0x200;

sendcounter = 10;

tm2ct = 0;

sending = true;

inten |= 0x40;

return (c);
}

unsigned char _sdcc_external_startup(void)
{
#ifdef __SDCC_pdk15
ihrcr = *((const unsigned char*)(0x8bed)); // Use PFS173 factory calibration value for IHRC at 16 Mhz.
#else
ihrcr = *((const unsigned char*)(0x87ed)); // Use PFS154 factory calibration value for IHRC at 16 Mhz.
#endif

clkmd = 0x34; // Use IHRC / 2 = 8 Mhz for system clock, disable watchdog.
clkmd = 0x30; // Disable ILRC

return 0; // perform normal initialization
}

void main(void)
{
// Set timer 2 for interrupt for 1200 baud.
tm2c = 0x10; // Use CLK (8 Mhz)
tm2s = 0x06; // Divide by 6 + 1 ~> 1142857 Hz
tm2b = 118;  // Divide by 118 + 1 ~> 9604 Hz
inten = 0x40;
__asm
engint
__endasm;

pac = 0x81;

for(;;)
{
printf("ASiDesigner!\r\n");
for(unsigned long int i = 0; i < 150000; i++); // Wait approx. 3s.
}
}




Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.


ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #683 on: September 07, 2019, 08:10:25 am »
Does the printf accept additional arguments? :-\
Code: [Select]
printf("ASiDesigner! %d\r\n",k);
k++;

if Not,I suppose we write something like this library for AVR (General purpose numeral output module)  form http://elm-chan.org/docs/avrlib/xitoa.zip
Unfortunately it's in AVR asm, But it should be some way of porting it to PADAUK.
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #684 on: September 07, 2019, 11:06:45 am »
I have modified the Hello example to output the UART on the PA.7 port, so after starting easypdkprog, it should capture the UART data, it can not get the UART data for now, But I have connected an external UART Bridge(FT230x) to it and it's putting data on the line,
There is no "BUG" with easypdkprog. EasyPDK programmer features AUTO-BAUD-DETECTION which requires to send 0x55 as first character followed by at lest 4 extra stop bits (or a small delay) to internally apply the baud rate.
It is reported to work fine with baud rates up to 1.5 Mbit.

I'm working on a clean "Hello World!" example project, which will be included in easypdkprog release.

Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.
How did you measure the internal clock speed? Serial port implementation in the sdcc-example program which you used is based on IHRC directly, not on SYSCLK, This means baud rate will not change when you change SYSCLK.

Does the printf accept additional arguments? :-\
Yes it does. Most likely the SDCC library is not compiled as "small" so the full printf (including support for width adjustments, leading spaces / zeros / floats / ...) implementation simply does not fit in our ultra ultra small RAM.


JS

EDIT: It is included in the Release now: https://github.com/free-pdk/easy-pdk-programmer-software/releases/latest
« Last Edit: September 07, 2019, 11:12:11 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: ali_asadzadeh

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #685 on: September 07, 2019, 06:43:18 pm »
Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

I don't know. I've asked Padauk, but didn't get a reply yet.
For the PFS173, PMS133 and PMS134, the datasheets are contradictionary on that question. Section 6.3 vs. sections 5.4.2 and 5.4.5.
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #686 on: September 08, 2019, 05:15:41 am »
Thanks JS :-+
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #687 on: September 08, 2019, 10:56:47 am »
Is there a way to tell how much flash and ram is used with SDCC? ^-^
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #688 on: September 08, 2019, 11:33:53 am »
Is there a way to tell how much flash and ram is used with SDCC? ^-^

Flash is easy. Have a look at the .map file.
For RAM, in general, you'd have to solve the halting problem (the data from the .map file does not include RAM used for the stack).
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #689 on: September 09, 2019, 06:40:28 am »
Thanks,Is there a way to add it to the command prompt? using make to tell the flash usage?
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #690 on: September 09, 2019, 06:59:38 am »
Guys I have some Idea, is it possible to add easypdkprog into the SDCC tool's, I mean adding the executable's to the distribution,

Something like winAVR for AVR. they had put AVRDUDE in it.

Then we can make a generic make file with the programming command too, also If there is some way of adding the code generated examples for PADAUK IDE for USART send,receive, I2C, SPI, PS2 and ADC it would be very nice too. I think the AVR and winavr was a smart choice at that time and place,(you could easily change the CPU name and FPCU in make file) and also PADAUK are very similar to lower end AVR's, still cheaper tough >:D
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #691 on: September 09, 2019, 07:06:21 am »
Thanks,Is there a way to add it to the command prompt? using make to tell the flash usage?

If you don't use any custom segments, the const segment is last in Flash. So you could parse the line, e.g.
Code: [Select]
Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
CONST                               0000106E    00000B16 =        2838. bytes (REL,CON)
with grep to get the start and size, then add them (e.g. using bc with ibase=16), then divide by 2 to get the size in words.

If you are just worried about exceeding the available Flash: The Linker will warn you about that (if you have a device that has the maximum Flash that the architecture supports).
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #692 on: September 09, 2019, 09:28:08 am »
Thanks, It's always beneficial to have some info, Today I'm working on embOS, such a great OS for Cortex M devices, though I have used a lot FreeRTOS and RTX, but now I prefer embOS simply because it would get much more info from inside the internal workings!

If we could have something like this, it would be very helpful


Quote
Program Size: Code=15080 RO-data=464 RW-data=284 ZI-data=4704 
>:D

can we have an OS on PAUDUK, something like this

http://www.femtoos.org/


or Am I dreaming ::) ::) ::)
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #693 on: September 09, 2019, 09:37:30 am »
can we have an OS on PAUDUK, something like this

http://www.femtoos.org/


or Am I dreaming ::) ::) ::)

Maybe, but it probably would work only on the bigger devices. Maybe try porting a more leightweight OS, such as Atomthreads first?
It probably won't we worth using an OS on such a small device though.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #694 on: September 09, 2019, 10:55:01 pm »
Then we can make a generic make file with the programming command too, also If there is some way of adding the code generated examples for PADAUK IDE for USART send,receive, I2C, SPI, PS2 and ADC it would be very nice too. I think the AVR and winavr was a smart choice at that time and place,(you could easily change the CPU name and FPCU in make file) and also PADAUK are very similar to lower end AVR's, still cheaper tough >:D

I started putting some things together. It will automatically compile&program and also output program length:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain

Still very much work in progress. Next step would be a smaller printf function. And we also need agreement on SFR names... My current favourite would be to use all capitals, like it is done for all other 8bit MCUs.

Regarding a multitaskting OS: I believe that is quite in contradiction to the "FPPA" paradigm. The idea of the Padauk MCUs is to do multithreading with deterministic timing in hardware. That is much more valuable than preemptive multitasking in software and requires little software overhead. Software based preemtive multitasking will not allow you to implement virtual periphery, as it is possible with the FPPA approach.

edit: Of course you could use one FPPA with a multitaksing OS and use other FPPAs for virtual periphery. Things are getting a tad bit complex then.

For those that are a bit more into computer architecture, you can find an introduction to XMOS below. This is based on similar ideas as the padauk FPPA.

https://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.4-DSP/HC23.18.410-XMOS-XS1-May_Xmos.pdf

« Last Edit: September 09, 2019, 11:12:31 pm by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #695 on: September 09, 2019, 11:00:15 pm »
Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

I don't know. I've asked Padauk, but didn't get a reply yet.
For the PFS173, PMS133 and PMS134, the datasheets are contradictionary on that question. Section 6.3 vs. sections 5.4.2 and 5.4.5.

Please let us know their response. I am getting the feeling that the PDK architecture is indeed a 2 cycle architecture. I was also fooled by the clock options initially. But then, there are some instruction that are very hard to efficiently implement in a 1 cycle architecture. For example the memory RMW-instructions (INC, many others). These would require a two port memory or would be very wasteful in ressources (f.e. double edge memory access).
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #696 on: September 10, 2019, 05:36:38 am »
Regarding a multitaskting OS: I believe that is quite in contradiction to the "FPPA" paradigm. The idea of the Padauk MCUs is to do multithreading with deterministic timing in hardware. That is much more valuable than preemptive multitasking in software and requires little software overhead. Software based preemtive multitasking will not allow you to implement virtual periphery, as it is possible with the FPPA approach.

edit: Of course you could use one FPPA with a multitaksing OS and use other FPPAs for virtual periphery. Things are getting a tad bit complex then.

For those that are a bit more into computer architecture, you can find an introduction to XMOS below. This is based on similar ideas as the padauk FPPA.

https://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.4-DSP/HC23.18.410-XMOS-XS1-May_Xmos.pdf

Their current FPPA paradigm is not very compatible with C. It looks like they designed a non-parallel instruction set, and then just made some parallel devices.
SDCC currently does not support multiple FPPA.

For efficient parallelism for the Padauk µC, we'd need:
* Stack-pointer-relative addressing and better stack handling (I'm currently running some experiments - when you compile code with --stack-auto for the current architecure, code size triples)
* Synchronization. We would need at least a compare-and-swap instruction, and an xch withindirect addressing mode. Preferably also an idxadd variant of add M, a.

I believe I can add support for multiple FPPA to SDCC. But the generated code will be big and slow. For practical purposes, running a multitasking OS on a single FPPA would be more efficient.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #697 on: September 10, 2019, 06:49:36 am »

Their current FPPA paradigm is not very compatible with C. It looks like they designed a non-parallel instruction set, and then just made some parallel devices.
SDCC currently does not support multiple FPPA.

For efficient parallelism for the Padauk µC, we'd need:
* Stack-pointer-relative addressing and better stack handling (I'm currently running some experiments - when you compile code with --stack-auto for the current architecure, code size triples)
* Synchronization. We would need at least a compare-and-swap instruction, and an xch withindirect addressing mode. Preferably also an idxadd variant of add M, a.

I believe I can add support for multiple FPPA to SDCC. But the generated code will be big and slow. For practical purposes, running a multitasking OS on a single FPPA would be more efficient.

I don't think true c-compatible paralellism was their ultimate goal. (They don't even provide a C-compiler...). Obviously that would have added a lot of additional complexity, as you point out.

The idea is probably to have specific tasks assigned to specific threads. For example one thread runs the SPI peripheral, a second one runs a control loop, while the main thread mostly sleeps and does housekeeping/reconfiguration. Each of these would reside in their own memory space with dedicated ressources and would use minimal inter-thread communication via pipes. This would keep synchronization overhead down a lot.

For SDCC, the main challenge would be to allow multiple main function to initialize each FPPA. Maybe that could be dont similar to interrupts? It would be up to the user to ensure that variables are not reused between different threads.

Of course, something needs to be done with the p-register. A very rigid approach would be to clearly assign each function to only one FPPA.

A more pragmatic approach, for now, would be to have C-code always stay on FPPA0 and use assembler for the others...

Regarding preemtive multitasking: Of course this would free up some of the synchronization headache, but then the usefulness would be quite limited compared to using multiple hardware threads.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1413
  • Country: us
  • Very dangerous - may attack at any time
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #699 on: September 14, 2019, 07:19:23 pm »

 
The following users thanked this post: voltsandjolts, tim_, socram


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf