Heap size, C++11 and THD_WA_SIZE in v3

[charlesrwest]

Hello!

This is my first time building a real application with ChibiOS. I'm really liking the architectures and layout, but had a few small questions come up as I worked through the basics.

Heap size:
From what I've read, it looks like you can use the default heap allocator if CH_CFG_USE_HEAP has been set to true and you put a NULL pointer for the heap.
If I may ask, does anyone know what the limits of the default heap size? The size of the main stack is defined in the make file (USE_PROCESS_STACKSIZE). Does the heap grow until it hits one of the stacks or statically defined memory objects or does it have a fixed size limit defined somewhere?

C++11:
I was hoping to use C++11 as the default language for this project. I was able to get an example to run and use auto by using a .cpp file for main and adding the -std=c++11 option to USE_CPPOPT. If I may ask, are there any downsides or "gotchas" that would prevent this from working reliably for my projects?

THD_WA_SIZE in ChibiOS v3:
In the example for dynamic thread creation in ChibiOS 2.8, a call like the one below would be used:

Code: Select all

thread_t *thread1 = chThdCreateFromHeap(NULL, THD_WA_SIZE(128), NORMALPRIO, &thread1Function, NULL);

However, the THD_WA_SIZE macro doesn't seem to be defined in v3 and I can't seem to find where it should be from looking in the 2.8 code. It does work if I just specify manually, but the posts I read seemed to indicated that was bad practice because the working area will be larger than the given 128 bytes. If I may ask, does anyone know what the v3 replacement for the macro would be?

Thanks,
Charlie West

[steved]

In general terms there's a fair amount of documentation, including both 2.x and 3.x APIs, through http://wiki.chibios.org/dokuwiki/doku.p ... :documents

There's an example of creating a thread on the heap in the STM32F429 demo in chibios3\demos\STM32\RT-STM32F407-OLIMEX_E407-LWIP-FATFS-USB

C++ use - I've seen (general) comments that the overhead can greatly increase the size of an embedded application unnecessarily. It's not bad enough to prevent me using some C++ on a 32F051 (64K flash).

[TexZK]

There is no harm in using C++ at all, just disable RTTI and exceptions if you do not strictly need them. C++ only fails when using the condemned singleton pattern, because a proper singleton's methods need the this parameter (just like any other C++ class instances), which should be constant and fixed at compile time, thus being unnecessarily pushed and accessed from the stack. You can replace the singleton object by a class with static methods only, but you lose flexibility and testability w.r.t. a generic object. Anyway, I think that with constexpr in all the right places you can help the optimizer to evaluate those pointers at compile time, and using a global variable in place of the widely argued instance() static method. Good luck with that, I have never tried, but I'm tempted to switch to this interesting C++11 from the good old C++98.

[Giovanni]

Hi,

A C++ demo is already included and there is a C++ wrapper class for most of the RT API. I can confirm that disabling RTTI and exception the size of C++ applications is not much different from plain C.

About the heap, the default heap uses all the RAM not used by other segments (BSS, DATA). If you look at the linker script (rules.ld) you can see how boundaries are defined.

In 3.0 that macro is now called THD_WORKING_AREA_SIZE(). The use of the macro is strongly recommended because the W.A. is not just the stack, there are other structures allocated there and their size can change depending on the current settings. The macro takes care of that, you just need to specify the stack size, the overhead is added.

Giovanni

[barthess]

I use C++11 features in my projects and can not see any drawbacks.
My compiler is https://launchpad.net/gcc-arm-embedded

[charlesrwest]

Thanks for all the great responses! I've integrated the macro and will start taking a closer look at the C++ wrapper.

Many of the posts I've read seem to indicate that you should stay away from the C++ standard library due to code size growth from templates, the requirement for dynamic memory allocation and exceptions. If I may ask, has anyone had a good experience with the C++ standard library and ChibiOS or alternate implementations of the standard library (such as https://github.com/msharov/ustl).

Also, how quickly does memory fragmentation get out of hand? Would using a few std::vectors tend to break the code?

Thanks,
Charlie West

[TexZK]

You don't have to use dynamic memory allocation with C++ (the new operator can also work on a preallocated chunk!), nor you have to use the STL with its default allocators if you think it isn't good for your purpose (many developers don't like it).
C++ as a language is capable to run at the same cost of plain C, if not even faster sometimes and cleaner (templates and constexprs are evaluated at compile time!). The so-called C with classes (plus namespaces and templates) is already much cleaner than C.

[barthess]

@charlesrwest
You can provide your own memory allocator to stdlib classes constructors.
I prefer memory pools from ChibiOS or http://www.gii.upv.es/tlsf/

[charlesrwest]

@barthess
If I may ask, how do you go about doing that? Most of the tutorials I've read have you replace the new and delete member functions, which is fine for using with the heap but doesn't do so well for memory pools unless you can use the placement new operator. My attempts to use the placement new to call the constructor on a block of allocated memory haven't seemed to work.

It would appear that I need to include the <new> header, but the compiler doesn't seem to find it with the default settings (<vector> doesn't work either). If I may ask, do you know of the best way to get access to the placement new operator so that you can pass memory/arguments to the new operator? I would love to get it working with a memory pool.

Thanks,
Charlie West

[barthess]

you need to #include <memory> for placement new