EEVblog #1144 - Padauk Programmer Reverse Engineering

[serisman]

Did a new Pull
Seems like Devel & Master has been "alligned"

Yes, to help alleviate all the confusion, JS just released version 1.3 to master a few hours ago, which includes all of the development changes.

I'm not a GIT Guru - is the below url correct for a "Git clone" , or should i have used some kind of tag to get devel ??
This devel
https://github.com/free-pdk/easy-pdk-programmer-software/tree/development

Has this as git chekout (no devel in the name)
https://github.com/free-pdk/easy-pdk-programmer-software.git

Well, git clone pulls down the repository with all the branches, so there isn't a different url per branch.
To change to a different branch you need to use the git checkout <branch> command (after pulling down the repo)

And Yipieee ..... Calibrating 

Code: [Select]

$ make clean program
rm -r -f .build .output
sdcc -mpdk14 -c --std-sdcc11 --fverbose-asm --opt-code-size -DPFS154 -DF_CPU=1000000 -DTARGET_VDD_MV=4000 -I. -I../include -o .build/main.rel main.c
sdar -rc .build/lib.lib
sdcc -mpdk14 --out-fmt-ihx -o .output/BlinkLED_WithIRQ_PFS154.ihx .build/main.rel .build/lib.lib
makebin -p .output/BlinkLED_WithIRQ_PFS154.ihx .output/BlinkLED_WithIRQ_PFS154.bin
---------- Segments ----------
.  .ABS.                            00000000    00000000 =           0. bytes (ABS,CON)
.  .ABS.                            00000000    00000000 =           0. bytes (ABS,CON)
HEADER1                             00000000    00000002 =           2. bytes (ABS,CON)
HEADER3                             00000000    00000010 =          16. bytes (ABS,CON)
PREG2                               00000000    00000002 =           2. bytes (ABS,CON)
RSEG0                               00000000    00000002 =           2. bytes (ABS,CON)
DATA                                00000002    00000015 =          21. bytes (REL,CON)
HOME                                00000022    00000002 =           2. bytes (REL,CON)
GSINIT                              00000024    00000014 =          20. bytes (REL,CON)
GSFINAL                             00000038    00000002 =           2. bytes (REL,CON)
CODE                                0000003A    00000124 =         292. bytes (REL,CON)
SSEG                                FFFFFFFF    00000001 =           1. bytes (REL,CON)
------------------------------
Size of BlinkLED_WithIRQ_PFS154.bin: 350 bytes
easypdkprog -n PFS154 write .output/BlinkLED_WithIRQ_PFS154.ihx
Erasing IC... done.
Writing IC (175 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 997066Hz (0x84)  done.


First time i ever saw Calibrating , when programming.

Yay!  I'm glad you got it working!

I have no idea what i did wrong , besides not specifying some magic git command on checkout.
And prob. being saved by master now updated to development.

But what did i do wrong

My guess is it was a combination of potentially not actually being on the development branch, and possibly not actually re-compiling the easypdkprog software.

Edit: easypdkprog still shows 1.2

Code: [Select]

$ easypdkprog -V
easypdkprog 1.2

I'll have to check that out later.  Possibly JS missed a release step?

[kaweksl]

Code: [Select]

./easypdkprog -vgives pc side software version

to get hw programmer version use

Code: [Select]

./easypdkprog --verbose probegives

Searching programmer... found: /dev/ttyACM0
FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.3 Protocol:1.3
Probing IC... Nothing found.

[bingo600]

Improvement for output of  easypdkprog -V
easypdkprog 1.2

$ git rev-parse HEAD
78983e5aee2ab4bc16628405a0da99ca290f9af3

Or
$ git log -1
commit 78983e5aee2ab4bc16628405a0da99ca290f9af3 (HEAD -> master, tag: 1.3, origin/master, origin/development, origin/HEAD)

Could you in the makefile run a:  git rev-parse HEAD , save it in a "GIT_VER"
Then insert a -DGIT_BUILD=$GIT_VER  , and use that GIT_BUILD as a string in the -V output ?

That could come in handy , when noobs like me don't know how to checkout development via git ?

easypdkprog -V
easypdkprog 1.2 - Git: 78983e5aee2ab4bc16628405a0da99ca290f9af3


All of the above git commands supplied by "Google" , i'm still at git clone & git pull  level.
SVN is my daily tool.

/Bingo

[serisman]

Edit: easypdkprog still shows 1.2

Code: [Select]

$ easypdkprog -V
easypdkprog 1.2

I'll have to check that out later.  Possibly JS missed a release step?

Yeah, it looks like the version number in the source code still needs to be updated (line 32):
https://github.com/free-pdk/easy-pdk-programmer-software/blob/master/easypdkprog.c

[serisman]

Improvement for output of  easypdkprog -V
easypdkprog 1.2

$ git rev-parse HEAD
78983e5aee2ab4bc16628405a0da99ca290f9af3

Or
$ git log -1
commit 78983e5aee2ab4bc16628405a0da99ca290f9af3 (HEAD -> master, tag: 1.3, origin/master, origin/development, origin/HEAD)

Could you in the makefile run a:  git rev-parse HEAD , save it in a "GIT_VER"
Then insert a -DGIT_BUILD=$GIT_VER  , and use that GIT_BUILD as a string in the -V output ?

That could come in handy , when noobs like me don't know how to checkout development via git ?

easypdkprog -V
easypdkprog 1.2 - Git: 78983e5aee2ab4bc16628405a0da99ca290f9af3


All of the above git commands supplied by "Google" , i'm still at git clone & git pull  level.
SVN is my daily tool.

/Bingo

bingo600,

That sounds like a good suggestion.  Why don't you open a feature request (i.e. issue) on GitHub?

I would think the releases would still just use the release number, but branches could use a git commit or possibly the git branch name and git commit.

[bingo600]

That sounds like a good suggestion.  Why don't you open a feature request (i.e. issue) on GitHub?

Done #45

Edit: I switched to development

Code: [Select]

$ git checkout development


Code: [Select]

$ git log -1
commit 78983e5aee2ab4bc16628405a0da99ca290f9af3 (HEAD -> development, tag: 1.3, origin/master, origin/development, origin/HEAD, master)
Author: freepdk <free-pdk@users.noreply.github.com>
Date:   Mon Jul 13 11:18:15 2020 +0200

    update firmware binary


/Bingo

[bingo600]

JS is a fast guy , thanx 

#45 has been done for easypdkprog

See
https://github.com/free-pdk/easy-pdk-programmer-software/issues/45#issuecomment-657677538

Code: [Select]

$ easypdkprog -V
easypdkprog 1.3-3-gef65826
I hope this will tell you experienced guyzz , that i'm using latest devel.

Then it should be fast to spot someone not building from devel or latest whatever.


Hope the tag will find it's way into the Firmware too , when time is.

Code: [Select]

$ easypdkprog probe --verbose
Searching programmer... found: /dev/ttyACM3
FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.3-3-gef65826 Protocol:1.3
Probing IC... found.
TYPE:FLASH RSP:0x1AA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1


[tim_]

You may download my assembler and I wrote a small tutorial for it.
http://www.endresz.eu/padauk/padauk.html

Hope you will find it usefull!

Nice! You should post it on Github so it is added to the project list.

I have to ask though: Have you tried SDASPDKxx, the assembler that comes with SDCC?

[kaweksl]

Some home-made projects using pdk

Replacement for PFC8574, NanoPi Duo controlling 1602 LCD with i2c using python


PMS150C-U06 as I2C relay controller , I can't find my SOT23 LDO's so had to glue sot223

[bingo600]

Would this patch work for addin git vers to the firmware ??

[js_12345678_55AA]

Would this patch work for addin git vers to the firmware ??

The problem is not adding it to the Makefile. The problem is to add the correct tag to the autobuild process.

Right now when you create a tag on master the travis autobuild uses this tag to include it into the release.
Since the firmware is not built with the autobuild right now there is no way to add the tag.

Example:
In future new master version is pushed and new tag 1.4 is added.
Then travis autobuild just compiles easypdkprog and creates the release
=> problem: firmware does not have new tag. Any previous (by hand) compiled firmware will have the old tag since the new tag is the trigger for autobuild.

=> solution: I need to add the firmware build to travis. this requires to add the arm build tools to the travis VM build process...

Have a look at ".travis.yml" and ".travis-build.sh".

And in case you did not have noticed there is a "build passed" badge on github. When you click on it you see the last autobuild: https://travis-ci.org/github/free-pdk/easy-pdk-programmer-software
and if you click on "Build History" there you see all autobuilds done: https://travis-ci.org/github/free-pdk/easy-pdk-programmer-software

[bingo600]

@JS

Beautifull 

Code: [Select]

$ easypdkprog -V
easypdkprog 1.3-10-gc5fabd3

Code: [Select]

$ easypdkprog probe --verbose
Searching programmer... found: /dev/ttyACM3
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3 (1.3-10-gc5fabd3)
Probing IC... found.
TYPE:FLASH RSP:0x1AA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1


/Bingo

[NickE]

You may download my assembler and I wrote a small tutorial for it.
http://www.endresz.eu/padauk/padauk.html

Hope you will find it usefull!

Nice! You should post it on Github so it is added to the project list.

I have to ask though: Have you tried SDASPDKxx, the assembler that comes with SDCC?

I only tried to write inline asm code in SDCC and I used the naked function keyword but still resulted a lot of extra asm code. I was unable to find any method to write code only in asm so I wrote my own assembler.

I'm working on the Github page.

[NickE]

I made this: https://github.com/NetNickE/assembler-for-padauk

[tim_]

You may download my assembler and I wrote a small tutorial for it.
http://www.endresz.eu/padauk/padauk.html

Hope you will find it usefull!

Nice! You should post it on Github so it is added to the project list.

I have to ask though: Have you tried SDASPDKxx, the assembler that comes with SDCC?

I only tried to write inline asm code in SDCC and I used the naked function keyword but still resulted a lot of extra asm code. I was unable to find any method to write code only in asm so I wrote my own assembler.

I'm working on the Github page.

I used full assembler when SDCC was still in a very early state. See here for example: https://github.com/cpldcpu/SimPad/tree/6f3a2bbe980e9122dc814abd942b395621b8c02d/PFS154Blinky

Not sure if this still works with the current version. I will look into adding some pure assembler examples again.

[HwAoRrDk]

I was unable to find any method to write code only in asm so I wrote my own assembler.

The Padauk assemblers that are part of SDCC are separate executables (as are all of them for other supported platforms): sdaspdk13, sdaspdk14, and sdaspdk15.

Code: [Select]

sdas Assembler V02.00 + NoICE + SDCC mods  (Padauk 14)


Copyright (C) 2012  Alan R. Baldwin
This program comes with ABSOLUTELY NO WARRANTY.

Usage: [-Options] file
Usage: [-Options] outfile file1 [file2 file3 ...]
  -d   Decimal listing
  -q   Octal   listing
  -x   Hex     listing (default)
  -g   Undefined symbols made global
  -a   All user symbols made global
  -b   Display .define substitutions in listing
  -bb  and display without .define substitutions
  -c   Disable instruction cycle count in listing
  -j   Enable NoICE Debug Symbols
  -y   Enable SDCC  Debug Symbols
  -l   Create list   file/outfile[.lst]
  -o   Create object file/outfile[.rel]
  -s   Create symbol file/outfile[.sym]
  -p   Disable automatic listing pagination
  -u   Disable .list/.nlist processing
  -w   Wide listing format for symbol table
  -z   Disable case sensitivity for symbols
  -f   Flag relocatable references by  `   in listing file
  -ff  Flag relocatable references by mode in listing file
  -I   Add the named directory to the include file
       search path.  This option may be used more than once.
       Directories are searched in the order given.

The macro assembler that's part of SDCC is basically a fork of the ASxxxx cross-assembler. You can find documentation for it here: https://shop-pdp.net/ashtml/asxxxx.php

(Note that the main-line ASxxxx doesn't support Padauk micros, though. I don't believe anything has ever been 'back-ported' from SDCC.)

[serisman]

Some home-made projects using pdk

Replacement for PFC8574, NanoPi Duo controlling 1602 LCD with i2c using python
(Attachment Link)

PMS150C-U06 as I2C relay controller , I can't find my SOT23 LDO's so had to glue sot223
(Attachment Link)

Thanks for sharing!

I assume the source code is in your https://github.com/kaweksl/pdk-codebucket repo?

That LCD adapter is similar to a project I had in mind.  But, why emulate the PCF8574 i2c extender when you could have a much more efficient/faster protocol that directly controls the LCD?  If I remember correctly, the PCF8574 requires a lot of overhead, specifically to properly toggle the LCD's EN line.

Edit:  Ok, I just looked at your source code, and it looks like your goal is a (mostly) compatible PCF8574 i2c expander, and not just a lcd driver.  This also gives the benefit of Arduino LiquidCrystal_I2C compatibility without introducing yet another new library.  So, it makes more sense why you are not using a more efficient protocol.  I am still interested in a more optimized version for myself and will work on that when I have time.

By the way, take a look at this library sometime: https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
There are optimizations and performance tests showing i2c being pretty slow.

[kaweksl]

That LCD adapter is similar to a project I had in mind.  But, why emulate the PCF8574 i2c extender when you could have a much more efficient/faster protocol that directly controls the LCD?  If I remember correctly, the PCF8574 requires a lot of overhead, specifically to properly toggle the LCD's EN line.

When developing i2c slave it was easy to compare and debug against PCF8574, also i could see "effect".

I assume the source code is in your https://github.com/kaweksl/pdk-codebucket repo?

Mostly same, needed to add some peephole rules since pdk13 has less instructions, also i switched from pin change interrupt to comparator interrupt, since pms150c-u6 don't have pin change interrupt, also added i2c address selection via external resistor value.

EDIT:
For me whole point of i2c is to save pins on master uc, reduce wires, speed has low priority. Also liquidcrystal_i2c library is not using PCF8574 sequential write (not sending address every byte) , which could speed up things.

[serisman]

For me whole point of i2c is to save pins on master uc, reduce wires, speed has low priority. Also liquidcrystal_i2c library is not using PCF8574 sequential write (not sending address every byte) , which could speed up things.

Oh yes, I completely agree that i2c is more about saving pins than speed.  But, if it can do both, why not.

I was just pointing out that if the goal is an i2c lcd adapter, there are faster / more efficient ways to drive an lcd over i2c than what the PCF8574 i2c expander allows (even with sequential write).

If I remember correctly, the PCF8574 is wired up using 4-bit mode, which requires 2 transfers per command/data byte.  But, I believe it also needs a second transfer per nibble to toggle the EN line, so that is at least 4 i2c transfers per lcd command/data byte.  Without sequential mode, that doubles again to 8 i2c transfers per command/data byte.  With a 14 or 16 pin Padauk, there should be enough I/Os for 8-bit mode along with the normal control lines (RS, RW, EN).  So, you could drive it much faster, almost down to 1 transfer per command/data byte (would depend on specific protocol used... a 'dumb' protocol could use 2 transfers, one to control RS, one for the actual command/data... a 'smart'er protocol could get slimmer by having a virtual command byte transfer optionally followed up by one or more data bytes... i.e. write data command followed by bytes to write, which would then be terminated by a null/zero data byte or i2c stop).  This would also optionally allow to read from the lcd instead of just write to it, meaning the status bit could be used to know when it is ok to send the next command/byte instead of relying on delays that have to be long enough for the worst case + some extra padding.  The disadvantage would be slightly more complex code in the padauk ic and need for an additional client library, but as an advantage, the additional client library should be really simple and smaller than any existing client library.

[tim_]

This is where the lite r1 programmers are stuck Looks like JLCPCBs Europaket is not such a good idea after all. I guess one of the packages they included created a customs issue...

[kaweksl]

I was just pointing out that if the goal is an i2c lcd adapter, there are faster / more efficient ways to drive an lcd over i2c than what the PCF8574 i2c expander allows (even with sequential write).
(...)

Creating dedicated i2c bridge would make sense (for me) only if it would take "high level commands", like setCursor, backlight, printascii,  and push it to lcd. But for that im not sure if we have enough idle time between transferring i2c bytes to do that on the fly, and we can't do parallel processing. So that would require to use:
- buffer and doing conversion after i2c frame, which would require some 'busy' time after each frame, reducing speed
- using clock i2c stretching, which may not be compatible with some masters, also reducing speed
- any ideas ?

And to be honest i have no idea how to drive 1602

This is where the lite r1 programmers are stuck Looks like JLCPCBs Europaket is not such a good idea after all. I guess one of the packages they included created a customs issue...

Is lite version made in easyeda too ?

[serisman]

Here's a fun little project I whipped up on a breadboard today: https://github.com/serisman/pdk-continuity-tester

It is a standalone continuity tester, that uses the Comparator to test for continuity, and has an aggressive battery saving mode (< 0.5 uA while sleeping).

It is a port to the Padauk MCUs of an original project by David Johnson-Davies for the ATtiny85:

• http://www.technoblogy.com/show?1YON
• https://github.com/technoblogy/continuity-tester

I have used the original ATtiny85 version for a few years, and have found it quite useful.  It frees up having to pull out a multimeter to do quick tests for continuity.

I've tested it on the PFS154 and PFS173, but it should also run on (at least) the PMS150C, PMS152, PMS154C as well.

It can even run on the 6-pin variants, and uses less than 100 words of code, and only 2 bytes of ram!

Eventually I will create and share a custom PCB for it as well.

[tim_]

Here's a fun little project I whipped up on a breadboard today: https://github.com/serisman/pdk-continuity-tester

It is a standalone continuity tester, that uses the Comparator to test for continuity, and has an aggressive battery saving mode (< 0.5 uA while sleeping).

That's a really neat project! Honestly, I would not have thought about using a MCU for this in the first place, so it is a good example for a use case of ultra-low-cost MCUs.

I wonder about the usage of the pin change for wakeup: This somehow implies that there is a trickle charge to pull the pin up while the MCU is asleep. So this is valid for both the Padauk MCUs and the ATtiny85?

Btw, one could probably  reduce active power consumption by making everything interrupt driven. But I guess that is inconsequential.

[serisman]

That's a really neat project! Honestly, I would not have thought about using a MCU for this in the first place, so it is a good example for a use case of ultra-low-cost MCUs.

Agreed!  And this is probably cheaper than (most) other approaches as well!  This can run on the 6/8-pin PMS150C (~$0.03) making it cost about the same as a few passives.  The Buzzer/Battery are the most expensive components on the build.

I wonder about the usage of the pin change for wakeup: This somehow implies that there is a trickle charge to pull the pin up while the MCU is asleep. So this is valid for both the Padauk MCUs and the ATtiny85?

Yes, the pull-up on the Probe pin is enabled, as well as the wake-up (i.e. PADIER) for that pin.  I have measured ~0.2-0.3 uA @ 3V while sleeping (using my Keysight 34465A 6.5 digit multimeter).  For a while I was measuring 1000x more sleep current until I also turned off wake-up for all the other pins (i.e. PBDIER).  The ATtiny85 version uses about the same in sleep mode.

Btw, one could probably  reduce active power consumption by making everything interrupt driven. But I guess that is inconsequential.

Not sure how interrupts would actually help here.  I suppose I could remove the idle counter if active power consumption really mattered (i.e. only keep the MCU awake in order to drive the Buzzer/LED while there is continuity), but 99.999% of the active power consumption is going to the Buzzer and power indicator LED.  The MCU itself only uses 0.3 mA (or so) while awake anyway (1MHz @ ~3V).

[tim_]

Btw, one could probably  reduce active power consumption by making everything interrupt driven. But I guess that is inconsequential.

Not sure how interrupts would actually help here.  I suppose I could remove the idle counter if active power consumption really mattered (i.e. only keep the MCU awake in order to drive the Buzzer/LED while there is continuity), but 99.999% of the active power consumption is going to the Buzzer and power indicator LED.  The MCU itself only uses 0.3 mA (or so) while awake anyway (1MHz @ ~3V).

Well, 0.5-1 mA should be enough for the LED, so it is more like 50-70%. But as mentioned, this should be inconsequential.