FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2015 Threads] allocating a buffer vs declaring itPosted by chaabanemalki on June 23, 2015 Hello,
I have task1 calling functionA. what's the difference between the 2 following cases of fucntionA
~~~~~~
Taks1()
{
for(;;)
{
functionA();
}
}
~~~~~~
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 itPosted 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.
Regards.
allocating a buffer vs declaring itPosted 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 itPosted by woops_ on July 1, 2015
allocating a buffer vs declaring itPosted 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|