Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


allocating a buffer vs declaring it

Posted by chaabanemalki on June 23, 2015


I have task1 calling functionA. what's the difference between the 2 following cases of fucntionA

~~~~~~ Taks1() {


} ~~~~~~

case 1

~~~~~~ functionA() { char* pBuffer;

pBuffer = pvPortMalloc(100);
    // process data, 
   //pBuffer is always used when calling functionA
pPortFree(pBuffer );

} ~~~~~~

case 2

~~~~~~ functionA() { Buffer[60];

    // process data, 
    // buffer is always used when calling functionA

} ~~~~~~

If taskA is pre-empted by a higher priority task, Will task1 save the variables of fucntionA ?

What is the best function to use ?

Thank you

allocating a buffer vs declaring it

Posted by rtel on June 23, 2015

If you declare a local 60 byte array then the compiler will place the array on the stack of the task. Every task has its own stack, so every task will have its own array, so it is a thread-safe way of doing it. This is a fast and neat way of allocating a 60 byte buffer - but it will mean the size of the stack allocated to the task will have to be large enough to hold it. See http://www.freertos.org/Stacks-and-stack-overflow-checking.html

If you dynamically allocate a buffer by calling pvPortMalloc(), and store a pointer to the buffer in a local variable (pBuffer in your case) then that variable will be either on the stack of the task or in a register. Every task has its own stack, and its own pseudo-copy of the registers - so again this is thread safe. Dynamically allocating the buffer is much slower than just declaring an array on the stack, but will allow you to allocate a smaller stack to the task.


allocating a buffer vs declaring it

Posted by chaabanemalki on July 1, 2015

Thank you for the clarification. So if I understood right. In the example I showed above, case 2 : the compiler will place and 60 bytes array the stack of task1 and another 60 bytes in the stack of functionA ? am I right ?

allocating a buffer vs declaring it

Posted by woops_ on July 1, 2015


allocating a buffer vs declaring it

Posted by richard_damon on July 2, 2015

In case 1, you have 60 bytes allocated on the task1 stack, so you need to make sure that you give task1 enough stack to store it.

In case 2, you have 60+ bytes allocated on the heap (it is + as allocations on the heap often require some overhead bytes to operate with them, and the allocation is often rounded up to some increment), and a pointer on the stack (likely 2 or 4 bytes long). This means you will need to make sure the heap has enough space to allocate the object out of.

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists