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

Electra and 3 Guests are viewing this topic.

Offline bovineck

  • Contributor
  • Posts: 7
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1125 on: July 27, 2020, 08:02:14 am »
Quote
Have you checked voltages with "easypdkprogtest.exe"=?

easypdkprogtest
vdd: 3.62   vpp: 3.62    (vref= 3.27) 

It looks like the 5V rail is not 5V but more like 1.9V. That can't be good - I have struggled the most with the USB connector so I'll keep working on that - but of course there might be a compromised component somewhere. My OpAmp measurements are way different to this:

Quote

Reference voltages when running easypdkprogtest:

                   +-------+
                   |   O   |
(DAC-VPP) 1.18V -> |5  P  4| <- -2.7V
          1.18V -> |6  A  3| <-  2.49V (DAC-VDD)
(VPP)      5.0V <- |7  M  2| <-  2.49V
          14.9V -> |8  P  1| ->  5.0V  (VDD)
                   |      .|
                   +-------+

       

More like this:

Reference voltages when running easypdkprogtest:


                   +-------+
                   |   O   |
(DAC-VPP)   -2V -> |5  P  4| <-  -6V
         -2.42V -> |6  A  3| <-  -0.78V (DAC-VDD)
(VPP)     0.32V <- |7  M  2| <-  -1.44V
          1.69V -> |8  P  1| ->  0.34V  (VDD)
                   |      .|
                   +-------+


I think MKIII is the way to go with lessons learned along the way... :-\

Take care,

OneCircuit

 

Offline daveatol

  • Regular Contributor
  • *
  • Posts: 135
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1126 on: July 27, 2020, 08:39:15 am »
Reference voltages when running easypdkprogtest:


                   +-------+
                   |   O   |
(DAC-VPP)   -2V -> |5  P  4| <-  -6V
         -2.42V -> |6  A  3| <-  -0.78V (DAC-VDD)
(VPP)     0.32V <- |7  M  2| <-  -1.44V
          1.69V -> |8  P  1| ->  0.34V  (VDD)
                   |      .|
                   +-------+


What's up with your 15V supply? It should be going to pin 8 of the opamp, and yours is apparently 1.69V. Is your dc-dc converter disabled, or faulty?
 

Offline bovineck

  • Contributor
  • Posts: 7
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1127 on: July 27, 2020, 11:26:12 am »
Quote
What's up with your 15V supply? It should be going to pin 8 of the opamp, and yours is apparently 1.69V. Is your dc-dc converter disabled, or faulty?

It's a mess for sure - I'm going to start again and hopefully have better success with MKIII.  :-//

Take care,

OneCircuit
 

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1128 on: July 28, 2020, 12:50:04 pm »
In easypdkprog the --securefill option makes only sense at OTP MCUs. Am I right?
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1129 on: July 28, 2020, 05:31:02 pm »
Also the break-out boards, that can be plugged into the programmer, arrived.

Speaking of break-out / adapter boards... I designed some new ones a few days ago:


Gerber files are also available if interested, and I can post all the design files somewhere at some point as well.
« Last Edit: July 28, 2020, 05:40:11 pm by serisman »
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1182
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1130 on: July 30, 2020, 09:55:42 am »
Can we Port avr v-usb Library to Padauk?

https://www.obdev.at/products/vusb/index.html

It's a bit-bang USB library for AVR's ^-^ >:D
I'm a Digital Expert from 8-bits to 64-bits
 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1131 on: July 30, 2020, 12:56:43 pm »
VUSB won't fit into most padauks as they are around 1K ROM and 80 B RAM.

Check CH552 it is low cost, has HW usb and requires only 2 caps to operate.
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1132 on: July 30, 2020, 08:28:12 pm »
VUSB won't fit into most padauks as they are around 1K ROM and 80 B RAM.

tim_ has a project from a few years ago (https://cpldcpu.wordpress.com/2014/03/19/%c2%b5-wire-usb-on-an-attiny-10/) (https://github.com/cpldcpu/u-wire) where he got a subset of the V-USB stack working on an ATtiny10 using 988 bytes of flash and 32 bytes of SRAM.

So, it might actually be possible to get something working on these Padauk MCUs.  It would probably require 'overclocking' and/or using the undocumented 16MHz sysclock mode.  Other than the novelty factor, I'm not sure how useful it would actually be, though.

Quote
Check CH552 it is low cost, has HW usb and requires only 2 caps to operate.

I agree, those are interesting (and inexpensive) MCUs, and have a USB/Serial bootloader so you don't even need a custom programmer.  Or, use the even smaller/cheaper CH551.  There are also the CH554/CH558/CH559 bigger brothers that even have USB host mode.  Being 8051 based, you can still use SDCC as well.
« Last Edit: July 30, 2020, 08:31:49 pm by serisman »
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1182
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1133 on: August 01, 2020, 07:08:28 am »
Quote
Check CH552 it is low cost, has HW usb and requires only 2 caps to operate.
If it can be done on a padauk, it would cost a lot less, It can be replaced for USB to UART.
I'm a Digital Expert from 8-bits to 64-bits
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 143
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1134 on: August 01, 2020, 09:20:35 am »
VUSB won't fit into most padauks as they are around 1K ROM and 80 B RAM.

tim_ has a project from a few years ago (https://cpldcpu.wordpress.com/2014/03/19/%c2%b5-wire-usb-on-an-attiny-10/) (https://github.com/cpldcpu/u-wire) where he got a subset of the V-USB stack working on an ATtiny10 using 988 bytes of flash and 32 bytes of SRAM.

So, it might actually be possible to get something working on these Padauk MCUs.  It would probably require 'overclocking' and/or using the undocumented 16MHz sysclock mode.  Other than the novelty factor, I'm not sure how useful it would actually be, though.

Indeed! That was a fun project. It was even reposted by one of the AVR founders (I think Vergard), so it surprised some people that this is possible, i guess :)

My guess is that an implementation from scratch in assembler could be much smaller. The Padauk instruction set should be quite efficient in handling the bitwrangling needed for USB.

If you are out for an interesting challenge, go for it! I would recommend to get a logic analyzer with USB protocol analysis capability first. Also, this: https://www.beyondlogic.org/usbnutshell/usb1.shtml

I have to second the comments regarding usefullness of software implementations, though. The USB protocoll is based on polling from the host (your PC), so any client has to be able to respond within microseconds all the time. The can be relaxed a bit using the tricks shown above, but regardless it will mean that any kind of firmware on your device has to be written around the USB protocol. I founds this a bit too limiting.
« Last Edit: August 01, 2020, 09:57:17 am by tim_ »
 

Offline Talrey

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1135 on: August 01, 2020, 05:05:58 pm »
Hello everyone. First post here! Apologies if this isn't the right place for this, but this thread seemed to be the most active place for discussing the Padauk OSH efforts.

I put in an order on LCSC for the parts list as given on the free-pdk hardware github, but now it's sitting in inquiry limbo. It looks like there's a couple items listed as "Backorder" with one even being listed as "Unavailable, please remove it." I'm new to LCSC, is there a way to replace these parts with possible equivalents in the order or will I have to start from a fresh order? I'm leery of making two orders given shipping costs.

Ironically, I got an email from OshPark that they'd upgraded my order to their super fast turnaround service for free, due to space on a panel... so now I'm going to get the blank boards way ahead of time!
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1136 on: August 01, 2020, 05:13:18 pm »
I finally designed a PCB for my Padauk based 7-segment digital clock.

I also moved the project to its own repository and added some README files:
https://github.com/serisman/pdk-digital-clock

It will take about two weeks before the PCBs are delivered to me, but I feel pretty confident in the design.  I've been running it on a breadboard for a few weeks now.

Feel free to suggest new 'features' or make pull requests with enhancements or bug fixes.

My PCBs were delivered yesterday, and I promptly built one up (used a OTP PMS152-S16):

Front (before installing 7-segment display):
[attach=1]

Back:
[attach=2]

Installed on monitor (and working):
[attach=3]


I am pretty happy with the results, and am calling this project done (at least for version 1).

I updated the github repo with a BOM for anyone interested.
 

Offline bovineck

  • Contributor
  • Posts: 7
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1137 on: August 01, 2020, 11:35:28 pm »
I had the same problem and had to split my order between LCSC and AliExpress. In the end the parts required for the programmer came from both suppliers at about the same time. The difficult part for me hasn’t been the acquisition of parts, but soldering those pesky SMD components (the USB connector is challenging). At this stage I’ve trashed two PCBs in the process, but the third one is looking good!

OneCircuit
www.onecircuit.blogspot.com
 

Offline Talrey

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1138 on: August 02, 2020, 02:02:13 am »
Thanks for the tip, bovineck. Unfortunately, I have to call my bank to approve the payment on AliEx for some reason, and the robot that answered my phone call curtly informed me that the office was closed and hung up on me!  :-DD   |O

Ah well. I'm being cheap on the shipping from LCSC so I've got plenty of time to sort it all out. Excited to dip into this Padauk stuff for real when it does! It's been on my radar since the original EEVBlog vid on it, but I'd always figured ATTiny85s were a better go-to until recently. I'm planning some things with lots and lots of blinkenlights and it felt wasteful to stuff the project full of Atmels when all those fancy features (and the reprogramming) weren't necessary for the design.
 

Offline bovineck

  • Contributor
  • Posts: 7
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1139 on: August 02, 2020, 02:49:21 am »
I use a prepaid debit card, load with cash at the P.O., then off to the interwebs for shopping. I too am looking forward to getting a working programmer. It’s been a journey, and my soldering skills have definitely improved! 🧐
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 235
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1140 on: August 03, 2020, 03:08:25 pm »
I have a very nice hacking project with a commercial product using a PADAUK MCU coming soon.

Teaser:
000000011001001010000100100001000110010010000100100001001001010010000100
000000011001001010000100011001001000010010000100100001001001010010000100
000000011001001010000100100001001000010001100100100001001001010010000100
000000010101010110000100100001001000010010000100100001001001010010000100


8)

JS
« Last Edit: August 03, 2020, 08:10:25 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline LovelyA72

  • Contributor
  • Posts: 22
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1141 on: August 05, 2020, 06:21:06 am »
I am trying to implement tone function.
I am looking for a way to do microseconds delay (like delayMicroseconds() in Arduino). However, existing delay functions are either for milliseconds only or way too large and use all the SRAM.

Any help would be greatly appriciated!
Kashikoma!
 

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1142 on: August 05, 2020, 08:55:03 am »
Just execute a few nop instruction. You can put them into a function.
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1182
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1143 on: August 05, 2020, 09:26:24 am »
Quote
000000011001001010000100100001000110010010000100100001001001010010000100
000000011001001010000100011001001000010010000100100001001001010010000100
000000011001001010000100100001001000010001100100100001001001010010000100
000000010101010110000100100001001000010010000100100001001001010010000100
It's a beauty >:D ^-^
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 235
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1144 on: August 05, 2020, 10:21:01 am »
Quote
000000011001001010000100100001000110010010000100100001001001010010000100
000000011001001010000100011001001000010010000100100001001001010010000100
000000011001001010000100100001001000010001100100100001001001010010000100
000000010101010110000100100001001000010010000100100001001001010010000100
It's a beauty >:D ^-^

Indeed  8) SOON more details !!!!!!! I got it running.  8)

I had a though time to find out some fact NOT mentioned in PFS154/PMS154 datasheet:
TM3 and PWGM2 share the same interrupt flag.
This means if you have TM3 and PWMG1 enabled, you will get interrupt requests from BOTH.
COMP and PWMG1 also share one interrupt flag.

Only the PFS154.INC header file reveals this:

Code: [Select]
INTEN IO_RW 0x04
$ 7 @4 : X, TM3 | PWMG2
$ 4 @3 : X, COMP | PWMG1

So my timing calculations been always half/double of what I expected.  |O |O |O |O |O |O |O


With the correct timing calculation I found the bit rate to be 1736 bits/sec  8)


JS
« Last Edit: August 05, 2020, 10:23:43 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1145 on: August 06, 2020, 01:27:14 am »
I am trying to implement tone function.
I am looking for a way to do microseconds delay (like delayMicroseconds() in Arduino). However, existing delay functions are either for milliseconds only or way too large and use all the SRAM.

Any help would be greatly appriciated!

The delay.h file from the free-pdk-examples repo (https://github.com/free-pdk/free-pdk-examples/blob/master/include/delay.h) has a _delay_us(us) macro in addition to the _delay_ms(ms) macro and only uses up (at most) 7 bytes of SRAM (less if you comment out the delay loop methods that aren't needed).

If you already tried using that delay.h file and are still running out of SRAM, it could be one of the following issues:
  • Possibly there is a bug in the version of SDCC you are using?  Try the latest nightly.
  • If you are including delay.h in multiple .c source files, each one seems to get their own allocation of the method parameters for some reason.  The file should really be broken out to separate delay.h and delay.c files to fix this.  I'll update the examples repo at some point.
 
The following users thanked this post: LovelyA72

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1146 on: August 06, 2020, 01:57:37 am »
So, here's my new rapid prototyping adapter and setup:


I am finding this setup much easier/quicker than anything else I have tried to date, including a dedicated 'dev board'.
« Last Edit: August 06, 2020, 02:04:13 am by serisman »
 

Offline LovelyA72

  • Contributor
  • Posts: 22
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1147 on: August 06, 2020, 10:20:19 pm »
The delay.h file from the free-pdk-examples repo (https://github.com/free-pdk/free-pdk-examples/blob/master/include/delay.h) has a _delay_us(us) macro in addition to the _delay_ms(ms) macro and only uses up (at most) 7 bytes of SRAM (less if you comment out the delay loop methods that aren't needed).

If you already tried using that delay.h file and are still running out of SRAM, it could be one of the following issues:
  • Possibly there is a bug in the version of SDCC you are using?  Try the latest nightly.
  • If you are including delay.h in multiple .c source files, each one seems to get their own allocation of the method parameters for some reason.  The file should really be broken out to separate delay.h and delay.c files to fix this.  I'll update the examples repo at some point.

Thank you for the advice! However, Even I stripped the delay.h to the smallest possible, I still got a SRAM full error.
Here is my source code: https://gist.github.com/Kashouryo/fcf1a8a6995ab7934b9abf936646f6ad
||ASlink-Warning-RAM value 134 too large (128B max)|

Thank you!
Kashikoma!
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1148 on: August 06, 2020, 10:41:43 pm »
Thank you for the advice! However, Even I stripped the delay.h to the smallest possible, I still got a SRAM full error.
Here is my source code: https://gist.github.com/Kashouryo/fcf1a8a6995ab7934b9abf936646f6ad
||ASlink-Warning-RAM value 134 too large (128B max)|

Ok, I see the problem now.

The _delay_us(us) macro is meant to be used with constants that are used to calculate the correct number of delay cycles at build time, not variables that would require the calculation at run-time.

So, use this:
Code: [Select]
_delay_us(100);

... instead of this:
Code: [Select]
uint8_t testVal = 100;
_delay_us(testVal);

If you really need something that is more variable at run-time you will have to come up with a different solution.

It looks like you are running at 1MHz, so each cycle is already 1uS.  So, technically you could skip all the 'calculation' and just call the delay loop directly.  But, there is overhead in calling the delay function as well as the delay loop (7 cycles overhead, 3 cycles per loop) that would still have to be taken into account.

For short delays, you don't really need the abstraction that the delay function provides, you could just directly do something like the following (inline assembly), but you still have to take into account the overhead (3 cycles overhead (2+1), 3 cycles per loop).
Code: [Select]
  uint8_t testVal = 32;         // 2 cycles - value = ((100uS -3) /3)
__asm
00001$:                             // 3 cycles per loop
  dzsn   _testVal                  // 1 cycle + 1 cycle for final skip
    goto 00001$                   // 2 cycles
__endasm;
You might be able to put some/most of this in a macro and/or possibly SDCC would already generate optimal loop code by just using a while (--testVal); loop or something similar.

Do you have a more complete example of what you are trying to accomplish?
« Last Edit: August 06, 2020, 10:46:21 pm by serisman »
 

Offline LovelyA72

  • Contributor
  • Posts: 22
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1149 on: August 07, 2020, 01:45:23 am »
Do you have a more complete example of what you are trying to accomplish?
I am trying to implement an Arduino-like tone function that outputs a specific frequently on a pin.
Kashikoma!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf