I have fond memories of using it for PIC16 as a teenager, ~25 years ago. It was a huge step up from writing assembly. My parents bought me a Microchip PICSTART Plus, but refused to pay for a Hitech-C compiler license. :)
Cool, I actually applied for a diploma thesis for doing the PIC 16 port around 2004. Raphael Neider actually was quicker then me, so he maintained the port for our lab at the Uni Karlsruhe (i am still in the same lab). We needed the port because was needed to allow people to compile our OS for our sensor nodes at the time. Still did a lot of testing of the PIC 16 port at the time because my thesis was about implementing a filesystem and a REST like API for the nodes.
I used sdcc for an 8051 based commercial project a while back. I seem to remember spending more time reading the assembly to figure out workarounds for the compiler than actually writing C code!
Whereas sdcc works brilliantly for z80 lineage processors. I wrote quite a lot of C for Gameboy recently and didn't find a single compiler bug in sdcc which revised my opinion of it upwards greatly.
Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)
But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)
when you have large code, bugs will find you. for example two uint16 vars globally declared one after another. adding them together to each other will produce an access to garbage memory after 5-6 additions. dumb code but a simple repro. i ran into its bug when working on eInk price tags a while back.
As a student, 20 years ago, I felt like I was going crazy when using SDCC for pic16. Being new to microcontrollers and C, SDCC seemed cursed - even simple 'blink LED' test cases pseudo-randomly worked or didn't. It turned out that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins. These bugs have long been fixed but still live on in my long-term memory.
I still run across this to this day with GCC and Cortex-M code. The optimizer will occasionally decide to blow away loops that are clearly doing something.
What a coincidence, just yesterday I asked an LLM to generate a C compiler for the 8051 because SDCC's output was not optimized.
Within an 1.5 hour it was correctly compiling my project at 60% of the size of what SDCC generates.
One or 2 quota refreshes later it passed the SDCC test suite and optimized soft floats.
I assume you're running that test suite using a 3rd party 8051 emulator to avoid the potential for common-mode errors in both your compiler and emulator resulting in false confidence the compiler's correctness?
> two simulators used for testing, sim51 (a plain 8051) and minitel_sim
I initially added the MOS 6502 support by hacking the HC08 backend. It was awful, someone else (Gabriele Gorla) cleaned it up and got it merged to the mainline. There are other options these days for optimized 6502, like llvm-mos or Oscar64.
I have a few Rabbit boards stashed away that I never got around to toying with, mostly because of the obscure horror IDE. At some point I noticed that SDCC might work and there might even have been a flasher. So, now it's only a matter of having the time and motivation. Which tends to be pointed at many other things.
Microchip XC compiler has support for those. They recently dropped the licensing requirement, so while it's not FOSS, it's freeware now, without limits.
The PIC compiler options were never standards compliant up until around when Microchip purchased AVR. There are great chips now that have free gcc support, reasonable power draw, and 32bit float support (ATSAM3X8E current prices are not worth it in many cases.)
PIC does still have a few key use-cases, but most people will hit the stack depth limits pretty quickly in C. A pic12 Assembly project is fun, but the limitations cut deep these days.
STM32/ESP32/RP2350 or nRF for low power stuff are far less effort these days, and give much better value. =3
ESP32 and RP2350 have pretty crap or nearly non-existent analog. I don't think they even come with a comparator, let alone rarer analog parts like a DAC.
If you need a DAC, Comparator, ADC, and a couple of logic gates, its hard to beat an AVR DD (4x arbitrary gates called CCL. 1x DAC. Differential SAC ADC. I believe 2x Comparators and multiple "internal DACs" so you don' have to spend your 1x external DAC on internal parts). Also 1.8V to 5.5V support, as well as dual-power supply support (PortC is run off a 2nd power supply, but all the logic is compatible. This means PortC can run at 5V while everything else runs at 1.8V, or vice versa, making the AVR DD also a built-in level shifter)
In general, most DAC and ADC colocated on/near a digital chip rail has a list of noise issues anyway, as even an external Vref chip may be unable to help repeatably hit the claimed bit resolution with oversampling. At $9.28/pc for a mcu chip that should cost under $2... runs out of excuses pretty quickly.
It is not about whether something is "crap", because they are all mostly "crap" at analog in different scenarios. Just some vendors have chosen not to polish their "turd" in Marketing. These days many DAC are part of a Class D amplifier, as battery life took priority over the noise floors. These have also become less "crap" over the years.
RP2350 doesn't have a DAC or Comparator. ESP32-S31 has... none. No DAC, no Comparator, no ADC.
"Literally and completely nonexistant" is about as bad as you can get.
Like the reason to reach for a PIC or AVR these days is because of 4-20mA protocol or other such mixed-signal tasks. Read a current between 4-20mA (voltage A - voltage B, so you need a differential ADC) -> MCU -> Logic -> DAC -> controls OpAmp -> controls transistor (BJT or MOSFET) -> outputs a current 4-20mA.
-------
Of the three chips you described (STM32, RP2350, and ESP32), only some STM32 can do the jobs that PICs / AVRs are specialized in.
Most of the ESP32 family includes a dedicated audio i2s interface bus, and doesn't drop out on interrupt like most mcu DAC naive polling offers. It also hits well over 16MHz SPI transfers with ease.
STM32 is in most volume equipment now for a reason. Microchip screwed everyone on long-term pricing, and clown priced themselves out of key markets.
Note, an inaccurate LLM-proxy reply makes people sound lazy. =3
I'm not talking about an audio-DAC chip attached to a MCU. I'm talking about the most basic of analog designs that would transmit data over 4-20mA (just controlling an OpAmp + Transistor passing some currents).
By the time you add that SPI-DAC to your design, you've spent more than any TI (MSP430, MSP erm... whatever cortex-M0+ version was), AVR, STM32 or PIC MCU. There's a lot of chips designed to do this, and they're all on the SDCC compiler for a reason. That's where the niche has been carved out.
Look, I know a lot of people like RP2350 but there's a lot of jobs that chip is just wholly unsuited for.
> STM32 is in most volume equipment now for a reason. Microchip screwed everyone on long-term pricing, and clown priced themselves out of key markets.
AVR16DD14 is 68-cents on Digikey, Mouser, and direct-order from Microchip right now (qty 100 or more). If you need more analog power, the AVR*DB line is closer to $1.20 but comes with 2x or 3x OpAmps (AVR32DB28 I think was 2x OpAmps)
It's great they do C23. I'd love to get three-four projects worth of things merged together for a good reason:
- TinyCC, SDCC, Musl and Cosmopolitan Libc
Reason is that I require a quick fast portable compiler with a decent runtime that can also be embedded into a larger runtime, like the way Bun does - while keeping runtime small and portable.
SDCC does not need the same amount of bloat - having decent small C runtime is a job in itself. Fixing it once could allow a better compiler that isn't quite as bloated as LLVM nor as small like TinyCC.
I have started to notice that programming with an LLM it seems to make little difference if I get it to write the entire program in assembly language rather than c.
qBittorrent is still on SF and seems to be more popular in terms of downloads over the prior week, and also looks after with a release earlier this month.
Skipping past two projects that consist of repackaging existing projects, or a corporate project that I suspect uses SF only for distribution, the next large community project is CrystalDiskInfo, with a release earlier this summer.
Apache OpenOffice is still popular, but doesn't look particularly active.
Then we have KePass followed by Ventoy.
Even when they are active projects, and maybe not even all that old, they feel like they have a vintage feel to them. Part of me wonders if it is using SF that makes it feel that way, but when I look at the home pages for some of these projects that have their home page off SF, they still have that vintage/old school feel.
I have fond memories of using it for PIC16 as a teenager, ~25 years ago. It was a huge step up from writing assembly. My parents bought me a Microchip PICSTART Plus, but refused to pay for a Hitech-C compiler license. :)
Cool, I actually applied for a diploma thesis for doing the PIC 16 port around 2004. Raphael Neider actually was quicker then me, so he maintained the port for our lab at the Uni Karlsruhe (i am still in the same lab). We needed the port because was needed to allow people to compile our OS for our sensor nodes at the time. Still did a lot of testing of the PIC 16 port at the time because my thesis was about implementing a filesystem and a REST like API for the nodes.
SDCC has the best OSS 8051 compiler. It is buggy as hell, but it is free. Sometimes that is good enough.
I used sdcc for an 8051 based commercial project a while back. I seem to remember spending more time reading the assembly to figure out workarounds for the compiler than actually writing C code!
Whereas sdcc works brilliantly for z80 lineage processors. I wrote quite a lot of C for Gameboy recently and didn't find a single compiler bug in sdcc which revised my opinion of it upwards greatly.
I used it for some toy projects never ran into "bugs" as in this is just broken, but it's quirky for sure.
Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)
But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)
when you have large code, bugs will find you. for example two uint16 vars globally declared one after another. adding them together to each other will produce an access to garbage memory after 5-6 additions. dumb code but a simple repro. i ran into its bug when working on eInk price tags a while back.
As a student, 20 years ago, I felt like I was going crazy when using SDCC for pic16. Being new to microcontrollers and C, SDCC seemed cursed - even simple 'blink LED' test cases pseudo-randomly worked or didn't. It turned out that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins. These bugs have long been fixed but still live on in my long-term memory.
> that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins.
Doesn't sounds like a bug in the compiler, sounds more like `volatile` was not used (unless, of course, `volatile` was not being honoured).
Might be. There certainly were bugs in my understanding of micro-controllers and compilers at the time...
EDIT: but SDCC indeed ignored 'volatile': https://sourceforge.net/p/sdcc/bugs/436/
I still run across this to this day with GCC and Cortex-M code. The optimizer will occasionally decide to blow away loops that are clearly doing something.
Please file a bug report, if you haven't done so.
What a coincidence, just yesterday I asked an LLM to generate a C compiler for the 8051 because SDCC's output was not optimized. Within an 1.5 hour it was correctly compiling my project at 60% of the size of what SDCC generates. One or 2 quota refreshes later it passed the SDCC test suite and optimized soft floats.
https://github.com/jyaif/cc51
I assume you're running that test suite using a 3rd party 8051 emulator to avoid the potential for common-mode errors in both your compiler and emulator resulting in false confidence the compiler's correctness?
> two simulators used for testing, sim51 (a plain 8051) and minitel_sim
Narrator: No, he was not.
"it runs on my device" is my criteria of success here
I initially added the MOS 6502 support by hacking the HC08 backend. It was awful, someone else (Gabriele Gorla) cleaned it up and got it merged to the mainline. There are other options these days for optimized 6502, like llvm-mos or Oscar64.
I have a few Rabbit boards stashed away that I never got around to toying with, mostly because of the obscure horror IDE. At some point I noticed that SDCC might work and there might even have been a flasher. So, now it's only a matter of having the time and motivation. Which tends to be pointed at many other things.
SDCC has been a nice resource for a variety of MCUs. I wish it had support for some of the 8-bit PIC chips like the PIC10 and PIC12... maybe one day!
Microchip XC compiler has support for those. They recently dropped the licensing requirement, so while it's not FOSS, it's freeware now, without limits.
you can also recompile xc gcc sources with some the paid features baked on, if you're so inclined and use mplabx pretty heavily
not for PIC
If it has not to be SDCC, Mikroe compilers have support for them across C, BASIC and Pascal compilers, if I am not mistaken.
The PIC compiler options were never standards compliant up until around when Microchip purchased AVR. There are great chips now that have free gcc support, reasonable power draw, and 32bit float support (ATSAM3X8E current prices are not worth it in many cases.)
PIC does still have a few key use-cases, but most people will hit the stack depth limits pretty quickly in C. A pic12 Assembly project is fun, but the limitations cut deep these days.
STM32/ESP32/RP2350 or nRF for low power stuff are far less effort these days, and give much better value. =3
ESP32 and RP2350 have pretty crap or nearly non-existent analog. I don't think they even come with a comparator, let alone rarer analog parts like a DAC.
If you need a DAC, Comparator, ADC, and a couple of logic gates, its hard to beat an AVR DD (4x arbitrary gates called CCL. 1x DAC. Differential SAC ADC. I believe 2x Comparators and multiple "internal DACs" so you don' have to spend your 1x external DAC on internal parts). Also 1.8V to 5.5V support, as well as dual-power supply support (PortC is run off a 2nd power supply, but all the logic is compatible. This means PortC can run at 5V while everything else runs at 1.8V, or vice versa, making the AVR DD also a built-in level shifter)
In general, most DAC and ADC colocated on/near a digital chip rail has a list of noise issues anyway, as even an external Vref chip may be unable to help repeatably hit the claimed bit resolution with oversampling. At $9.28/pc for a mcu chip that should cost under $2... runs out of excuses pretty quickly.
It is not about whether something is "crap", because they are all mostly "crap" at analog in different scenarios. Just some vendors have chosen not to polish their "turd" in Marketing. These days many DAC are part of a Class D amplifier, as battery life took priority over the noise floors. These have also become less "crap" over the years.
Best of luck =3
RP2350 doesn't have a DAC or Comparator. ESP32-S31 has... none. No DAC, no Comparator, no ADC.
"Literally and completely nonexistant" is about as bad as you can get.
Like the reason to reach for a PIC or AVR these days is because of 4-20mA protocol or other such mixed-signal tasks. Read a current between 4-20mA (voltage A - voltage B, so you need a differential ADC) -> MCU -> Logic -> DAC -> controls OpAmp -> controls transistor (BJT or MOSFET) -> outputs a current 4-20mA.
-------
Of the three chips you described (STM32, RP2350, and ESP32), only some STM32 can do the jobs that PICs / AVRs are specialized in.
RP2350 pico can pull off a few classic tricks cleanly with the unique io dma design:
https://github.com/codaris/picovga-cmake
The sync'd DMA is so fast it also often replaces hard to find PROM chips with simple emulation (could pull this off in a fgpa for 10x the price too):
https://www.youtube.com/watch?v=GAh021jgGgs
Most of the ESP32 family includes a dedicated audio i2s interface bus, and doesn't drop out on interrupt like most mcu DAC naive polling offers. It also hits well over 16MHz SPI transfers with ease.
STM32 is in most volume equipment now for a reason. Microchip screwed everyone on long-term pricing, and clown priced themselves out of key markets.
Note, an inaccurate LLM-proxy reply makes people sound lazy. =3
I'm not talking about an audio-DAC chip attached to a MCU. I'm talking about the most basic of analog designs that would transmit data over 4-20mA (just controlling an OpAmp + Transistor passing some currents).
By the time you add that SPI-DAC to your design, you've spent more than any TI (MSP430, MSP erm... whatever cortex-M0+ version was), AVR, STM32 or PIC MCU. There's a lot of chips designed to do this, and they're all on the SDCC compiler for a reason. That's where the niche has been carved out.
Look, I know a lot of people like RP2350 but there's a lot of jobs that chip is just wholly unsuited for.
> STM32 is in most volume equipment now for a reason. Microchip screwed everyone on long-term pricing, and clown priced themselves out of key markets.
AVR16DD14 is 68-cents on Digikey, Mouser, and direct-order from Microchip right now (qty 100 or more). If you need more analog power, the AVR*DB line is closer to $1.20 but comes with 2x or 3x OpAmps (AVR32DB28 I think was 2x OpAmps)
It's great they do C23. I'd love to get three-four projects worth of things merged together for a good reason:
- TinyCC, SDCC, Musl and Cosmopolitan Libc
Reason is that I require a quick fast portable compiler with a decent runtime that can also be embedded into a larger runtime, like the way Bun does - while keeping runtime small and portable.
SDCC does not need the same amount of bloat - having decent small C runtime is a job in itself. Fixing it once could allow a better compiler that isn't quite as bloated as LLVM nor as small like TinyCC.
That gap isn't solved.
Didn't expect to see SDCC being discussed here today. Spent quite a bit of time tinkering with it back then definitely a nostalgic feeling.
I use SDCC for 8051.
I have started to notice that programming with an LLM it seems to make little difference if I get it to write the entire program in assembly language rather than c.
Has worked well enough for me on 8051 and stm8
stm8 array access is suboptimal.
I wonder if this is the most active (or last?...) still-under-development project on SourceForge?
qBittorrent is still on SF and seems to be more popular in terms of downloads over the prior week, and also looks after with a release earlier this month.
Skipping past two projects that consist of repackaging existing projects, or a corporate project that I suspect uses SF only for distribution, the next large community project is CrystalDiskInfo, with a release earlier this summer.
Apache OpenOffice is still popular, but doesn't look particularly active.
Then we have KePass followed by Ventoy.
Even when they are active projects, and maybe not even all that old, they feel like they have a vintage feel to them. Part of me wonders if it is using SF that makes it feel that way, but when I look at the home pages for some of these projects that have their home page off SF, they still have that vintage/old school feel.
There are probably several other projects. I remember coming across OpenOCD recently https://openocd.org/pages/repos.html
TIL about Dallas Semiconductor from this page.
Love Silicon Prairie lore.