Closed j5mj5s closed 3 years ago
Hi @j5mj5s,
First we would like to thank you for your contribution.
In fact, the description of the usStackDepth
parameter to the xTaskCreate()
function clearly states that the stack is specified in words, not bytes. FreeRTOS runs on 8, 16, 32 and 64-bit processors, so the word size is dependent on the architecture. If each item placed on the stack is 16-bits, then a stack size of 100 means 200 bytes will be allocated for use as the task's stack. As described in the CMSIS-RTOS v1.03, when stacksz
is 0, a fixed size memory pool is used for the thread stack. In this case OS_STKSIZE
specifies the stack size for the thread function. When stacksz
is not 0, the thread stack is allocated from a user space. The size of this user space is specified by OS_PRIVSTKSIZE
with is the combined stack requirement (in words) of all threads that are defined with with osThreadDef stacksz != 0
(excluding main).
I hope this is helpful. Unfortunately, we don't treat these aspect related to FreeRTOS in our GitHub repositories. They are rather treated at FreeRTOS GitHub.
Please allow me to close this issue now. Thank you again for your contribution.
With regards,
Describe the set-up Review of the API from freeRTOS and CMSIS-RTOS
Describe the bug
The function
osThreadCreate
gets the stack size in bytes. (https://www.keil.com/pack/doc/CMSIS/RTOS/html/group__CMSIS__RTOS__ThreadMgmt.html#gaee93d929beb350f16e5cc7fa602e229f)On the other side freeRTOS
xTaskCreate
needs ausStackDepth
in number of words. (https://www.freertos.org/a00125.html)The current implementation pass through the "byte-size" to a "word-size".
Note I saw the note at the end of the CMSIS-RTOS API, that macro can be "specific". But I thing, that the idea of the CMSIS-RTOS abstraction is that these basics are compatible for each implementation.