
SDCC – Small Device C Compiler - vmorgulis
http://sdcc.sourceforge.net/
======
msarnoff
SDCC is the only FOSS compiler for PIC microcontrollers. Microchip's XC8
compiler has a free version that's deliberately crippled (optimizations
disabled, garbage instructions added to slow your code down) and a license for
the full optimizing compiler costs $1000. SDCC does a decent job, though it
has its quirks, and may not support the newer architectural features of the
latest PICs.

One reason the Arduino project was so successful is that it was built on a
microcontroller platform (Atmel AVR) which, unlike PIC, has a fully open-
source GCC toolchain.

~~~
jeff_marshall
Is there any reason to use PIC instead of ARM these days? On the low end, 32
bit arm microcontrollers can be had for ~ 0.50 USD in modest quantities
(digikey minimum order quantity in the thousands).

It's not like there is a shortage of compilers for the various ARM
architecture revisions (though the BSP support may be lacking in the hobby
market).

~~~
sjburt
There's lots of other factors besides compiler support and cost. There are
some PIC devices with extreme low-power states that ARM can't really touch.

It's also pretty common for special-purpose devices to include a small general
purpose core. For example the TI CC2541 BTLE module includes an 8051.

~~~
jeff_marshall
Good point re: general purpose cores in devices whose primary purpose is other
things. I've been spoiled by the ability to choose parts that don't go quite
so retro for the CPU in my own designs.

Regarding power, is the difference all that great? some googling shows that
there are cortex M3 devices that use 0.3 uA in standby. Do the PICs have some
features that make standby mode more useful, or do they have significantly
lower power draw in sleep mode?

I've never had to deal with low power draw in standby/sleep mode outside of
FPGA-based designs, so I'm curious to know whats out there.

------
mappu
I recently used some version of SDCC as a part of the old GBDK. It did produce
working binaries, but only after some significant coaxing to avoid internal
compiler errors. It might be attributable to GBDK's old SDCC fork, but it
really wasn't a pleasant experience and took a lot of guesswork to get things
working (separate code into two functions? ICE! reorder two variable names?
ICE! nested conditionals? ICE!)

------
steaminghacker
Big thumbs up for this compiler!

I've been using it to develop my z80 trs-80 star trek game. I constantly check
the code output to ensure it hasn't done something silly, but it all looks
good. massively better than writing assembler by hand, and i would say better
too.

[https://github.com/voidware/trek14](https://github.com/voidware/trek14)

~~~
vmorgulis
I like a lot your "Precision doubler":

[https://github.com/voidware/dp/blob/master/dp.h](https://github.com/voidware/dp/blob/master/dp.h)

You gave me an idea for multiprecision numbers with variadic templates (like
tuple<> with head/tail).

Thank you!

------
archimedespi
What benefit does SDCC have over GCC for most embedded development? And if
it's the only FOSS compiler for PICs, why hasn't someone ported parts of
SDCC's backend over to LLVM or GCC?

~~~
sjburt
It has a few compiler extensions that are very useful for small embedded
development, but GCC won't add (eg an "at" keyword to let you place a symbol
at a specific address).

As for "why" nobody has done it, it's probably just because nobody has. The
targets are mostly 8-bit devices with limited resources and SDCC is good
enough. Typically the vendors have their own paid toolchains. I don't really
know how well GCC would perform on those targets (although AVR8 uses GCC).

~~~
archimedespi
Yeah, I can get that. When I was working with SDCC, I really would have
preferred GCC or clang - SDCC has some funky quirks that really pissed me off
and introduced some weird bugs.

And yeah, AVR8 (and IIRC 16 and 32) have GCC toolchains as well as avr-llvm,
which is pretty sweet.

~~~
aexaey
>AVR8 (and IIRC 16 and 32)

What's AVR16, may I ask?

------
jdblair
I used SDCC for a project that targeted an 8051 CPU. Its not fancy but it gets
the job done.

~~~
veli_joza
We also used SDCC for teaching embedded devices. We deployed the compiled hex
into simulation software called Proteus - it's a weird combination of
schematic capture / pcb design / realtime circuit simulator supporting analog,
digital and programmable components.

SDCC worked very well in this environment. Students could easily download it
to work from home without any environment dependencies or license issues.
Error messages were descriptive. Our customization needs were nicely solved by
some compiler flags. All in all it was a good choice.

------
jhallenworld
You can use it to hack old credit card terminals:
[http://jhallenworld.blogspot.com/2012/08/reverse-
engineering...](http://jhallenworld.blogspot.com/2012/08/reverse-engineering-
verifone-zon-jr-xl.html)

------
flohofwoe
I used SDCC to write C code for an 8-bit home computer that never officially
supported C, it was fun:

[http://floooh.github.io/2014/11/09/new-adventures-
in-8-bit-l...](http://floooh.github.io/2014/11/09/new-adventures-in-8-bit-
land.html)

It was a fun project, but for 'real world code' that needs to fit into a few
hundred bytes and needs to be fast, directly writing assembler code is the
only choice on 8-bit CPUs.

------
tluyben2
SDCC is also nice for dev on old (80s) platforms like Z80; that's what a lot
of retro machine C aficionados use it for.

------
csense
If it's a compiler with Z80 target, has anyone ported this to the Z80 based TI
calculators?

------
i336_
Remember those silly cheap <$5 picture frames you find in $2 shops, or as a
free bonus online sometimes? You probably have one lying around.

If it uses an AX206 chipset, you can flash _whatever code you like_ onto them
with an SDCC-based toolchain.

You get a color LCD with at least 128x128 resolution (some cool devices are
320x320), and MENU, LEFT and RIGHT keys for input. Perhaps best of all, they
have a bootloader, meaning burning the wrong code into Flash is completely
recoverable :D

There are a couple basic firmware images that come with the toolchain - one to
let you control the LCD from Linux, and one that dumps CPU registers in real
time (for debugging) - so it's very easy to get started.

Vague high-level overview:
[http://picframe.spritesserver.nl/wiki/index.php/DPF_with_App...](http://picframe.spritesserver.nl/wiki/index.php/DPF_with_AppoTech_AX206)

SVN repo: [http://sourceforge.net/p/dpf-
ax/code/HEAD/tree/trunk/src/](http://sourceforge.net/p/dpf-
ax/code/HEAD/tree/trunk/src/)

If you have a device and want to play with this, I recommend cloning the SVN
repo and pouring over the readme file inside, which covers backing up your
stock firmware, identifying your device model so you know which firmware to
build (and if it's an AX206 at all - moment of truth :P), and reflashing. It
only takes about 30 minutes to feel like you've read everything thoroughly
enough and execute a reflash.

There are some conflicting bits of information and link-rot here and there,
but I'll say this: I know zero about low-level device hacking, and I managed
to get this installed onto a cheap picture frame I had lying around within a
few minutes. I also managed to fully recover from a bad flash run too.

My DPF currently sits on my bedside table with the debug firmware on it (you
enable the debug code via a config file change); the sole reason I've done
nothing with it (tetris! breakout! space invaders!! :D) is that the buttons on
mine are on the back :( (why??? >.>)

So, the project and code actually does do what it says on the tin, and the
hardware is _very_ resilient. :D

Note that some picture frames are based on the ST2205u or ST2203u, which use a
6502 core (the AX206 uses a MCS-51 aka 8051 core). This is quite different,
with no SDCC toolchain; you'll need to know 6502 asm for these, I think. There
does appear to be some LCD-control firmware available for these which you
could work from but the AX206 is much easier to start with I think.

