SEGGER embOS/Micrium OS-III on STM32F4

[mailmail9116]

Posted on July 17, 2013 at 09:58

Hi ,

Maybe someone here can help me with the issue that i am having .

I am currently evaluating both embOS and OS-III on STM32F4G-Eval, and i see the same issue on both of them .

After starting my task , when inside the task i am trying to call malloc or even the thread safe version of malloc that is provided by the OS , it fails and returns null , i know that i have plenty of free RAM so i guess this is not the issue , maybe heap de-fragmentation ?

When calling malloc before starting the OS  , malloc works just fine , so i am afraid that is some kind of issue with the OS , but the strangest part is that i am having the same behaviour on both OS`s .

Any idea why?

Edit :

I think that i am on my way to fix the problem .

it seems that setting in the linker script :

_Min_Heap_Size = 0x19000; /* required amount of heap */

_Min_Stack_Size = 0x200; /* required amount of stack */

instead of :

_Min_Heap_Size = 0x00; /* required amount of heap */

_Min_Stack_Size = 0x200; /* required amount of stack */

solves the issue .

I am used to work on a bare metal system , where the _Min_Heap_size was not a issue , it seems that working with OS is different in this aspect.

Thanks

Michael

[dthedens23]

Posted on July 17, 2013 at 20:08

Can't help you with the malloc issue.  I never use it because it can fail (fragmentation can cause it to return NULL) and then what?  crash? reset? ...

both of the RTOS should have compile time static memory pools that one can allocate simple things like messages, queue objects, mailbox items, ...  Allocation from these pools generally cannot fail (unless they reach max size) because fragmentation doesn't fail since the object in a specific pool is the same size

In a past life I evaluated both of these RTOS.  embOS won because of the much lower cost (including source code)  and per CPU family license.  Unlimited on any CPU in the family of processors.  With OS-III it would have been one license for a M-4 with 80 pins and another for the same part with 100 pins.

However, I am now using Chibios.  Quite a few drivers for STM32F4xx peripherals.

[ts_it]

Posted on July 19, 2013 at 10:41

This issue is less related to the OS but more to how heap management with GCC works.

With GCC linker files sections like .data and .bss are defined. In these two sections goes all your initialized and not initialized C variables. Most GCC linker files places the start of the heap after the end of the .bss section and the begin of the stack at the end of the RAM.

When you now call malloc() (directly or via OS function) malloc calls a function called sbrk().

sbrk() checks if the current heap pointer is still below the stack pointer (heap pointer grows to higher addresses and stack pointer grows to lower addresses). If not malloc() returns NULL.

If you call malloc() the first time with e,g, malloc(10) the heap management will allocate much more than the 10 Bytes because it needs some bytes for the heap management itself .

It works exactly  the same way with embOS but embOS defines linker symbols for heap start and heap end as also for stack start and stack end which makes it easier to define the size of heap and stack. Thus embOS comes with an own sbrk() function and the heap size has to be defined.

Most embOS start projects already define the heap size as 0x400 Bytes, which makes it easier to use heap out of the box.

Regarding embOS vs Micrium OS-III

I am working now since several years with embOS and it is definitely the better OS. It's easy to you use, runs out of the box and Segger makes the best support I have ever seen.

[mailmail9116]

Posted on July 19, 2013 at 17:36

Yes , now i know that , the thing was that i didn't you the template project , but instead i inserted the embOS ''module'' to my current project , then i really find out that i need to change sbrk implementation ,and modify the linker script

After that everything works like a charm.

It my first attempt with operation system , but i must say that embOS manuals are great , and the API is very easy to use , i really like it so far , + the embOSviewer is a nice tool.