ChibiOS Free Embedded RTOS

Exactly. If it does use malloc() internally then the syscall.c should already provide the required integration between newlib and ChibiOS.

As I wrote it is just matter of integration and debug

Giovanni

Great! This seams to work. I even added a std::vector test - all fine! Of cause this will take up huge amounts of ROM... But it works nonetheless.

The wrapper was meant to enable enough C++ to allow compact object oriented applications, STDC++ automatically negates this, the size explodes even for trivial programs.

Giovanni

Of cause you are right. But ROM consumption can be reduced further, even with libstdc++. I found some great tips here: http://www.webalice.it/fede.tft/cpp_on_ ... ricks.html

I have done some tests with C++ on the STM32, and found out some interesting things:

- static constructors should be called from the startup scripts with __libc_init_array(). This is called in ST's template for Atollic studio, but not the Ride7 one (gave me quite a headache to find that). No need for a #define: in C, this function simply does nothing.
- Using the options -no-exceptions -no-rtti in the compiler can reduce some KB (5KB in the program I tested).
- Using a single new operator, my program raised by 55KB! After some research I found out that this pulls in useless exception code all around, even with the above options and the nothrow keyword. The workaround to this is having our own new implementation. That's actually even better if we want to integrate with ChibiOS's malloc(), though I haven't done that yet. With that, my test program was pretty much the same size as when compiling with pure C.

I have a page with a more thorough explanation: http://wiki.dapaixao.com.br/microcontro ... /cplusplus
It is in Portuguese, but a smart guy can get the feel of it, or use a translator (do not get the code from a translated page!): http://translate.google.com.br/translat ... =&ie=UTF-8

Also, I have a skeleton Eclipse C++ project here: http://wiki.dapaixao.com.br/microcontro ... c_completo

Hi,

I agree on everything you suggested, the current C++ wrapper is quite limited. Good idea about redefining the "new" operator to use the OS primitives directly.

About constructors and destructors, those should already be invoked by the current startup code (in 2.3.3), are you experiencing problems with the current implementation?

Giovanni