something worth mentioning in the newer padauk IDE. They are using a key and response system for the customer service to unlock clients that can not connect to the internet. Might be a fun investigation if someone is interested. The way to access the unlock dialog is to run a fresh IDE without internet connection and click Help > News
So the new IDE is locked down? It really seems that Padauk is not appreciating the open market...
I am having a good time with the CH32V003. It's a minimal RISC-V (RV32EC) microcontroller that is only $0.10 and comes with an excellent free toolchain. Not to speak of an overabundance of periphery including DMA...
also, seems like they just released some MCU with EEPROM or lithium charger.
They are also planning to release some hall effect switches next year.
I want to program PFC161 using freePDK hardware. For this I need to use the development branch. Using the firmware of master branch does not support in development branch. But there is no
EASYPDKPROG.dfu file in this branch. Where can I get it?
Reply to self
The problem is understood but not solved. The chip has no issue and identifies correctly
Our motherboard has 'just' a 10k pullup to the Padauk supply on the programming pins, but that already causes the programming interface to get wrong bits apparently and fail. I assume its some critical timing in the programmer firmware, a 10k pullup should actually not have any influence on a digital signal like that programming data pin.
We use easypdk 'lite' with 100 ohm series resistors in the programming lines, removing those does not change anything.
Johannes
uint32_t FPDK_ProbeIC(FPDKICTYPE* type, uint32_t* vpp_cmd, uint32_t* vdd_cmd)
{
//try to get IC with low voltages
*vpp_cmd = 4500; *vdd_cmd = 2000;
...
You can try to increase those values slightly to compensate for pull ups / downs in your circuit. E.g. try to set vpp_cmd to 5500 and vdd_cmd to 2500 or 3000 and check if probing is working with your circuit. Note: This is just for the probe command. { .name = "PFC154",
.otpid = 0x2AA5,
.id12bit = 0x34A,
.type = FPDK_IC_FLASH,
.addressbits = 13,
...
.vdd_cmd_read = 2.5,
.vpp_cmd_read = 5.5,
.vdd_read_hv = 2.5,
.vpp_read_hv = 5.5,
...
.vdd_cmd_write = 2.5,
.vpp_cmd_write = 5.5,
.vdd_write_hv = 5.5,
.vpp_write_hv = 0.0,
...
Hi JS,
i can send you PFS122 via DHL quickly (within europe), we bought a good quantity of -S16 and -U08
I have quite some parts stocked now in Portugal - i believe in using those padauks for several projects, so we bought stock to have them.
Plus - i want to use them commercially so happy to send you a bounty to get this moving.
Johannes
I did some more investigation about the programming problem with the pullup on the padauk PFC154 ('in circuit programming').
My suspicion proves correct, it is the pullup on the data line (PA6). The other pins used for programming are not affected.
It is super easy to reproduce, if you just add a 10kOhm pullup between PA6 and VDD on a sip test socket with a PFC154 and plug that to easyprog lite. it cannot identify the chip properly.
The error seems to be just in the last bit of the ID, and with the scope i verified that the levels of the bits seem correct.
So my assumption is that this can be fixed in software on easyprog, it is probably an issue of sampling timing of the answer, and it is not an issue of the padauk pin (not being able to drive against 10k or the like).
attached
- picture of setup (with easyprog and pfc154 and the pullup)
- picture of signals on scope without pullup
- picture of signals on scope with pullup.
I dont know the exact serial programming protocol of the padauk, but i can investigate into the firmware of the programmer and probably figure this out, however, i assume some of you are much faster on this.
Johannes
OK, so i have a full feature I2C implementation, interrupt based, working.
It simulates the usual PCF8574 but it also 'makes' a second device with 16 generic registers plus some readonly info for identification.
All works 100% in interrupt context, so the 'main' program is free for other functions.
There is a 'notification callback' when the PCF8574 is written so the main program can take action.
I will test the code a bit and clean it up. I will eventually publish it as open source, if someone is interested i can share it now.
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. So if a specific bit (in my case i2c data) is set to 0, but 'input', the set bit instruction on any other IO bit in that port will result .. in the 0 being changed to 1 (by readback of the input with '1 value and write out). It is logical but caught me ..
last comment (actually this is a question): i would like to use the "SWAPC" instruction, but did not get that to compile (well .. assemble). Is that maybe missing or is there a specific syntax i am missing ?
I tried SWAPC and also SWAPC.io, neither worked.
Cheers
Johannes
Checking OTP_ID we learn:
PFS121, PFS122, PFS172, PFS172B are all the SAME IC.
PFS123, PFS173, PFS173B are all the SAME IC
So looks like PFS122 support was there all the time
JS
OK, so i have a full feature I2C implementation, interrupt based, working.
It simulates the usual PCF8574 but it also 'makes' a second device with 16 generic registers plus some readonly info for identification.
All works 100% in interrupt context, so the 'main' program is free for other functions.
There is a 'notification callback' when the PCF8574 is written so the main program can take action.
I will test the code a bit and clean it up. I will eventually publish it as open source, if someone is interested i can share it now.
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. So if a specific bit (in my case i2c data) is set to 0, but 'input', the set bit instruction on any other IO bit in that port will result .. in the 0 being changed to 1 (by readback of the input with '1 value and write out). It is logical but caught me ..
last comment (actually this is a question): i would like to use the "SWAPC" instruction, but did not get that to compile (well .. assemble). Is that maybe missing or is there a specific syntax i am missing ?
I tried SWAPC and also SWAPC.io, neither worked.
Cheers
Johannes
Could you check if you can flash the PFS122 with the easy-pdk-prog with the PFS172 flag.
If that works we can add PFS122 to easy-pdk-prog and have official support!
edit: forget to say flag
You can try the previous version of SDCC to get SWAPC to compile, but they I believe you will have to also revert all the .IO syntax. There is an outstanding bug report about the issue here: https://sourceforge.net/p/sdcc/bugs/3376/. Hopefully it is resolved for the next release.
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.
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)