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.
You mean "setup()" and "main()"? Well ...![]()
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.
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.
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 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 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.
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.
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)
QuoteI 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?
QuoteI 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?
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
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?
ihrcr = *((const unsigned char*)(0x87ed));
// took me hours to find where from the 0x8000 comesI 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.
This was the most diifficult hello world code I've ever seenCode: [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?
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?
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)
I have published some i2c slave code examples for PFS154/PMC150C:
https://github.com/kaweksl/pdk-codebucket
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?
volatile unsigned char c;
void f(void)
{
c |= 0x04;
}
What kind of i2c speed are you able to achieve?
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.
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.
OT: what program was used for creating this type of image?
Bit / reset instructions are working for I/O in SDCC 4.0.2 #11707 now.
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.