Here is a picture and a link to an article I posted on ARM site:

https://community.arm.com/groups/tools/blog/2016/03/11/cmsis-a-proposal-for-a-future-cmsis-written-in-c

Any feedback will be highly appreciated.

Liviu

For modest-sized RAM in embedded (say, <= 256KB), C++ is an unnecessary risk for most. You have to know what you are doing to stick with static class instances, avoid New/malloc()/Free(), and not use classes like String().

For many/most embedded applications that are controlling or interacting with real world things, not just a GUI.

I have been toying with the idea of doing a C++ wrapper for the FreeRTOS API. Thanks for saving me from that exercise!

Mike, µOS++/CMSIS++ is now fully functional.

I have a Git repo with two demo projects: https://github.com/micro-os-plus/eclipse-demo-projects

Please let me know if you decide to evaluate µOS++.

Generally when you are programming embedded it is good to know what you are doing ;-)

C++ is no exception, but it is not an unnecessary risk; just avoid fancy library features and you are safe.

One of the demo projects blinks the LEDs on a STM32F0DISCOVERY board, which has a Cortex-M0 core, and the Release version of the scheduler requires about 15 KB of flash (including newlib printf) and some hundred bytes of RAM + the 3 stacks, so the µOS++ footprint is actually very small, comparable with most other RTOSes written in C.

There is a legend that a simple C++ application compiled with arm-none-eabi-g++ needs more than 150 KB of code, but this is true only if you use iostreams.

The µOS++ comes with a minimal run-time environment for C++, so there is practically no overhead compared to C.

I wrote my bachelors project in C++ back in 2010. It was running stm32f103 MCU which AFAIR had 16kB or 20kB of SRAM. My experience is that the overhead in small applications is no more than 10% of C code and in complex projects you'll get smaller footprints in C++ than in C because it is easier in C to repeat yourself more often.

Few rules to follow:

1. Turn off RTTI.
2. Turn off exceptions - frame unwinding code is often huge comparing to application size.
3. Prefer using static objects if possible (same rule as in C).
4. Don't use 3rd party libraries without checking how they work internally (for example stdlib and boost are not intended to be used in an embedded world).

I never use free()/delete method for security reasons (heap fragmentation) anyway.