SDCC – Small Device C Compiler(sdcc.sourceforge.net)
sdcc.sourceforge.net
SDCC – Small Device C Compiler
http://sdcc.sourceforge.net/
23 comments
I like a lot your "Precision doubler":
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!
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!
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...
SVN repo: 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.
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...
SVN repo: 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.
I used SDCC for a project that targeted an 8051 CPU. Its not fancy but it gets the job done.
I did the same, for my college thesis project, back in 1998! It sure has been around for quite a while, glad to see it is still chugging along.
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.
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.
You can use it to hack old credit card terminals: http://jhallenworld.blogspot.com/2012/08/reverse-engineering...
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!)
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.
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.
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).
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).
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.
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.
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.
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.
The reasons for using PICs typically where cost (in the embedded market every cent is counted) and ultra-long device availability (there were only few PICs ever discontinued, and I guess most got some compatible successors).
Fair enough, but the device in question would have to be made in serious quantity to feel the difference (though that is a rational use-case).
Per digikey, the cheapest 8-bit PIC is 0.35 USD in MOQ of 3K. When 15 cents matters to your BOM cost, you know you are making a lot of things :)
Per digikey, the cheapest 8-bit PIC is 0.35 USD in MOQ of 3K. When 15 cents matters to your BOM cost, you know you are making a lot of things :)
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?
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).
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).
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.
And yeah, AVR8 (and IIRC 16 and 32) have GCC toolchains as well as avr-llvm, which is pretty sweet.
>AVR8 (and IIRC 16 and 32)
What's AVR16, may I ask?
What's AVR16, may I ask?
sdcc is the only(viable?) foss option for many 8-bit/older architectures. 8051, z80, stm8 are what I've used it for. A lot of newer chips(example many of TI cc2xxx SoCs) actually have 8051 still, stm8 is newer entry(I think).
SDCC supports architectures that GCC doesn't support. 8051 is one of these. I'm not sure if GCC supports any 8-bit CPUs.
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.
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...
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.
http://floooh.github.io/2014/11/09/new-adventures-in-8-bit-l...
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.
If it's a compiler with Z80 target, has anyone ported this to the Z80 based TI calculators?
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