C++ Was a Joke

[Sylvain Cote]

It is possible to use objects, interfaces, design patterns, exceptions, reflection, etc
in a micro-controller environment but you have a lot of work to do to make it happen.

I have prototyped and then lead a successfull project using GNU C++ for ARM with a
Cortex-M3 MCU and FreeRTOS 7/8.

The internally designed board has the following: (partial listing)
- Cortex M3 MCU with 96KB RAM & 768KB Flash
- external 8MB of flash for firmware/config. updates (2MB) and data storage (6MB)
- GSM/3G cellular radio with IP stack in the radio for transferring data/firmware/config/etc
- Sensors: GPS module, Accelerometer, etc

50k devices in the last year has been shipped with the following C++ framework platform in it.

Today, a medium complexity application with two boot loaders fit in a little less than 400k
of Flash and the application consume around 50K of RAM.

One thing that I underestimated was the time it take to convert a seasoned C procedural embedded
software developper into a "java like server" developper. I started with a team of 6 persons
(excluding me), lost 2 persons in the process that could not follow and for the 4 persons left
it took them 12 months to fully integrates all the concepts and be completely autonomous.

Best regards,

Sylvain

PS: The following list some of the constraints imposed on the project ...
> service oriented architecture
- each service is delivered as pluggable library
> Hardware Abstraction Layer (HAL)
- defined with interfaces
> Hardware Implementation Layer (HIL)
- classes implements the interfaces define in HAL
- allow fast changes in the hardware without impacting software behaviour
- each HIL is delivered as pluggable library
> OS Abstraction Layer (OSAL)
- defined with interfaces
- also include some concrete classes that are OS generic
> OS Implementation Layer (OSIL)
- classes implements the interfaces define in OSAL
- allow transparent RTOS and target platform changes
- each OSIL is delivered as pluggable library
> object oriented programming
- single inheritance is allowed (multiple-inheritance is not)
- all classes must derive from the CObject (root) class
- all concrete classes are final and cannot be derived
- ex: [CObject]<-[CService]
> object instanciations & associations
- no composition is allowed
- only aggregation is permitted and through constructors only
- aggregation is done with references only (no pointers allowed)
- all objects must be statistically instanciated (exception: inter-task messaging)
- all aggregations must be done before the main function is called
> programming by interfaces
- interfaces are defined using pure abstract classes
- interfaces must derived from the CObject class or from another interface
- ex: [CObject]<-[IBus]<-[CSpiBus], [CObject]<-[IAddress]<-[CSpiAddress]
> unit tests
- unit testing framework design from scratch to use the less possible RAM/Flash
- all test cases must run in the MCU itself
> design patterns
- most designs from the GOF used (facade, chain, command, responsability, etc)
- ex: [CObject]<-[ICommand]<-[CCommandChain], [CObject]<-[ICommand]<-[CCommandMock]
> memory management
- custom memory allocator (for inter-task messaging only)
- multiple fixed size memory allocator (no fragmentation)
> exceptions management
- custom thread implementation
- to reduced stack usage
- to keep the thrower/catcher in the same RTOS task
- no throw in catch allowed (to reduced stack usage)
> miscellaneous features
- namespace used
- RTTI not allowed (consume way to much memory and flash)
- custom reflection implemented (cost only 4 bytes of RAM per instanciated object)
- no templates (well almost, only used 3 times in the entire framework)
- no standard C++ libraries allowed (iostream, stl, etc)
> there is lot more that I could add to this list but I think the above will suffice for now