EEVblog #1144 - Padauk Programmer Reverse Engineering

[serisman]

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?

[LovelyA72]

For the "pdkuino.h" does it means that we can program pdk like an Arduino, or even make an Arduino core based on it?

Btw congratulation on reaching 1000th posts! You guys are doing some incredible jobs!

[tim_]

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?

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.

[serisman]

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.

Also, the limited RAM and program (CODE) size means we have to be much more frugal with how we write code and how libraries are written and used.  A 'simple' thing like printf (ok, not that simple in reality) can already consume more resources than a lot of these devices have.

But, we can make the environment feel a little more at home for those already versed in Arduino.  We can introduce helper macros and libraries that make interfacing with pins and peripherals and external devices look a bit more like Arduino code.  The pdkarduino.h include file in my repo really just introduces setup() and loop() methods so you don't have to manually create them (SDCC, like all C compilers just gives a main() method).  And I have a util.h file that helps us to write code a little more like with Arduino.

So, we can write things like:

Code: [Select]

#define PIN_LED PA,4
...
setPinOutput(PIN_LED);
setPinHigh(PIN_LED);

Instead of something like this:

Code: [Select]

PAC &= ~(1<<4)
PA |= (1<<4)

There are readability and portability improvements by using something like the first more Arduino like example (although I understand not everyone prefers that syntax).

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.

[spth]

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?

It just means that SDCC will generate more set0 / set1.

Code: [Select]

__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).

P.S.: Edited to fix formatting of code (had used the GitHub syntax before, while the syntax for code is different on this forum)

[serisman]

spth is the main developer of the PDK support in SDCC.

Thanks. I was just reading through the SDCC changelog, and definitely saw his name all over the pdk stuff.

The printf from the standard includes results in code that is too big to fit into of the Padauk MCUs.

Well, technically it fits on the PFS173, but even still that is pretty wasteful of its resources.

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.

Yeah, I'll check that out more later.  But it would be nice to have something more accessible (i.e. included with SDCC) for 'standard' methods like 'printing' strings and numbers.

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.

Yeah, that's what I was wondering about.  I have used the printf_small, and printf_tiny, etc... size optimized methods that SDCC has in the past.  I thought they were available for all devices, but it looks like they were only created for MCS51 (or maybe a few more, but definitely not all?).  I wonder how big of an undertaking that would be to create optimized versions for pdk?  We probably don't need to print floats all that often, but 8-32 bit signed/unsigned numbers would be helpful.

[serisman]

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).

Ok thanks for clarifying.  That is still great progress.   

[spth]

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.

You might also want to have a look at the sduino project, which created an arduion-like using STM8 with SDCC as compiler.

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.

[serisman]

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?

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

You might also want to have a look at the sduino project, which created an arduion-like using STM8 with SDCC as compiler.

Yeah, actually, the ch55xduino is a fork of the sduino project.  I briefly looked into sduino back in the day, but ended up going a different direction for the few projects I have done with STM8.  It was certainly an interesting concept.  I haven't looked at it recently.

[spth]

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?

Not necessarily: SC22WG21, the standardization body for C++ wants to make C++ suitable for low-level devlopment. So carefully coded modern C++ should be similarly efficient as C, even on small devices. Of course, there are C++ features that have a high price in terms ofmemory, but you'd typically have to pay a similar price when coding an equivalent feature in C.
Also, the LLVM+SDCC combination gives you some of the high-level and interprocedural optimizations (where SDCC is lacking) together with SDCC optimizations aimed at small devices (which couldn't be easily implemented in GCC or LLVM). Back when I did the Dhrystone experiment, the Dhrystone that went through LLVM+SDCC was actually slightly faster than the one compiled with just SDCC. There was a substantial increase in code size, but only due to inefficient handling of static inline functions in SDCC. If that one feature was improved in SDCC, even the code size would have been lower with LLVM+SDCC than with plain SDCC.

[spth]

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?

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/

[cmfcmf]

Hi everyone!

After finally having a programmer (thank you tim_!) I got started programming my PFS173 mikrocontrollers.
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

[serisman]

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 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

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)

This is still a work in progress, but I have committed a bunch of new (hopefully easier to understand) examples to the new "free-pdk-examples" repo (https://github.com/free-pdk/free-pdk-examples) that make use of the new "pdk-includes" (https://github.com/free-pdk/pdk-includes) and "easy-pdk-includes" (https://github.com/free-pdk/easy-pdk-includes) repos.

These example programs are loosely modeled after the examples included with Arduino.

Code Examples:

• BlinkLED - Turns an LED on for one second, then off for one second, repeatedly.  Uses a timing loop for delays.
• BlinkLED_WithIRQ - Turns an LED on for one second, then off for one second, repeatedly.  Uses a timer interrupt for delays.
• FadeLED - Uses PWM to fade an LED in and out, repeatedly.
• ReadButton_WriteLED - Reads a Button (digital input), and turns on an LED when active.
• Serial_HelloWorld - Transmits "Hello World" over Serial @ ~115200 baud, and repeats once a second.
• ReadButton_WriteSerial - Reads a Button (digital input), and transmits the results over Serial @ ~115200 baud.
• (TODO...) ReadAnalog_FadeLED - Reads an analog input, and uses PWM to set the brightness of an LED.
• (TODO...) ReadAnalog_WriteSerial - Reads an analog input, and transmits the results over Serial @ ~115200 baud.
• (TODO...) ReadAnalog_WriteAverageSerial - Reads an analog input, calculates a rolling average, and transmits the results over Serial @ ~115200 baud.
• (TODO...) EchoSerial - Echos back over Serial every line that is received.
• (TODO...) ReadSerial_FadeLED - Reads a value over Serial, and uses PWM to set the brightness of an LED.

More examples and better README.md files are on their way over the next few days.

[serisman]

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?

[serisman]

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

I agree that they are a bit too wide, but otherwise those are very nice diagrams!

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.

[greenpossum]

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

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?

[kaweksl]

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?

It's is 2 byte variable added by SDCC. Added probably to optimize code, i see it being used in loop counter. Also it is guaranteed to be aligned in memory and able to be addressed by instructions operating on 2 bytes, like ldt16 stt16. If you gonna use that instructions on another uint16_t it may or may not work, depends where linker would place variable in memory. Example:

Code: [Select]

//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
That is why in my i2c-fancontroller example I'm using ldt16 on p, then moving p to acc and then from acc to 'final' variable. Very inefficient but i can't guarantee placement of 'final' variable.

[cmfcmf]

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.

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?

Yes! I have cleaned the project up a bit and all chip data is now located in this file: https://github.com/cmfcmf/ic-pinout-diagram-generator/blob/master/src/chips.js. Other chips can be added in there. To preview changes locally, follow the instructions in the README file.

[tim_]

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.

[spth]

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.

[serisman]

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.

Thanks for the explanation!

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?

I agree that having another pseudo-register or two would be helpful for juggling things around. +1 for eventually getting that implemented.

[spth]

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?

Both a and p are saved by the caller, if necessary.

[cmfcmf]

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

[LovelyA72]

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

Your pr is way superior than my pr! In honest it looks really awesome! I am gonna close my pr after they merged your pr.

[tim_]

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

https://free-pdk.github.io/

It's live now, thanks a lot!

Now it's much easier to contribute some much needed documentation. Everyone, feel free to contribute. You can directly submit pull-requests here: https://github.com/free-pdk/free-pdk.github.io/tree/development

I will add a section about ordering the lite-programmer once I received and validated the r1 samples - they are being made right now.