Swapnil
DIIDevHeads IoT Integration Server
•Created by Prahallad on 1/14/2024 in #middleware-and-os
Is there any way I can get stack requirements of task practically?
Yes @Prahallad . There is API in FreeRTOS which returns the watermark of stack used by task.
• In FreeRTOSconfig.h, enable “INCLUDE_uxTaskGetStackHighWaterMark” (define it as 1)
• Add below piece of code in a task for which you want used stack size.
Uint32_t watermark = uxTaskGetStackHighWaterMark(NULL);
This API will return the value of unused stack in words. For ex. on a 32-bit machine a return value of 1 would indicate that 4 bytes of stack were unused.
• Once you freeze your code and clear with stack requirements, in production code you can remove this code and disable this API.
• Once you freeze your code and clear with stack requirements, in production code you can remove this code and disable this API.
4 replies
DIIDevHeads IoT Integration Server
•Created by Swapnil on 1/7/2024 in #middleware-and-os
How should I decide appropriate Tick time configTICK_RATE_HZ in RTOS project?
Thanks for detailed response. Its really helpful.
8 replies
DIIDevHeads IoT Integration Server
•Created by Umesh Lokhande on 12/16/2023 in #middleware-and-os
Why always use only heap4.c memory scheme in FreeRTOS?
Every "heap_x.c" has different memory allocation schemes which provides different level of flexibility, and efficiency in terms of memory use.
But I find "heap4.c" is well balanced schemes in terms of flexibility, memory requirement and execution time. However its never a rule of thumb to use the "heap4.c" rather it depends on micro-controllers memory specification in term of size and firmware design requirements.
heap1: It allocates memory from a statically allocated array. It doesn't permit memory to be freed once it has been allocated. Despite this limitation, heap1.c is appropriate for many small embedded system because of few advantage. "heap1.c" has less memory requirements and helps to reduce RTOS footprint. There is no memory fragmentation with "heap1.c"
Heap2: heap_2 uses a best fit algorithm and allows previously allocated blocks to be freed. But heap4 is preferred over heap2 because heap2 can results in a heap space that is badly fragmented into multiple small blocks. Heap3: It provides wrapper for the standard C library malloc() and free() function which probably increases the RTOS footprint(RTOS code size).
Heap4: heap_4 uses a first fit algorithm and it allows dynamically allocate and free memory. It combines adjacent free memory blocks, which significantly reduces the problem of small unusable fragments. Heap4 is much more efficient that most standard C library malloc implementations. I would like to add one more thing here, In tutorials, application code is very small with 2/3 task and Queues. Most of the tutorials are on arm based controller where you get good amount of memory space and processing power with respect to embedded system. So in this case no need to think much about RTOS footprint and execution times while configuring the RTOS. But when you are working on a product code, you have to use appropriate heap and RTOS configurations to meet performance requirements.
heap1: It allocates memory from a statically allocated array. It doesn't permit memory to be freed once it has been allocated. Despite this limitation, heap1.c is appropriate for many small embedded system because of few advantage. "heap1.c" has less memory requirements and helps to reduce RTOS footprint. There is no memory fragmentation with "heap1.c"
Heap2: heap_2 uses a best fit algorithm and allows previously allocated blocks to be freed. But heap4 is preferred over heap2 because heap2 can results in a heap space that is badly fragmented into multiple small blocks. Heap3: It provides wrapper for the standard C library malloc() and free() function which probably increases the RTOS footprint(RTOS code size).
Heap4: heap_4 uses a first fit algorithm and it allows dynamically allocate and free memory. It combines adjacent free memory blocks, which significantly reduces the problem of small unusable fragments. Heap4 is much more efficient that most standard C library malloc implementations. I would like to add one more thing here, In tutorials, application code is very small with 2/3 task and Queues. Most of the tutorials are on arm based controller where you get good amount of memory space and processing power with respect to embedded system. So in this case no need to think much about RTOS footprint and execution times while configuring the RTOS. But when you are working on a product code, you have to use appropriate heap and RTOS configurations to meet performance requirements.
2 replies