The configMINIMAL_STACK_SIZE setting is a good indication. This is the stack size allocated to the idle task (which does not use much stack at all) but also most of the demo tasks. The demo tasks exercise all the FreeRTOS functions.
Ok, but the idle task does not use much of the freeRTOS services, so it is unlikely that it will use the maximum stack size needed by the most task consuming kernel service.
So, if all the parameters to the freeRTOS service functions are passed on the stack, and further, all the parameters from the service to internal functions are again passed on the stack, which, in turn, allocate local variables on the stack… Is there any way to know which is the longest or the most stack-consuming call chain given these hypotheses?
My compiler is capable of passing some of the parameters in registers(up to 8 bytes), but due to the need of interfacing user-mode application with the system-mode kernel through a trap I cannot use register calling convention, but instead I need to use the stack.
So, for example, I call xTaskCreate, passing its parameters on the stack. This function stores local variables on the stack but it also calls other functions, which will further load the stack.
Of course, the size of the return addresses are architecture dependent, so there is practically no way to include them in the stack usage estimation. All I’m interested in is the size taken by the parameters and local variables.
Alternatively you could create stack sizes that are easily large enough, run the program with the stack highwater function enabled, throw everything imaginable at your program and after you’re satisfied that the program has run long enough, look at how much stack has been used. Using these results you can then fine tune the stack sizes.
I know this approach is not 100% sure but there are problems with calculating it out on a theoretical basis:
1. Mistakes are easily made and certain factors (e.g. interrupts) can be overlooked. I wouldn’t trust a calculation unless I can perform such a test run and get comparable results.
2. You cannot make any changes to your program, or ever upgrade to a new version of FreeRTOS, without having to recalculate everything.