Hi, I have a question regarding the memory allocating in FreeRTOS. Can I use the malloc(size) function to allocate the memory for a struct data? If not, how can I  do for allocating a memory space? Thanks,

There is nothing to stop you using malloc() if you have included the necessary C libraries and you have defined a C heap.  Take a look at http://www.freertos.org/a00111.html though, it might be better to use pvPortMalloc() instead, depending on the nature of your application. Regards.

Hi,
Should I assume that standard library malloc/free are not thread safe?
I’m using yagarto GCC compiler for STM32F2 CPU.
Comments for heap_3.c says:
> The wrapper simply makes the malloc() and free() functions thread safe.
And this makes me think that they are not thread safe and can be used only in critical section?

Generally, assume malloc() and free() are not thread safe. Heap_3.c makes them thread safe by crudely wrapping in scheduler suspend/resume API functions. Heap_4.c is recommended.  It is small, fast, thread safe and avoids fragmentation as much as is possible. Regards.

Clear.
But this leads me to the next questions. I need to use sprintf function from standard library. (This is where my question started at all). It leads me to missing _sbrk system call implementation.

c:/yagarto/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/lib/thumb/v7mlibg.a(lib_a-sbrkr.o): In function `_sbrk_r':
C:msys1.0homeyagartonewlib-buildarm-none-eabithumbv7mnewliblibcreent/../../../../../../../newlib-1.20.0/newlib/libc/reent/sbrkr.c:58: undefined reference to `_sbrk'

The reason for that is malloc’free calla from sprintf.
Questions:
1. Does it mean I can’t use standard library sprintf as it is not thread safe?
2. What is _sbrk ?
3. Why sprintf should use malloc/free. (To tell the truth I have stubbed _sbrk with empty code doing nothing and returning NULL and everything worked fine. I assume sprintf uses malloc/free in some very special cases. I can dig it’s code but before going into it I want to see your suggestions as I think this is very common situation.) Thanks for tremendous support here.

1. Does it mean I can’t use standard library sprintf as it is not thread safe?

Doesn’t mean you can’t use it.  Does mean you have to be very careful when using it.  You can protect the non re-entrant parts of the standard library with a mutex for example, or wrap functions in a scheduler suspend/resume block.  Some of the Newlib functions take a long time though, and using Newlib will seriously bloat your code.  These, together with the re-entrancy problems, are reasons why most professional embedded compiler distributions based on GCC provide their own library implementations.  Personally I try and avoid Newlib. If you just want a *basic* sprintf() capability then search the FreeRTOS/Demo directory for a file called printf-stdarg.c.  You will find lots of copies.  Note that snprintf() is defined but not implemented in that file though.

2. What is _sbrk ?

Newlib needs porting to your platform, and that is one of the functions that needs porting (like the read and write functions too if you try using standard out/in).  Google will tell you more about it than you can ever wish to know.

3. Why sprintf should use malloc/free. (To tell the truth I have stubbed _sbrk with empty code doing nothing and returning NULL and everything worked fine. I assume sprintf uses malloc/free in some very special cases. I can dig it’s code but before going into it I want to see your suggestions as I think this is very common situation.)

I have done that before.  Stub it out, set a break point in it, then test every path in your code that uses sprintf() to see if the break point is ever hit. Just calling sprintf() in your code will cause Newlib to bring in masses of other code into your binary, most of which you will not use.  malloc()/free() is part of it, but it will also bring in lots and lots of floating point libraries which seems to be where the most bloat comes from.  I think there are alternative integer only versions of printf and sprintf with slightly different names that avoid that though. Regards.

Well, summarizing your reply I came to plan B that I had in my mind. This is to use some light embedded implementation of sprintf and avoid using of the Newlib. 
I wander if there are some well know libraries to do it? (Not a big deal to write my own implementation but I do not like to reinvent the wheel).

BTW I looked in printf-stdarg.c and it has all required printf/sprintf implementations.

Going back to your question on _sbrk, sbrk() is a function that is sometimes used to build the heap that malloc/free uses. If the malloc/free functions used by your implementation use sbrk, then the implementation should have provided it. The one reason I can see for printf to call malloc would be to get some temporary buffers to do the conversions.

Hi, I’m using arm cortex, KEIL, FreeRTOS V7.1.0. The problem I met is: after many times of running the following malloc function, the heap was used out, couldn’t allocat 1KB space any more. char *Str = (char *)myMalloc(strLen); // strLen is a variable, value between 0 and 1024 if(Str != NULL){ …… myFree(Str);

}

Here are the definitions of myMalloc and myFree: void *myMalloc( size_t xWantedSize ) { void *pvReturn; pvReturn = NULL; if(xWantedSize) { vTaskSuspendAll(); pvReturn = malloc( xWantedSize ); xTaskResumeAll(); } return pvReturn; } void myFree( void *pv ) { if( pv ){ vTaskSuspendAll(); free( pv ); xTaskResumeAll(); }

}

After the parameter strLen was changed to a fixed value, the problem was gone. Why variable length malloc doesn’t work properly? Anything wrong in functions above? Any help will be appreciated. Thank you!

This has been posted to a really old thread. The malloc() function you are calling is not provided by FreeRTOS, but provided by your compiler, so is a question for Keil, not us. However, it sounds like the heap implementation is suffering from fragmentation. I would advise using heap_4.c, which is provided by us, and should not suffer that type of fragmentation. Regards.

Hi, A few more details, maybe: In the code shown, you are protecting your calls to malloc()/free(). That doesn’t mean that other calls (from other tasks) will also be protected. The two stdlib functions are usually not task-safe. Note that malloc()/free() can sometimes be called from the standard C library as well, e.g. by the localtime()/gmtime() functions. I would not expect that KEIL’s malloc()/free() are “leaking” somehow. You could try it out by letting a single task run and do the above test a million times. Like Richard, I would also recommend start using portable/MemMang/heap_4.c (or heap_5.c in case you don’t have “1 piece of RAM”). You can forward the old calls to the FreeRTOS versions: ~~~~~ /* Defining malloc/free should overwrite the standard versions provided by the compiler. / void malloc (size_t size) { /* Call the FreeRTOS version of malloc. */ return pvPortMalloc( size ); } void free (void* ptr) { /* Call the FreeRTOS version of free. */ vPortFree( ptr ); } ~~~~~ Regards.

That’s also what we suspect. Will try heap_4.c. Thanks a lot!

Yes， that protecting code won’t help calling from other stdlib functions. It seems random sequence of malloc()/free() also causes problem. Will try the method you recommended. Thanks a lot & Best regards.