The embedded development community/industry seems stuck in C. (I'm talking truly embedded here -- not Linux gumsticks, not "single board computers", etc.)
How about C++ with STL (but without vector and other containers that use new/malloc)?
Does this buy you anything?
There has to be an alternative to C. I wish it was Forth, but there doesn't even seem to be a Forth for Cortex.
I love C, but it doesn't scale very well (when it comes to abstractions and type safety).
How would generic programming (templates) look on an MCU? Would I be able to come up with a template that would let me abstract away SPI and UART code?
Is Embedded C++ (with templates) inevitable?
The prospect almost makes me want to buy this: http://www.digikey.com/scripts/dksearch/dksus.dll?Detail&name=497-6049-ND&enterprise=12 (a Cortex M3 demo/devkit for < $40).
I'm starting with the STM32, and using C++ with it. Before I was using C++ with an ARM7 (LPC2000 series). Microcontrollers with >= 256KB of flash and > 32 KB of RAM support nearly all features of C++, including exceptions and vector, list, string... iostream is another matter, it pulls in code for locale support and makes the binary file too big, but who needs iostream in an embedded device anyway?
ReplyDeleteThe big problem with the STM32 is that Cortex-M3 seems to be standardizing startup an peripherals into libraries (CMSIS), and these libraries are designed for C developers and not C++ friendly...
I use C++ on the TI Stellaris LM3S9B96 (Cortex-M3 core) with success.The only C++ features I stay clear of are templates, RTTI, the std library and exception handling. Classes and polymorphism are concepts that enable me to write efficient device drivers etc on these microcontrolllers.
ReplyDeleteI do not understand developers who write code for these devices in C when their code size exceeds 32K in flash. Scalability, type checking and code re-usability are very limited or non-existing in C and for programs that use 32K or more flash, C++ offers the right toolset to write coherent and (mostly) bug-free code. The price you pay is having to learn C++ and developing an "Object-Oriented" mindset. In my perception, this is a small price to pay for writing better embedded software with fewer bugs and more functionality.
C++ templates can be very useful with small embedded processors (as well as classes). In the MSP430 IAR, an empty C++ class consumes 1 byte.
ReplyDeleteAs mentioned by the last commenter, you should stay away from RTTI, the std lib, exceptions, etc.
But I've found that templates and simple (non-inheriting) classes (for abstraction) are okay.
For my last job, I wrote a serial bootloader in C++ using templates and classes (for abstracting MSP430 families and UART params). It compiled to 800 bytes!
Hello, I have 7 years doing C code for MCU, mostly because I was asked to do so (even though last time it was for a Cortex M3 - iMX53). Then I was told C++ produced bigger code and it was not optimal (and I partially believed since ASM code can produce more efficient instructions than C, or I think so).
ReplyDeleteNow I am in another company and I'm about to use the same Cortex M3 -STM32-. Even though I'm not a CPP versed coder I think OOP is way powerful than structured programming.
Anyway, my question is: CPP code has any disadvantage against C? I mean, regarding processing time, memory, etc?
Generally, an object instantiation of an empty class takes 1 byte (under IAR at least). Objects aren't expensive, the heap is. You'll need to stay away from 'new' and 'delete'.
ReplyDeleteWhat you get with C++ is more type checking, and lots more compiler help. In particular, inlining functions gives the compiler help on deciding what to generate (sometimes inline, sometimes a function call).
In theory, C++ can produce tighter code than C. At least from an optimizer's perspective.
Most of the C++ I've done for embedded revolved around using classes for information grouping/hiding; templates for code generation and inlining for optimization.
If you don't use the heap or RTTI features of C++, you have a richer C and the code generation should not be any larger than C (good optimizing compilers notice that you aren't using exceptions or the heap and don't generate "extra" code).
To answer your question more directly: It depends. Given a good compiler, the compiles should still be fast and the code small and fast too.
Thanks a lot for your prompt answer Todd!
ReplyDeleteEven though I actually programmed in C, I always tried to create classes (through structures and pThis pointers) and create Object Oriented designs.
Regards!
BTW, sorry about my poor english.