Hello ,
We planning to use freeRTOS for my up coming project. And i would like to create about 50 tasks for this project and i tried creating 25 tasks and i could successfully but if while executing these 25 tasks few of my tasks does not work as expected.
I am using NXP-MPC5777c MCU and following configuration from freeRTOS.
And i am using static task creating using xTaskCreateStatic(), So i am wondering if are there any configuration settings which are limiting the no of tasks that can run on freeRTOS?.
One big question is what are the tasks doing, ?
– In real application they are more like periodic tasks like reading sensors data, reading certain switch inputs and periodic CAN transmission and reception tasks.
– But in my test code, i have just few LED blink tasks, counter decrement tasks and CAN periodic transmission to check if they work concurrently.
and do you have enough CPU to process all of them
– I am bit new to the FreeRTOS, But my understating is that freeRTOS does not limit number of tasks that can be run so i just create the tasks and see if they are able to run. i am using MPC 5777c which is powerful MCU so i assume that CPU is good enough to handle it but i really have no idea can i check if my CPU is enough? Could you please let me know?
Also, try supplying configASSERT and stack overflow checking to help catch some common problems.
– I use the asserts there is no problem, seems like tasks are running but output is not as expected(I could see that LED blinks not as expected)
It doesn’t matter how fast your processor is if some task just does a busy-wait loop and burns up all the CPU time.
You can implement the Run Time Stats to see if that is the issue. See https://freertos.org/RTOS-run-time-stats.html for instructions. This is a likely problem if simple low priority tasks are not running.
Another issue could be a dead-lock, where Task A is waiting for something from Task B, but Task B is waiting for something from Task A.
I’ve had projects with 25 tasks and no problems, but you do need to be careful in your design
I have enabled run time stats and trying to use vTaskGetRunTimeStats API to get the stats, but kernel expects configSUPPORT_DYNAMIC_ALLOCATION to be set to 1, But i am using static allocation for for my tasks.
So question here is run time stats only supported for dynamic allocation? or can i use it for static allocation as well? If yes, How can i do that.
You can enable BOTH static and dynamic allocation, and allocate all of your tasks statically, but also allow FreeRTOS to uses the dynamic allocation routines for the stats.
Note, you can use the function uxTaskGetSystemState to get the raw data for the stats without needing to enable dynamic allocation, since you know how any elements to allocate for the status array (remember to add elements for the Idle task and the Timer/Service task).
You will need to provide more information the symptom you are seeing, and what you have done to debug, to get more targeting suggestions. How does the issue manifest itself beyond not working “as expected”. For example, do all the tasks start running, or is a symptom that one task just never executes. Is there one particular task that causes the issue, and omitting that task resolves the issue? Is it the issue directly related to the number of tasks created, or simply caused by whichever was the last task to execute?
I mean that, i have created 20 tasks with different priorities and all the 20 tasks are running without issues. I have 2 LED tasks in 20 which also blinks periodically for every 200 ms with no issues.
Note: LED tasks are the lowest prio tasks with same priority (tskIDLE_PRIORITY + 1)
But when i try to add another 3 periodic tasks with different priorities, then my lowest prio LED tasks execution is not periodic for every 200 ms. with the blink pattern i could see that LED does not blink for every 200 ms they blink randomly with unknown timing. But all the 23 tasks are running.
I am suspecting the dummy tasks which i have created which does nothing but wait for 1 tick. And i have 10 of these tasks which does the same thing.
/* Run time and task stats gathering related definitions. */ #define configGENERATE_RUN_TIME_STATS 1 #define configUSE_TRACE_FACILITY 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1
My first guess at the strange values is that you Run Time States counter is overflowing.
Newer version of FreeRTOS allow it to use a 64 bit counter that helps. Otherwise you cycle counter needs a low enough count rate that the default 32 bit total time counter doesn’t overflow during your sample period.
I recommend setting a pre-scaler on your timer counter to slow down it’s rate. FreeRTOS is only going to context switch every ms (unless their is pre-emption I think?), so I always set the prescaler on my timer so that things work out that each timer tick is a us, which should give me a reasonable amount of accuracy while still making the numbers coherent to read. To do this, set the pre-scaler on your counter to the same rate that it’s being clocked at (so if the timer is running at 150MHz, put a pre-scaler of 150).
To make it easier to read, you could also do some print formatting. This is what my debug printout looks like.
--Task Name State Pri Stack Num Time
ConUsbRx - 4 850 8 193
IDLE R 0 231 2 5,775,898
Smbus B 3 129 5 11,394
Tmr Svc B 2 431 3 6,574
BootTask B 1 44 1 2,688,221
PwrMgr B 5 865 6 109,884
LTI B 6 411 4 168,607
ConUsbTx S 4 966 7 122
From this, I can see that my idle task has take approximately 5.7s of time, my boot task has taken 2.6s and everything else has been less than 1 second.
One point of correction, FreeRTOS can context switch much more often than the tick rate, as every time the current task blocks, it will context switch.
It will only context switch elsewhere only if in ISR wakes up a higher priority task or on a tick interrupt.
Just would like to understand this Absolute time bit more, So this Abs time is time in micro seconds as my timer period is 1 micro second. Is my understanding correct?
The numbers are the number of Real Time Counter Ticks the task saw, so yes, approximately the number of microseconds it has run (subject to sub-microsecond round off errors every interval it runs).
The very high value for the TaskCanMaster task makes me wonder if it has a polling loop in it, and might be a cause for concern about other tasks getting starved.
To understand this topic little bit more on how to interpret these values, Could you please clarify my following points.
How do i know what is the total available time of my CPU? (Is IDLE task time + Time taken
by all the other tasks gives total CPU time?)
Is IDLE0 task time is the remaining available time of the CPU? If Yes, i need to ensure that this time should not reach zero and always some IDLE0 time?
The the sum of all the tasks percentages value shown in the stats should always be equal to 100 %?
I fixed 1 tick delay in TaskCanmaster which shows high CPU time earlier. Following are my new stats.
