#if ( configUSE_IDLE_HOOK == 1 )
/* A variable that is incremented by the idle task hook function. /
static volatile uint32_T ulIdleCycleCount = 0U; #endif // configUSE_IDLE_HOOK == 1
… … … #if ( configUSE_IDLE_HOOK == 1 )
/ Idle hook functions MUST be called vApplicationIdleHook(), take no parameters,
and return void. /
void vApplicationIdleHook( void )
/ This hook function does nothing but increment a counter. */
} #endif // configUSE_IDLE_HOOK == 1
Task.c file kept unchanged, o.c.
Using Lauterback debugger I could see that periodic task are correctly triggered
So, what is the solution?
I have saturated the CPU with only 5 periodic tasks…not a good thing for me.
We need both periodic and event-driven tasks (to be activated on CAN/LIN/SPI interrupt service routines).
How can I harmonize everything with FreeRTOS? Maybe it does not fit on our application.
One big question is do your I/O drivers use interrupts and block the task using the device while the I/O is in process, or do the tasks just poll a ready flag?
If the latter, then you are wasting a LOT of CPU time during I/O. Many vendor supplied I/O libraries do the latter and are a cause of this sort of problem.
IF that isn’t the problem, It may be needed to use the run-time stats functions to see if one of the tasks is over heavy.
Note, a task that runs every millisecond can’t do a lot without using up a large portion of the CPU time available.
It is also very possible that you just underspecified the CPU power you need, not knowing what all the tasks are doing, it is hard to say.
Another question is do these tasks really need to be “periodic”, or could they be changed to respond to actual needs? Waking up a task often for it to just check if it is needed wastes a lot of CPU time.
Yes, peripherals’ ISRs (CAN for diagnostics, or SPI communication between master uC and slave SBC, or a PWM for electronic motor control, Half bridges, and so on…) can block OS tasks during their execution; we usually pull (-> ISR disabled) only 1 CAN channel for development, for sure not during production phases.
Both OS periodic and event-driven tasks are fundamental for our application.
Using FreeRTOS manual, I have create the tasks and set delay for timing sheduling but, to be very honest, at the moment it is totally unclear for me how FreeRTOS manage tasks’ “switch-in”/ “switch-off” and how next IDLE (or background) task is activated and managed.
Anyway, just few minutes ago I have performed a very simple test, with all peripherals’ ISRs disabled, one periodic task with priortity 2 and cycling time 100msec.
As you could see, neither in this case the IDLE task is activated
Priority 0 is NOT “Disabled”, so the fact they exist says they may be taking time (unless your code does something with this structure you are printing out).
Personally, I would likely turn on Run Time States, and see which task is using the time. The other option is to randomly breakpoint the system a few times and see what task is currently running.
Yes, it is quite possible that you have something misconfigured, but there is a lot of code you haven’t shared, so hard to tell, but Coretex-M7 should be a fairly straight forward port without a lot of options to get wrong, unless you HAVE changed something to customize it.
The run time counter will continue to count (until it rolls over, at which point the run time stats get hard to interprete). The purpose of doing this was to see which task is getting all the CPU time.
The fact that you when you were running w/o break point you ended up in a “TaskEvent”, with a very large ulRunTimeCounter value makes me wonder what that task is doing. That may be your task that is using all your time.
That OS_FreeRTOS_Init function and those tasks are NOT part of the FreeRTOS distribution, but something added by someone (maybe the implementation as a “generic” interface). Maybe they were sample code that the framework intended to be edited with implementations.