I use FREERTOS on an ATMEGA8 (1k SRAM, 8k FLASH) and if I have two tasks everything is OK, if I put another (3 in total) system seems to get stuck on one of them or something like that. Then I experimented by increasing the stack size for the two previously working tasks and I verified my theory. Once I increase the total stack size allocated from all tasks above 220bytes the system gets stucked.
I don’t really have a problem, I can do my job with two tasks. I just want to ask if this should happen or not?
1K SRAM is not very much. Each task has it’s own stack, plus any static data you have. This all has to fit into this 1K. There is also the stack for the idle task.
Can you implement one of your tasks as an idle hook? This would save you some RAM, but can only be done if the task never makes a blocking call (the task must always be available to run).
I fixed the problem by increasing the TOTAL_HEAP_SIZE size from 500bytes to 700bytes. It’s a little bit misleading that Task’s STACK is being allocated on the HEAP (- I’m sure that the OS masters will laugh now claiming that “where else could it be allocated on?”)
and experiment with different values for TOTAL_HEAP_SIZE. (Don’t forget to ‘make clean’ and then ‘make all’ again in case that “FreeRTOSConfig.h” is not included in your Makefile’s dependencies).
It’s still strange the way that application stalls always in the same way! Perhaps some macros inside “xTaskCreate” could enable a message to be popped. Some additional documentation about memory management would be welcome!
Note: By increasing the HEAP SIZE from 500bytes to 700bytes I can have two more tasks. When I add another task it gets stuck in exactly the same way as before! - Very strange! I am used to see really unstable behaviour when a system runs out of memory - in freeRTOS it seems like the scheduler just stops task switching.
Which means that the thread switching doesn’t even start. By hacking the source of vTaskStartScheduler(), I put some additional traces that revealed that the “problem” was once creating the IDLE task. xTaskCreate kindly returned pdFAIL and vTaskStartScheduler() was returning imediatelly.
Of course I’ve never imagined that something like this could happen and I haven’t put a “HEY, WHAT DO YOU THING YOU’RE DOING?” message after vTaskStartScheduler() inside main().
And, as my project completes, one last world of attention: "If your application has 3 user tasks that must all be at different priorities then use priorities 3 (highest), 2 and 1 (lowest - the idle task uses priority 0)." In this case, do set configMAX_PRIORITIES configuration variable to 4. That is the number of your priorities + the idle priority.
Internally, configMAX_PRIORITIES is being used like this:
