xTaskCreate has 3rd argument const uint16_t usStackDepth. It is the number of words to allocate for use as the task's stack.
configMINIMAL_STACK_SIZE is 1024, and it is lots of memory.
Nevertheless it is minimum: it isn't enough to start a task and allocate anything inside.
Why? What this memory is used for?
StackDepth for xTaskCreate, why so big values?
- martinayotte
- Posts: 141
- Joined: Fri Nov 13, 2015 4:27 pm
Re: StackDepth for xTaskCreate, why so big values?
The name is self-explained. It is for the stack. Size 1024 seems to be big for a LED blinking task, but not for some other kind of tasks.
Re: StackDepth for xTaskCreate, why so big values?
There appears to be a FreeRTOS FAQ entry on sizing the stack which can be found here:
http://www.freertos.org/FAQMem.html#StackSize
It seems to describe a number of characteristics which go into sizing the stack. It also suggests a function to get the high water mark of stack depth actually used during some runs. While that should not be used as the gauge for "all runs", it does seem to provide an indication that could be used to gain some insight into how much stack might actually be used in common cases.
http://www.freertos.org/FAQMem.html#StackSize
It seems to describe a number of characteristics which go into sizing the stack. It also suggests a function to get the high water mark of stack depth actually used during some runs. While that should not be used as the gauge for "all runs", it does seem to provide an indication that could be used to gain some insight into how much stack might actually be used in common cases.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: StackDepth for xTaskCreate, why so big values?
In a slight variation from the standard FreeRTOS convention, StackType_t on esp-idf is uint8_t, so the stack size is specified in bytes not words. So passing 1024 for usStackDepth yields a 1KB stack not a 4KB stack. I'll make sure we document this somewhere.
As far as I know (I'm sure Jeroen can explain this properly if I'm wrong), the main reason that even simple tasks need some stack space is that exception handlers (ie interrupt handlers) use the running task's stack, both for saving context and for executing the ISR. It may be possible to rework this in the future so that all exception handlers share a stack region, however as exceptions can be configured in various ways (multiple levels, preemption, etc.) this may be quite complex to get right.
As far as I know (I'm sure Jeroen can explain this properly if I'm wrong), the main reason that even simple tasks need some stack space is that exception handlers (ie interrupt handlers) use the running task's stack, both for saving context and for executing the ISR. It may be possible to rework this in the future so that all exception handlers share a stack region, however as exceptions can be configured in various ways (multiple levels, preemption, etc.) this may be quite complex to get right.
Who is online
Users browsing this forum: Baidu [Spider] and 81 guests