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

0 Members and 1 Guest are viewing this topic.

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #975 on: June 30, 2020, 07:17:54 am »
Code: [Select]
setPinOutput(PIN_LED2);We, of course don't have to do anything.  ;)  That code is easily changeable if/when something better is available.

If you don't like that, don't look at some of the more recent updates I just pushed.  >:D

You mean "setup()" and "main()"? Well ... :)


Yep, I was referring to the #include "pdkuino.h" at the top that moves main() out of the main .c file and assumes you will instead implement setup() and loop() methods.   >:D

Of course an optional Arduino-like include could not hurt.

But I was thinking there is a lack of consistency in the general toolchains that exist around PDK. It would be good to have at least one point of reference that we can all agree on extending on together. (olbigatory: https://xkcd.com/927/)

There are now at least 4 different repositories that have examples sitting somewhere in a deeply nested folder. All of them based on a different set of system includes. But as someone wanting to start development, it is simply a pain to find somethign that is consistent.


I agree.  But we aren't there yet.  I did start working on a refactoring of the include files on a branch in the easy-pdk-programmer-software repo earlier today, with a goal of trying to clean it up a bit, make it more extensible, and separate out the easy-pdk specific code from the more general pdk stuff that maybe could eventually be packaged into SDCC.  If you have a chance, take a look and provide feedback on the (work-in-progress) pull request: https://github.com/free-pdk/easy-pdk-programmer-software/pull/33.  Please keep in mind this isn't 'finished' or 'ready to use' yet, and maybe not all the ideas I was playing around with are good ideas, so please be gentle.  ;D

Even if I do go the pdkuino route with my repo, it would ideally just be a layer on top of the base pdk include files, not a replacement for them.

For example, there are still glaring issues when trying to use "printf" (Some of the examples use "puts" for a reason) . I implemented some optimized routines that took a lot of effort, to be at least able to do basic printf-style debugging (https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c), but there is simply no place to put them oither than my own repositiy.

I also still don't know how to build a librariy with conditional linking of functions to be able to cope with the limited program memory.

Yeah, the limited resources are definitely something we have to find a way to manage.  I haven't tried to use printf-style debugging yet, mostly because I assumed it would be too resource intensive.  For the things I have been playing around with so far, a logic analyzer is actually more useful anyway.

For SDCC, the only way I have found for it to have conditional linking (or exclusion of unused functions) is if each one is in it's own file and compiled into a library.  I think the SDCC manual mentions that somewhere.  My toolchain is setup in this fashion, although it's hard to see it working since I only have one library file checked in so far.

Could we agree on starting a new repository on "free-pdk" that contains a central repository for the toolchain and examples? (Also looking at JS and Phillipp)

I personally don't have access to the free-pdk repos to start something like that, but would be happy to collaborate there if that was setup.
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #976 on: June 30, 2020, 07:34:45 am »
I got my dev boards in the mail today, and soldered one up with a PFS173-S16 this evening.  I'll build another one with a PFS154-S16 later.

I built up another one, this time with a PFS154-S16 and a 2x4 IDC connector.

1013308-0 1013312-1

I used 22k resistors for all the LEDs on this one, but for some reason I can't program it at all with any resistor on the PA6 pin (I also tried 33k and 47k).  It could be that the IDC cable has higher resistance, or maybe the PFS154 is more sensitive than the PFS173, or maybe using 22k instead of 10k resistors on the other pins is affecting it in some way.  I'll have to do more testing later, but just taking the one resistor off makes it work again (although the LED won't work without it).

I think I like this IDC connector version better after all.  It is a bit easier to connect/disconnect and a bit lower profile.

1013316-2
 
The following users thanked this post: icraftcrafts

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #977 on: June 30, 2020, 07:35:33 am »
I agree.  But we aren't there yet.  I did start working on a refactoring of the include files on a branch in the easy-pdk-programmer-software repo earlier today, with a goal of trying to clean it up a bit, make it more extensible, and separate out the easy-pdk specific code from the more general pdk stuff that maybe could eventually be packaged into SDCC.  If you have a chance, take a look and provide feedback on the (work-in-progress) pull request: https://github.com/free-pdk/easy-pdk-programmer-software/pull/33.  Please keep in mind this isn't 'finished' or 'ready to use' yet, and maybe not all the ideas I was playing around with are good ideas, so please be gentle.  ;D

Even if I do go the pdkuino route with my repo, it would ideally just be a layer on top of the base pdk include files, not a replacement for them.
Sounds reasonable

Quote
For example, there are still glaring issues when trying to use "printf" (Some of the examples use "puts" for a reason) . I implemented some optimized routines that took a lot of effort, to be at least able to do basic printf-style debugging (https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c), but there is simply no place to put them oither than my own repositiy.

I also still don't know how to build a librariy with conditional linking of functions to be able to cope with the limited program memory.

Yeah, the limited resources are definitely something we have to find a way to manage.  I haven't tried to use printf-style debugging yet, mostly because I assumed it would be too resource intensive.  For the things I have been playing around with so far, a logic analyzer is actually more useful anyway.

For SDCC, the only way I have found for it to have conditional linking (or exclusion of unused functions) is if each one is in it's own file and compiled into a library.  I think the SDCC manual mentions that somewhere.  My toolchain is setup in this fashion, although it's hard to see it working since I only have one library file checked in so far.

Ah, I have to look into this. This requires careful planning of the overall structure.

Quote
Could we agree on starting a new repository on "free-pdk" that contains a central repository for the toolchain and examples? (Also looking at JS and Phillipp)

I personally don't have access to the free-pdk repos to start something like that, but would be happy to collaborate there if that was setup.

Perfect :)
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #978 on: June 30, 2020, 07:39:36 am »
Quote
I used 22k resistors for all the LEDs on this one, but for some reason I can't program it at all with any resistor on the PA6 pin (I also tried 33k and 47k).  It could be that the IDC cable has higher resistance, or maybe the PFS154 is more sensitive than the PFS173, or maybe using 22k instead of 10k resistors on the other pins is affecting it in some way.  I'll have to do more testing later, but just taking the one resistor off makes it work again (although the LED won't work without it).
(Attachment Link)

Have you looked at the voltage levels on PA6 with a scope? Btw, is your resistor pulling up or down?
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #979 on: June 30, 2020, 07:43:43 am »
Quote
I used 22k resistors for all the LEDs on this one, but for some reason I can't program it at all with any resistor on the PA6 pin (I also tried 33k and 47k).  It could be that the IDC cable has higher resistance, or maybe the PFS154 is more sensitive than the PFS173, or maybe using 22k instead of 10k resistors on the other pins is affecting it in some way.  I'll have to do more testing later, but just taking the one resistor off makes it work again (although the LED won't work without it).
(Attachment Link)

Have you looked at the voltage levels on PA6 with a scope? Btw, is your resistor pulling up or down?

I haven't.  I probably need a new scope.  Mine is ancient (a really old Tektronix 2213A - 60MHz analog crt scope) and kind of a pain to use.  I've been thinking about getting a newer digital storage scope for a while now.  Have any recommendations for a reasonable one?

The resistors are pull-up.

1013324-0
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #980 on: June 30, 2020, 07:59:52 am »
Quote
I used 22k resistors for all the LEDs on this one, but for some reason I can't program it at all with any resistor on the PA6 pin (I also tried 33k and 47k).  It could be that the IDC cable has higher resistance, or maybe the PFS154 is more sensitive than the PFS173, or maybe using 22k instead of 10k resistors on the other pins is affecting it in some way.  I'll have to do more testing later, but just taking the one resistor off makes it work again (although the LED won't work without it).
(Attachment Link)

Have you looked at the voltage levels on PA6 with a scope? Btw, is your resistor pulling up or down?

I haven't.  I probably need a new scope.  Mine is ancient (a really old Tektronix 2213A - 60MHz analog crt scope) and kind of a pain to use.  I've been thinking about getting a newer digital storage scope for a while now.  Have any recommendations for a reasonable one?

The resistors are pull-up.

(Attachment Link)

Hm... the combination of pull-up (your board) and pull-down on PA5 (programmer) will surely lead to an undefined potential between GND and VDD. The impedance on PA6 should be high enough, though. No obvious reason why it would not work?

Edit: Regarding scope: I have been happy enough with lower end Rigol. I will receive a new MSO5074 in a few days, I hope it's worth the investment.

« Last Edit: June 30, 2020, 08:56:45 am by tim_ »
 

Offline greenpossum

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: au
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #981 on: June 30, 2020, 01:55:29 pm »
I just like to express my appreciation of you guys spurring each other on to improvements and simplifications. I hope to join the party one of these months.  :-+
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #982 on: June 30, 2020, 06:25:11 pm »
Hello!

I made an 8 pins Padauk micro breakout board. I want to share my design with you guys so you guys can use it. It was designed with EasyPDK programmer in mind.

preview: https://imgur.com/a/12QWAbP

https://easyeda.com/LovelyA72/ezpdk8
« Last Edit: June 30, 2020, 06:30:54 pm by LovelyA72 »
Kashikoma!
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #983 on: June 30, 2020, 06:27:20 pm »
Hm... the combination of pull-up (your board) and pull-down on PA5 (programmer) will surely lead to an undefined potential between GND and VDD. The impedance on PA6 should be high enough, though. No obvious reason why it would not work?

I'm actually thinking I might spin a new version of the board that uses a CD4053 (3x 2-channel analog mutiplexer/demultiplexer) to provide 2-way disconnection of PA3 (ICPCK), PA5 (ICVPP), and PA6 (ICPDA).  It would probably be controlled by a switch/button.  So, in idle state, the PA3/5/6 MCU pins would only be connected to the board header pins, but when pressed the PA3/5/6 MCU pins would only be connected to the programmer.  That would still leave GND, VDD, PA0, PA4, PA7 connected to the programmer full time, which I think means we can still 'run' the program from the programmer and perform Tx/Rx.  The real challenge is fitting the CD4053 on the board without growing it too much.
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #984 on: June 30, 2020, 06:32:16 pm »
I made an 8 pins Padauk micro breakout board. I want to share my design with you guys so you guys can use it.

https://easyeda.com/LovelyA72/ezpdk8

Thanks for sharing.  It looks pretty basic, the only additional component appears to be a bypass capacitor.  Can you explain your thoughts on why you prefer this over just using a generic SOP-8/16 adapter PCB or SOP-8/16 ZIF socket to DIP8/16 adapter?
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #985 on: June 30, 2020, 06:36:36 pm »
I made an 8 pins Padauk micro breakout board. I want to share my design with you guys so you guys can use it.

https://easyeda.com/LovelyA72/ezpdk8

Thanks for sharing.  It looks pretty basic, the only additional component appears to be a bypass capacitor.  Can you explain your thoughts on why you prefer this over just using a generic SOP-8/16 adapter PCB or SOP-8/16 ZIF socket to DIP8/16 adapter?
It acts as an adapter board between SOP and DIP. Also, since most of the padauk micros are OTP, I can write the name of the program on the board with a sharpie(white silkscreen area). It also marks the pinout for the chip to make the chip more convenient to work with.
« Last Edit: June 30, 2020, 07:09:28 pm by LovelyA72 »
Kashikoma!
 

Offline NickE

  • Contributor
  • Posts: 20
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #986 on: July 01, 2020, 07:38:01 pm »
I also built the free-pdk programmer and started to learn Padauk microcontroller. I finished reading PFS154 datasheet and SDCC manual.
A few parts are pretty challenging for beginners, for example the calibration..., it took me almost a whole day to figure out how the hello world program works.  :phew:

This was the most diifficult hello world code I've ever seen :)
Code: [Select]
ihrcr = *((const unsigned char*)(0x87ed)); // took me hours to find where from the 0x8000 comes
https://github.com/free-pdk/sdcc-pdk-code-examples/blob/master/hello-s16/hello.c

I don't complain, I am very happy to find this topic, you guys made excellent job.

Anyway I am not sure for beginners it is a good idea to start with SDCC. Are there any pure assembler available for this MCU for those who don't want to buy the Padauk programmer?
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #987 on: July 01, 2020, 07:42:44 pm »
I also built the free-pdk programmer and started to learn Padauk microcontroller. I finished reading PFS154 datasheet and SDCC manual.
A few parts are pretty challenging for beginners, for example the calibration..., it took me almost a whole day to figure out how the hello world program works.  :phew:

This was the most diifficult hello world code I've ever seen :)
Code: [Select]
ihrcr = *((const unsigned char*)(0x87ed)); // took me hours to find where from the 0x8000 comes
https://github.com/free-pdk/sdcc-pdk-code-examples/blob/master/hello-s16/hello.c

I don't complain, I am very happy to find this topic, you guys made excellent job.

Anyway I am not sure for beginners it is a good idea to start with SDCC. Are there any pure assembler available for this MCU for those who don't want to buy the Padauk programmer?

Have you seen the Examples directory in the easy-pdk-programmer-software repo?

e.g. https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/helloworld.c

At the very least, there are macros for easier calibration and defines for registers and their values.

Work is underway to try and standardize include files and example programs: (e.g. https://github.com/free-pdk/easy-pdk-programmer-software/pull/33)
« Last Edit: July 01, 2020, 07:48:41 pm by serisman »
 
The following users thanked this post: icraftcrafts

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #988 on: July 01, 2020, 07:46:19 pm »
Anyway I am not sure for beginners it is a good idea to start with SDCC. Are there any pure assembler available for this MCU for those who don't want to buy the Padauk programmer?

Well, there are the assemblers that come with SDCC…
 

Offline kaweksl

  • Contributor
  • Posts: 18
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #989 on: July 02, 2020, 12:20:35 am »
I have published some i2c slave code examples for PFS154/PMC150C:

https://github.com/kaweksl/pdk-codebucket
 
The following users thanked this post: serisman

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #990 on: July 02, 2020, 03:06:20 am »
Hi!
I opened a pull request at https://github.com/free-pdk/free-pdk.github.io/pull/2
This is a basic responsive improvement on the website and it makes the website mobile friendly.
Before:


After:


thank you!
Kashikoma!
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #991 on: July 02, 2020, 04:14:53 am »
Work is underway to try and standardize include files and example programs: (e.g. https://github.com/free-pdk/easy-pdk-programmer-software/pull/33)

JS, spth, tim_, and others...

I have just completed a major refactoring of the include files (and Examples) from the easy-pdk-programmer-software repo, and am asking for community review as this point.
https://github.com/free-pdk/easy-pdk-programmer-software/pull/33

The goals as stated in the pull request are:
  • Provide better separation of generic PDK device/peripheral definitions from the more specific easy-pdk-programmer things (i.e. calibration)
  • Provide an easier and more standard way to add new devices
  • When/If approved, the desire is for this to be the new defacto standard set of include files so existing repos can be updated and we have a single standard and source of truth going forward.  We have had some discussion about moving this to the new https://github.com/free-pdk/free-pdk-examples repo once approved.
  • Hopefully SDCC will eventually be able to include the pdk/ includes directory out of the box at some point!



Here is an overview of the changes introduced and the directory structure:
The easy-pdk/ directory contains things that are specific to the easy-pdk-programmer including:
  • easy-pdk/calibration.h - IHRC/ILRC/BG calibration routines
  • easy-pdk/serial_num.h - Setting of a unique Serial Number during programming

The pdk/ directory contains things that are programmer agnostic (i.e. don't assume or require the easy-pdk-programmer)
  • The goal is to eventually get SDCC to include this by default!
  • pdk/device.h - The main include that pulls in the appropriate device/XXX.h include file and other supporting files.
  • pdk/device/XXX.h - One include file per device, and the appropriate include file is pulled in automatically by pdk/device.h. These includes contain device specific configuration values like: register addresses, fuse address/values, factory calibration address(es), peripheral configuration, etc...
  • pdk/device/periph/XXX.h - Common device peripherals. The appropriate include files are pulled in automatically by the pdk/device/XXX.h files. These contain peripheral specific register __sfr and value definitions. When there is enough commonality between devices, they share the same peripheral file (with some configurability allowed), otherwise the peripheral files are split and the pdk/device/XXX.h file pulls in the appropriate one (i.e. misclvr and pwmg).
  • pdk/util.h - This is pulled in automatically by pdk/device.h and includes macros for built in opcode and assembler macros
  • pdk/fuse.h - This is pulled in automatically by pdk/device.h and includes a macro for setting the FUSE word at the appropriate address if the device specific pdk/device/XXX.h defined a FUSE address and FUSE values.
    • This seems generic enough to not get moved to the easy-pdk/ directory because all it does is set a specific word value at a specific pre-defined address. It doesn't necessarily imply how the programmer will write the value. (i.e. along with the code, or as a separate post calibration step)
  • pdk/factory_calibration.h - This is pulled in automatically by pdk/device.h and includes macros for using the factory IHRCR and/or BGTR factory calibration values, depending on what the device specific pdk/device/XXX.h defined addresses for.
  • pdk/sysclock.h - This is pulled in automatically by pdk/device.h and includes macros for setting the sysclock to the various IHRC and ILRC frequencies.

I included support for the following devices:
  • PMS150C
  • PMS152
  • PMS171B
  • PFS154
  • PFS172
  • PFS173

Let me know if there are other devices people would like to see included out of the gate.  It is easier to define new devices than before.

One final note... the calibration routines rely on the not yet released feature/newcalibration code that JS has finished up but not yet merged to development branch.  So, testing anything to do with calibration will require pulling down that branch and rebuilding both the firmware and easypdkprog software.
 
The following users thanked this post: icraftcrafts

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #992 on: July 02, 2020, 04:22:33 am »
I have published some i2c slave code examples for PFS154/PMC150C:

https://github.com/kaweksl/pdk-codebucket

Excellent!  Thanks for posting that.

I'll have to check it out later.  i2c slave is definitely on my list of things to try with these ICs.

What kind of i2c speed are you able to achieve?

EDIT:  Those peephole rules look really useful.  I wasn't even aware you could do that with SDCC.  Maybe I'll be able to stop writing inline assembly now!  I wonder what it would take to get SDCC to perform these optimizations by default?
« Last Edit: July 02, 2020, 04:28:47 am by serisman »
 

Offline eliocor

  • Supporter
  • ****
  • Posts: 519
  • Country: it
    • rhodiatoce
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #993 on: July 02, 2020, 08:15:59 am »
OT: what program was used for creating this type of image?
 
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #994 on: July 02, 2020, 09:49:25 am »
EDIT:  Those peephole rules look really useful.  I wasn't even aware you could do that with SDCC.  Maybe I'll be able to stop writing inline assembly now!  I wonder what it would take to get SDCC to perform these optimizations by default?

These rules can't be just added to the rules SDCC applies by default (see sdcc/src/pdk/peeph.def), as in general, they can break stuff. Consider .e.g.

Code: [Select]
volatile unsigned char c;

void f(void)
{
c |= 0x04;
}

The peephole rules from https://github.com/kaweksl/pdk-codebucket/blob/master/peephole_rules/peephole_pdk14.def will "optimize" that into a use of set1. However, the address of c is not known until later at link time. The linker might decide to place c in the upper half of the address space, while set1 only works on the lower half of the address space.

There would be ways to make better use of set1 in SDCC, but it's a bit more complex (involves changes in register allocation, code generation and fixing https://sourceforge.net/p/sdcc/bugs/3075/); I hope to have something working for I/O by the end of the week.
« Last Edit: July 02, 2020, 10:05:36 am by spth »
 

Offline kaweksl

  • Contributor
  • Posts: 18
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #995 on: July 02, 2020, 11:33:40 am »
What kind of i2c speed are you able to achieve?

100kHz only, at 400kHz interrupt fires to late, maybe it could be achieved with constant pulling. Some day i will try make 400kHz address sampling and for rest I would use clock stretching.


The peephole rules from https://github.com/kaweksl/pdk-codebucket/blob/master/peephole_rules/peephole_pdk14.def will "optimize" that into a use of set1. However, the address of c is not known until later at link time. The linker might decide to place c in the upper half of the address space, while set1 only works on the lower half of the address space.

There would be ways to make better use of set1 in SDCC, but it's a bit more complex (involves changes in register allocation, code generation and fixing https://sourceforge.net/p/sdcc/bugs/3075/); I hope to have something working for I/O by the end of the week.


I agree, they can't be placed into sdcc general rules, because of that addressing issue. In code i made a comment about this.
Also assembler gonna complain about not being able to address operations.

Maybe implement in SDCC some keyword (like 'volatile') that would mark variable as bit accessible, then compiler could name this variable differently, so it could be targeted as pattern, linker could also place them at beginning of memory too.
« Last Edit: July 02, 2020, 11:36:01 am by kaweksl »
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #996 on: July 02, 2020, 12:24:28 pm »
There would be ways to make better use of set1 in SDCC, but it's a bit more complex (involves changes in register allocation, code generation and fixing https://sourceforge.net/p/sdcc/bugs/3075/); I hope to have something working for I/O by the end of the week.

Bit / reset instructions are working for I/O in SDCC 4.0.2 #11707 now. Implementing it for memory would be a lot of effort for little gain, so it probably won't be done anytime soon.
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #997 on: July 02, 2020, 10:01:18 pm »
OT: what program was used for creating this type of image?
 


Affinity Designer should do the job. It's a nice software, and I am using it for my design works.
Kashikoma!
 
The following users thanked this post: eliocor

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #998 on: July 03, 2020, 03:27:33 am »
Bit / reset instructions are working for I/O in SDCC 4.0.2 #11707 now.
Oh, that's interesting.   :-+  Does this mean that we can use __bit now (or even bitfields), or just that SDCC will choose to generate more set0/set1 instructions for more case?
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #999 on: July 03, 2020, 03:30:15 am »
What kind of i2c speed are you able to achieve?

100kHz only, at 400kHz interrupt fires to late, maybe it could be achieved with constant pulling. Some day i will try make 400kHz address sampling and for rest I would use clock stretching.


Still, 100kHz is nothing to sneeze at.  That still puts it neck and neck with lots of other dedicated ICs out there.  :-+  Have you tried variable frequencies between 100 kHz and 400 kHz to see where it starts breaking down?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf