spth,
I noticed when I was trying to optimize some of the code examples (specifically the adctest.c example) that certain functions that I am used to using with SDCC didn't seem to be available.
For one, I couldn't find a way to get _ultoa or _utoa to actually work. I did get _uitoa to work for up to 16-bit unsigned ints, but couldn't get the 32-bit or 8-bit optimized versions working. And, none of the smaller sized printf functions seemed to be there either (i.e. printf_tiny, printf_small, printf_fast, etc).
It seems like you are the resident SDCC expert (are you one of the developers?) Do you know if these are known issues where the library code just hasn't been ported yet, or am I doing something wrong? Is there a list of supported library functions somewhere for these pdk devices?
For the "pdkuino.h" does it means that we can program pdk like an Arduino, or even make an Arduino core based on it?
#define PIN_LED PA,4
...
setPinOutput(PIN_LED);
setPinHigh(PIN_LED);
PAC &= ~(1<<4)
PA |= (1<<4)
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?
__sfr __at(0x17) SFR;
void f(void)
{
SFR |= 0x40; // Will use set1
SFR &= 0x7f; // Will use set0
SFR ^= 0x13; // Will use xor IO, a on pdk15
}
spth is the main developer of the PDK support in SDCC.
The printf from the standard includes results in code that is too big to fit into of the Padauk MCUs.
I implemented some size optimized printf-like functions fore debugging here:
https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c
This was with the aim of having a minimal memory overhead for debugging.
One could probably implement a size optimized printf as well. But that needs to tie-in to standard libraries, that have not been set up yet. Your effort should be a good basis to finally tackle this as well.
It just means that SDCC will generate more set0 / set1.
~~~~
\_\_sfr \_\_at(0x17) SFR;
void f(void)
{
SFR |= 0x40; // Will use set1
SFR &= 0x7f; // Will use set0
SFR ^= 0x13; // Will use xor IO, a on pdk15
}
~~~~
__bit would be for variables in data memory, but isn't implemented yet (__sbit would be the equivalent for I/O, not yet implemented either). Also bit-fields still only work for normal objects (as covered by the C standard), not for __sfr I/O i.e. an SDCC extension).
For the "pdkuino.h" does it means that we can program pdk like an Arduino, or even make an Arduino core based on it?
Well, we are pretty far away from that right now.
The biggest obstacle is that Arduino technically uses a C++ compiler, but SDCC is only a C compiler. These PDK devices weren't even really designed with C in mind, let alone C++. It is unlikely there will ever be a C++ compiler, or that it would be worth using if there was one.
[…]
There is also a possibility to integrate the toolchain into the Arduino IDE (although, IMO there are much better IDEs out there). I ran across this the other day, which accomplishes an SDCC toolchain available to import into the Arduino IDE: https://github.com/DeqingSun/ch55xduino
There is still a lot of work to make the software libraries and example programs as clean and easy to use as Arduino provides, but hopefully we can at least start to bridge that gap.
The biggest obstacle is that Arduino technically uses a C++ compiler, but SDCC is only a C compiler. These PDK devices weren't even really designed with C in mind, let alone C++. It is unlikely there will ever be a C++ compiler, or that it would be worth using if there was one.For those who really want C++ on Padauk: There is the LLVM+SDCC toolchain (http://www.colecovision.eu/llvm+sdcc/), but that is experimental stuff that needs more work, and I haven't worked on it since late 2016. AFAIR, back then, I got it to work good enough to put Dhrystone through it, and get it to work on STM8.
There is also a possibility to integrate the toolchain into the Arduino IDE (although, IMO there are much better IDEs out there). I ran across this the other day, which accomplishes an SDCC toolchain available to import into the Arduino IDE: https://github.com/DeqingSun/ch55xduinoYou might also want to have a look at the sduino project, which created an arduion-like using STM8 with SDCC as compiler.
The biggest obstacle is that Arduino technically uses a C++ compiler, but SDCC is only a C compiler. These PDK devices weren't even really designed with C in mind, let alone C++. It is unlikely there will ever be a C++ compiler, or that it would be worth using if there was one.For those who really want C++ on Padauk: There is the LLVM+SDCC toolchain (http://www.colecovision.eu/llvm+sdcc/), but that is experimental stuff that needs more work, and I haven't worked on it since late 2016. AFAIR, back then, I got it to work good enough to put Dhrystone through it, and get it to work on STM8.
Oh interesting. But, I would imagine with the limited RAM and CODE sizes we are dealing with on these Padauk MCUs, that is asking for trouble, right?
spth,
I noticed when I was trying to optimize some of the code examples (specifically the adctest.c example) that certain functions that I am used to using with SDCC didn't seem to be available.
For one, I couldn't find a way to get _ultoa or _utoa to actually work. I did get _uitoa to work for up to 16-bit unsigned ints, but couldn't get the 32-bit or 8-bit optimized versions working. And, none of the smaller sized printf functions seemed to be there either (i.e. printf_tiny, printf_small, printf_fast, etc).
It seems like you are the resident SDCC expert (are you one of the developers?) Do you know if these are known issues where the library code just hasn't been ported yet, or am I doing something wrong? Is there a list of supported library functions somewhere for these pdk devices?
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
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)
All functions from the C standard that are in SDCC headers should just work.
_ultoa, etc are SDCC-specific extensions that just haven't been ported yet (the situation with these needs to first be improved anyway - they are not tested in regression tests, and they have bad names - as compiler-specific extensions hteir names should start with two underscores to not conflict with functions written by the user).
P.S.: I just opened a ticket for these functions: https://sourceforge.net/p/sdcc/bugs/3077/
mov a, p
mov p, a
idxm p, a
ceqsn a, p
etc...
I quickly realized that I was badly missing an easy overview of the available pins and their functions (the overview in the datasheet is not that nice to look at).
Therefore I made a simple tool to generate pinout diagrams. For now, I added diagrams for all PFS173 packages.
The source code is at GitHub; adding diagrams for the other Padauk mikrocontrollers shouldn't be hard, if desired: https://github.com/cmfcmf/ic-pinout-diagram-generator/blob/96578800d1e2ad50d6beccc5705d3ac240b117b6/src/App.js#L5-L226
The main issue right now is that the diagrams are super wide and look bad on smaller screens.
Let me know what you think!
https://christianflach.de/ic-pinout-diagram-generator
The source code is at GitHub; adding diagrams for the other Padauk mikrocontrollers shouldn't be hard, if desired: https://github.com/cmfcmf/ic-pinout-diagram-generator/blob/96578800d1e2ad50d6beccc5705d3ac240b117b6/src/App.js#L5-L226
All functions from the C standard that are in SDCC headers should just work.
_ultoa, etc are SDCC-specific extensions that just haven't been ported yet (the situation with these needs to first be improved anyway - they are not tested in regression tests, and they have bad names - as compiler-specific extensions hteir names should start with two underscores to not conflict with functions written by the user).
P.S.: I just opened a ticket for these functions: https://sourceforge.net/p/sdcc/bugs/3077/
Thanks spth!
An additional question...
When looking at the generated .asm files, I am seeing code like:Code: [Select]mov a, p
mov p, a
idxm p, a
ceqsn a, p
etc...
But, I don't see any reference to a register named 'p' in the datasheets or .INC files. Do you know if this is just a memory address that SDCC reserves for its own use, or an undocumented register, or something else?
//Assuming variables are place in presented order
uint16_t t16counter; // ldt16 will work
uint8_t somevar;
uint16_t sect16count; //ldt16 will fail, not aligned
uint8_t secsome;
uint16_t tht16count; //ldt16 will work
One thought... Since you are color-coding the blocks, you don't necessarily need to keep them in aligned columns. That would reduce the width a bit.
It would be great to have these published to https://free-pdk.github.io/ (https://github.com/free-pdk/free-pdk.github.io). If would be nice to have a page per IC with pinout diagrams and other useful information.
Hi cmfcmf,
Very nice. Is it possible to generalise it for other MCUs, maybe take the input data from a file, and an easier way to edit? A generator-generator?
One thought... Since you are color-coding the blocks, you don't necessarily need to keep them in aligned columns. That would reduce the width a bit.
It would be great to have these published to https://free-pdk.github.io/ (https://github.com/free-pdk/free-pdk.github.io). If would be nice to have a page per IC with pinout diagrams and other useful information.
I have added an option to adjust the font size and toggle between "aligned" and "dense" mode as well as download buttons.
I agree that the diagrams should be on https://free-pdk.github.io/. I think it would make a lot of sense to use GitHub's Jekyll integration to generate the documentation pages from Markdown instead of writing plain HTML.
I'll see if I can get something nice to work.
When looking at the generated .asm files, I am seeing code like:Code: [Select]mov a, p
mov p, a
idxm p, a
ceqsn a, p
etc...
But, I don't see any reference to a register named 'p' in the datasheets or .INC files. Do you know if this is just a memory address that SDCC reserves for its own use, or an undocumented register, or something else?
p is a "pseudo-register", i.e. a memory location handled by the compiler as if it was a register. It is physically located at address 0 (which means we know it is aligned, and in the lower half of the address space, so all instructions work on this location).
P.S.: In retrospective, I think more pseudo-registers should be used. But this is a trade-off: More pseudo-registers allow SDCC to generate better code, but they also need to be saved at interrupts, increasing interrupt latency. Still, I now think the sweet spot is at 3 consecutive bytes of pseudo.registers, starting at address 0 (that way, one could have p0, p1, p2. p0 together with p1 would be used for access to the 16-bit timer and for ldtabl. Having both p0 and p2 would allow more efficient copies between two stack locations). But changing the number of pseudo-registers is a long-term thing, and also needs to be coordinated with future pdk16 support.
Is it safe to assume that 'p' can be modified in an inline assembly method without worrying about saving/restoring? i.e. does the caller already save/restore 'p' if it uses it, or should the callee do the save/restore?
One thought... Since you are color-coding the blocks, you don't necessarily need to keep them in aligned columns. That would reduce the width a bit.
It would be great to have these published to https://free-pdk.github.io/ (https://github.com/free-pdk/free-pdk.github.io). If would be nice to have a page per IC with pinout diagrams and other useful information.
I have added an option to adjust the font size and toggle between "aligned" and "dense" mode as well as download buttons.
I agree that the diagrams should be on https://free-pdk.github.io/. I think it would make a lot of sense to use GitHub's Jekyll integration to generate the documentation pages from Markdown instead of writing plain HTML.
I'll see if I can get something nice to work.
Jekyll would be great. We could then also use that space for instruction/tutorials.
One thought... Since you are color-coding the blocks, you don't necessarily need to keep them in aligned columns. That would reduce the width a bit.
It would be great to have these published to https://free-pdk.github.io/ (https://github.com/free-pdk/free-pdk.github.io). If would be nice to have a page per IC with pinout diagrams and other useful information.
I have added an option to adjust the font size and toggle between "aligned" and "dense" mode as well as download buttons.
I agree that the diagrams should be on https://free-pdk.github.io/. I think it would make a lot of sense to use GitHub's Jekyll integration to generate the documentation pages from Markdown instead of writing plain HTML.
I'll see if I can get something nice to work.
Jekyll would be great. We could then also use that space for instruction/tutorials.
I have created a PR [1] that introduces a new design for https://free-pdk.github.io/ and also integrates the pinout diagrams as well as an overview of the many different free-pdk repositories. There is a lot of room for further improvements, but this should get the ball rolling when it comes to tutorials and more detailed instructions. Adding pages is as easy as adding new markdown files (no more HTML ).
I have not yet added any information on the SDCC examples and headers, since that is an ongoing discussion.
[1] https://github.com/free-pdk/free-pdk.github.io/pull/3
I have created a PR [1] that introduces a new design for https://free-pdk.github.io/ and also integrates the pinout diagrams as well as an overview of the many different free-pdk repositories. There is a lot of room for further improvements, but this should get the ball rolling when it comes to tutorials and more detailed instructions. Adding pages is as easy as adding new markdown files (no more HTML ).
I have not yet added any information on the SDCC examples and headers, since that is an ongoing discussion.
[1] https://github.com/free-pdk/free-pdk.github.io/pull/3