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

0 Members and 3 Guests are viewing this topic.

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1475 on: December 27, 2022, 11:51:09 pm »
All, PFS132 is available, seems to be a 'better' PFS122 with improved (not R-Type) 12 bit ADC.

I am going to purchase a large number of those directly in China (somewhere between 10k and 100k pcs, i will stock them for longer term use in Europe for us), if some of you want some for testing, play projects etc, you can contact me with PM and i can send you some early next year (we should get them before Chinese New Year).
PFS132-S16A to be exact, SOIC-16 case.

Cheers

Johannes
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 342
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1476 on: December 28, 2022, 05:54:18 pm »
sorry for the delay.
compiler: it will definitely not do the read/modify/write as 3 opcodes, that you would see in the assembly listing and the set0.io instruction is actually assembly already.

i agree you would wish that only one bit would be changed, but this not what i observe.
There is a simple test to do:

add a pull-up (or program a pull-up) on one bit on PA or PB (lets take the example here, PB0).
i want to use PB0 as 'open collector' output (actually for i2c ..)
So i do a set0.io  PB,#0   - to set the bit to 0
after that, using PBC i can make the pin either '1' (due to the pullup) if i configure it as input, or '0' if i configure it as output in PBC.

then, while the bit is 'input', set ANY other bit in PB, one or zero does not matter.
the data bit '0' stored in the holding register for PB0 will be changed to a one, although no-one does a set1.io PB,#0

So it seems setting ANY bit in PB will 'read back' ALL values as seen from the port, change the one bit in question, and write them all to the port's holding register.
In normal situations (where inputs are inputs always) this would not harm as the value in the holding register is not important. however, in my usecase i depend on the 0 to be there, and as it is magically 'changed' now i need to set it to 0 everytime before i enable the output .. doable but annoying and i think its worth a warning.

Johannes

Actually it looks more like flipping the state of "PAC" / "PBC" from input to output might transfer the content of the input to the output latch...
I need to investigate more... So setting a bit seems to cause the port to also update all inputs... (unfortunately we can not see this from the diagram in PADAUK manual)

But I think you can prevent this easily. Just have a look at "PADIER" / "PBDIER"...
Here you can detach the digital pin input completely (again, have a look at  page 56 / Fig. 17:  http://www.padauk.com.tw/upload/doc/PFS122%20datasheet_EN_V001_20220518.pdf
Setting the bit to 0 for a pin should make it impossible to "read back" anything from the actual port.

JS
« Last Edit: December 28, 2022, 06:02:17 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 342
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1477 on: December 28, 2022, 06:05:44 pm »
One problem i stumbled upon which i would like to 'warn' about ;)
The bit set/reset instructions on the IO ports (PA and PB) do not affect a single bit. the implementation in the padauk is made in a way that they read back all 8 bits, modify the specific bit, and then put them back into the output register.

Could you explain your observation a bit more in detail? I'm working on a cycle accurate emulator which also includes peripherals (parts of it been used in the noiseplug showcase project: https://github.com/free-pdk/easy-pdk-showcase-projects/tree/master/noiseplug/emulation)

Would it make sense to merge this work into the uCsim simulators that SDCC uses?

uCsim is a different "beast" which I have not much knowledge of.

The emulator I'm working on is for realtime simulations with built in emulation of external components like PWM output routed to WAV output, WS2812B RGB led matrix to SDL2 drawing, ...


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

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1478 on: January 16, 2023, 10:22:00 pm »
I think it will be nice to update the site for newer ICs.
Kashikoma!
 

Offline vic_luga

  • Newbie
  • Posts: 3
  • Country: ru
    • 188230 г.Луга пер Солецкий дом 8
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1479 on: January 30, 2023, 10:19:37 am »
Hello. What could be the problem?
It is calibrated normally at 8 MHz

e:\easy-pdk-programmer-software>easypdkprog.exe write -npfc161  E:\easy-pdk-programmer-software\Examples\src\build\comptest_pfc161.ihx
Erasing IC... done.
Writing IC (394 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 5.00V ... calibration result: 892003Hz (0x8F)  out of range.
ERROR: Calibration failed
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 342
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1480 on: February 01, 2023, 03:34:40 pm »
Hi,

according to your output:

Calibrating IC
* IHRC SYSCLK=1000000Hz @ 5.00V ... calibration result: 892003Hz (0x8F)  out of range.


you try to calibrate to 1 MHz (1.000.000 Hz).

In case you selected an 8MHz clock (like you wrote) then you get this error since calibration can only tune the frequency so slightly.

Solution: Either select a clock of 1MHz in your code if you want to calibrate to 1MHz or select calibrate to 8MHz (8000000) in case you wanted and selected an 8MHz clock in your code.


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

Offline vic_luga

  • Newbie
  • Posts: 3
  • Country: ru
    • 188230 г.Луга пер Солецкий дом 8
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1481 on: February 02, 2023, 02:42:04 am »
Not so. When setting 8 MHz, calibration is normal.
If I install any other it is not calibrated. In this case, the file from the example, I did not change it.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 342
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1482 on: February 03, 2023, 10:06:38 am »
Not so. When setting 8 MHz, calibration is normal.
If I install any other it is not calibrated. In this case, the file from the example, I did not change it.

Just tried it and it works without any issue:

8MHz:

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V
  return 0;                                     //perform normal initialization
}



./easypdkprog write -npfc161 build/helloworld_pfc161.ihx
Erasing IC... done.
Writing IC (184 words)... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 4.00V ... calibration result: 7973105Hz (0x50)  done.


1MHz:

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_1MHZ();                //use 1MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(1000000,4000);        //tune SYSCLK to 1MHz @ 4.000V
  return 0;                                     //perform normal initialization
}


./easypdkprog write -npfc161 build/helloworld_pfc161.ihx
Erasing IC... done.
Writing IC (182 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 997843Hz (0x50)  done.


For completeness, I just flashed the "comptest_pfc161.ihx" from the project:

./easypdkprog -nPFC161 write Examples/comptest_pfc161.ihx
Erasing IC... done.
Writing IC (394 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 5.00V ... calibration result: 998690Hz (0x50)  done.



Other possible problems:
* IC might be bad
* wiring to IC is not good
* clock selection is wrong in your code
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline vic_luga

  • Newbie
  • Posts: 3
  • Country: ru
    • 188230 г.Луга пер Солецкий дом 8
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1483 on: February 05, 2023, 09:25:39 am »
8MHz
E:\easy-pdk-programmer-software>easypdkprog.exe write -npfc161  E:\easy-pdk-programmer-software\Examples\src\build\helloworld_pfc161.ihx
Erasing IC... done.
Writing IC (184 words)... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 4.00V ... calibration result: 7945630Hz (0x7B)  done.

1MHz
E:\easy-pdk-programmer-software>easypdkprog.exe write -npfc161  E:\easy-pdk-programmer-software\Examples\src\build\comptest_pfc161.ihx
Erasing IC... done.
Writing IC (394 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 5.00V ... calibration result: 786982Hz (0x29)  out of range.
ERROR: Calibration failed



Example code

// COMPARATOR test. VDD estimation using internal VBandGap (1.2V) reference, serial output of comparator results on PA7 at 19200 baud.
//
// We use 1MHz as sysclock so we can test with much lower VDD:
//
//  easypdkprog start --runvdd=5.0
//  easypdkprog start --runvdd=3.3
//  easypdkprog start --runvdd=2.0

#include <stdint.h>
#include <stdio.h>
#include "easypdk/pdk.h"

volatile uint16_t txdata;                       //txdata, serial data shift register

void interrupt(void) __interrupt(0)
{
  if( INTRQ & INTRQ_TM2 )                       //TM2 interrupt request?
  {
    INTRQ &= ~INTRQ_TM2;                        //mark TM2 interrupt request processed
    if( txdata )                                //txdata contains bits to send?
    {
      if( txdata&1 )                            //check bit (1/0) for sending
        __set1io( PA, 7 );                      //send 1 on PA7
      else
        __set0io( PA, 7 );                      //send 0 on PA7
      txdata >>= 1;                             //shift txdata
    }
  }
}

int putchar(int c)
{
  while(txdata);                                //wait for completion of previous transmission
  INTEN &= ~INTEN_TM2;                          //disable TM2 (setup of 16 bit value txdata is non atomic)
  txdata = (c << 1) | 0x200;                    //setup txdata with start and stop bit
  INTEN |= INTEN_TM2;                           //enable TM2
  return (c);
}

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_1MHZ();                //use 1MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(1000000,5000);        //tune SYSCLK to 1MHz @ 5.000V
  EASY_PDK_USE_FACTORY_BGTR();                  //use factory BandGap tuning value (tuned @ 5.0V)
  return 0;                                     //perform normal initialization
}

void main(void)
{
  //setup timer2 (TM2) interrupt for 19200 baud
  TM2C = TM2C_CLK_IHRC;                         //use IHRC -> 16 Mhz
  TM2S = TM2S_PRESCALE_NONE | TM2S_SCALE_DIV8;  //no prescale, scale 8 ~> 2MHz
  TM2B = 104;                                   //divide by 104 ~> 19230 Hz (apx. 19200)

  PAC = 0x80;                                   //enable PA.7 as output
  txdata = 0xD55F;                              //setup 2 stop bits, 0x55 char for autobaud, 1 start bit, 5 stop bits
  INTEN = INTEN_TM2;                            //enable TM2 interrupt, send out initial stop bits and autobaud char
  __engint();                                   //enable global interrupts

  //comparator VBandGap / VInt (case 3: VDD = [ 40 / (N+9) ] * 1.20 V ;
  static const char vddcompstr[16][5] = {"5.33","4.80","4.36","4.00","3.69","3.43","3.20","3.00","2.82","2.67","2.53","2.40","2.29","2.18","2.09","2.00"};

  //setup COMPARATOR: IN- = VBandGap, IN+ = VInt (selected by GPCS)
  GPCC = GPCC_COMP_ENABLE | GPCC_COMP_MINUS_BANDGAP_1V2 | GPCC_COMP_PLUS_VINT_R;

  for(;;)
  {
    puts("VDD is:");
    for( uint8_t n=0; n<16; n++ )               //loop over all 16 values of the VInt_R resistor ladder
    {
      GPCS = GPCS_COMP_CASE3 | n;               //case 3 covers 2.0V - 5.33V
      for(uint32_t d=100; d>0; d--);            //small delay after GPCS setup required

      if( GPCC & GPCC_COMP_RESULT_POSITIV )     //test if comparator result is positiv
        putchar('>');
      else
        putchar('<');

      puts(vddcompstr[n]);                      //output the coresponding VDD value (we use a string table to avoid printf)
    }

    for(uint32_t i=180000; i>0; i--);           //wait approx. 3s
  }
}
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1484 on: February 17, 2023, 01:16:40 pm »
Hello All,

my wishful thinking that the PFS132 is 'just' the same like a PFS122 or PFS172 with better A/D peripheral did not realise well.

I have PFS132 on a board for testing but the programmer does not recognize it (obviously), it has a different chip id (0x764) and when i try to handle it with the PFS172 settings it fails.

Difference in the datasheets i see is that it has also 3x 11bit PWM and 8x8 multiplier, so it is a different animal than the PFS122.

Is there a chance to get it supported by the programmer ? I can send chips to whoever wants to try to make this work, i can also test settings and recompile the easypdkprog code if you have ideas what i should try.
The 'probe' shows VPP 4.5V VDD 2.0V ..

Johannes
« Last Edit: February 17, 2023, 06:37:44 pm by jacola »
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1485 on: February 25, 2023, 11:06:35 am »
Hmm no-one on the PFS132 ?  Anything i could try to see how to support it ? Anyone wants some to try ?

I have a quite large stock of PFS132 and just ordered PFS122 in large quantities (at 100k pcs the SO-16 is 0.04$ in china ..) now as they work as expected.

My current quest is to make a POE signature controller out of the PFS122 for both 802.3at and 802.3afn - this will allow you make a low cost solution to connect, for example, LEDs, directly to PoE.
If anyone is interested PM me.
Next quest will be to try to use the PFS122/132 as a switching power supply controller ...
Why do i do these things ?

PoE is everywhere, but the choice and availability of inexpensive, standards compliant PoE signature chips is limited, and those chinese companies who make PoE modules do not test and design well, deliver nonworking and bad product etc. Reputable module manufacturers like Silvertel are better but still there are a lot of caveats. If my project works (and i have first success already) i get a very intelligent, software programmable solution at a much lower cost.

Cheers

Johannes
« Last Edit: February 25, 2023, 12:07:28 pm by jacola »
 
The following users thanked this post: printplaatreparatie

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1486 on: May 18, 2023, 12:18:46 am »
Hi all, anyone volunteering to help adding PFS132 to the programmer/toolchain ?
Happy to invest some time but i need to understand how to do it ..

Johannes
 

Offline crossbound

  • Newbie
  • Posts: 4
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1487 on: June 26, 2023, 01:59:45 am »
Hello everyone. Just trying to get my feet wet with the Padauk MCU's. Had a quick silly question regarding the LED's on the programmer. I don't seem to be able to figure out what each of the three LED's indicate. Searching the thread didn't seem to give me any results. Thanks for the info!
 

Offline DC1MC

  • Super Contributor
  • ***
  • Posts: 1882
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1488 on: July 26, 2023, 11:07:09 am »
If someone has a programmer compatible with PMC150 for sale in DE/EU kindly please contact me.

Cheers,
DC1MC
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1489 on: August 28, 2023, 09:44:28 pm »
well, pretty much quiet here .. seems padauks are not in favor any more ;)
I have put out a 500$ bounty for the PFS132 support ..

https://app.bountysource.com/issues/123829632-pfs132-support

Cheers

Johannes
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 239
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1490 on: August 29, 2023, 04:59:11 am »
Seems that Padauk is realigning their strategy:

https://www.digitimes.com/news/a20230814PD207/consumer-electronics-mcu.html

Could mean that they are looking into more complex and/or very specialized products. In any case, there seems to be reduced focus on ultra-low-cost MCU.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 239
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1491 on: August 29, 2023, 05:08:54 am »
well, pretty much quiet here .. seems padauks are not in favor any more ;)
I have put out a 500$ bounty for the PFS132 support ..

https://app.bountysource.com/issues/123829632-pfs132-support

Cheers

Johannes

It seems the PFS123 is a direct replacement for the discontinued PFS173, but with a capacitance based ADC instead of resistor based. PFS173 is already supported. The amount of memory and periphery seems to be basically the same.

The section in the datasheet about the programming is identical for both devices. I'd guess there is a high likelyhood that the programming algorithm is the dame for both devices and only the deviceid needs to be changed. Have you already tried something in that direction.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 239
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1492 on: August 29, 2023, 05:24:30 am »
Ok, i realized you were asking for PFS132, not PFS123.

The PFS132 is indeed a bit different, although the programming instructions are the same as for PFS123/PFS173. Possibly using the PFS173 programming algorithm still works when changing chipid and adjusting for different memory size?
 

Offline crossbound

  • Newbie
  • Posts: 4
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1493 on: October 17, 2023, 01:49:45 am »
Just my little contribution at this time. I have been working on a breakout board and programmer riser design for the EasyPDK programmer. The breakout board features a pad on the bottom side for a decoupling capacitor and the top has a place for an LED and current limiting resistor connected to PA4. Pads are designed in such a way that 1206, 0805, or 0603 components can be used.
There will be two different versions of the gerber files, one that has a single board and riser, the other is panelized with mouse bites that will yield 15 breakout boards and 5 risers per panel. Dimensions of the panel is such that it will allow for ordering 5 panels for $2 on JLCPCB.
If anyone is interested I'll upload the gerbers to Github. Will be ordering a set for myself soon to verify.







« Last Edit: October 17, 2023, 01:53:03 am by crossbound »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 239
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1494 on: October 17, 2023, 05:08:39 am »
Looks really neat! 0'1" less wide and you would not need the riser. :) But then, no place for silk screen...

Btw, which PCB layout program did you use?
 

Offline crossbound

  • Newbie
  • Posts: 4
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1495 on: October 17, 2023, 02:50:33 pm »
Thank you.. I tried getting the header closer in to avoid using a riser, but unfortunately they would end up touching the pads for the MCU..  :--
Kicad is my software of choice. I did play around with EasyEDA, but it was not for me. I do however like the integration with LCSC for picking the parts.

Looks really neat! 0'1" less wide and you would not need the riser. :) But then, no place for silk screen...

Btw, which PCB layout program did you use?
 

Offline HwAoRrDk

  • Super Contributor
  • ***
  • Posts: 1480
  • Country: gb
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1496 on: January 10, 2024, 04:42:52 pm »
Can anyone give me some insight into how the 16-bit timer on Padauk MCUs works?

What I want to do is create a timeout timer of around 500 msec. I've figured I can do this by setting the T16 clock source to SYSCLK (which will be IHRC/16 = 1 MHz), dividing by 16 for 62.5 kHz tick rate, then setting the interrupt source to be bit 15 of the counter (count of 32,768). This should give me a timeout period of approximately 524 msec, which is good enough for my purposes.

But, I only want to enable this timeout timer on-demand, and wait for either an I/O pin to toggle or the timeout to expire (i.e. I don't want something to repeat every 500 msec).

I'm thinking there's two potential ways I can go about this. When I want to start the timeout, I could either:

- Reset the timer counter to zero, then enable the interrupt for T16 (INTEN |= INTEN_T16). Disable the interrupt at all other times.
- Enable T16 by setting its clock source, hopefully the counter is reset to zero whenever the timer is re-enabled. Keep T16 disabled (i.e. T16M_CLK_DISABLE) at all other times. Interrupt is enabled at all times.

The first method is difficult because the T16 counter can only be written or read with specific assembly instructions, STT16 and LDT16, and these instructions only read/write from/to a fixed memory address. To reset the counter to zero, I would have to do something like declare a global variable with a value of zero, then use inline assembly to write that value to the counter.

Code: [Select]
static uint16_t t16_reset_val = 0;

/* Wherever I need to reset T16 counter: */
__asm__("stt16 _t16_reset_val\n");

Also, the Free-PDK website detailing the PDK13 instruction set says that the memory address for STT16 and LDT16 must be word-aligned. I don't know how to ensure that with SDCC, or if it's even possible.

The second method, I don't know if the counter value gets reset whenever the T16 is disabled/enabled. If it does, this approach would work, but if not it's not viable. Anyone know?
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1497 on: January 12, 2024, 08:57:59 am »
If you want to set the timer to 0, why not just do so?

Code: [Select]
__sfr16 timercnt;

void f(void)
{
timercnt = 0;
}

SDCC doesn't have much support for alignment yet, and support for the 16-bit timer is quite incomplete (some stuff, in particular setting the counter to a small value, works), but it should always either generate correct code or give an error message.

 

Offline HwAoRrDk

  • Super Contributor
  • ***
  • Posts: 1480
  • Country: gb
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1498 on: January 12, 2024, 05:31:29 pm »
If you want to set the timer to 0, why not just do so?

Haha, yeah, I subsequently found that myself just yesterday. ;D

I previously saw the definition for T16C in the Free-PDK headers for a __sfr16 but with no address (i.e. no __at()) and thought that was odd and perhaps some vestigial thing. But then I found it is actually used in some example code. I couldn't comprehend how that worked, so I went looking in the SDCC code for how the stt16 instruction was emitted.

Am I interpreting this code correctly, or is SDCC hard-coded to handle this specially? Does it just assume that any assignment of a literal value to any __sfr16 should be translated to a stt16 instruction loading from pseudo-register p? That seems a bit of a hack... :P I suppose technically there are no 16-bit peripheral or CPU registers, so this is a fairly safe assumption to make, but what happens if someone attempts to use __sfr16 to access a contiguous pair of high/low registers on a peripheral (e.g. PWM generator)?

(some stuff, in particular setting the counter to a small value, works)

Yes, I note that it only works assigning values 0-255, which is unfortunate, because I need to assign a value greater than that. :( Will still need to use the global variable method. Or maybe I will try writing some inline assembly to use p, given that is implicitly guaranteed to be at a word-aligned address.
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1499 on: January 12, 2024, 07:42:35 pm »
Yes, the 16-bit timer counter is the only 16-bit I/O location, so _sfr16 is considered to always mean the 16-bit timer counter.

The pseudoregister p is used as an 8-bit register followed by a 0x00 byte. So it cannot be used to write values larger than 255.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf