If you use uxTaskGetSystemState to get the states, it returns the total accumulated time as an output, and that should be equal to the sum of all the times for the tasks, including the idle task.
I don’t know why your idle task is called Idle0, unless your port is based on a multi-core version, and that will be the time not used by any normal task. Just not being 0 isn’t necessarily good enough, as that just means that at some point you weren’t starving it. The amount of time you want to make sure it gets depends a lot on the application and your reserve requirements, For many systems it will get most of the time, as other tasks just need time in bursts. For systems with more sustained loads, it might get just a small amount. For some systems it might even be ok for it to get starved at times due to high peak loads. It all depends on the system.
The sum of the time used should add up to the total time, and the %ages are task time used/total time which should add up to 100%, but because the %ages are rounded, it might not add up exactly. Especially with a lot of <1% values, the sum is hard to verify. In your case, the some of the not <1% looks to be 90%, so all the <1% look to add up to about 10%. which is reasonable.
Still one thing which is not clear for me is that how come Abs time is in ticks if my runtime stats timer period is 1 micro second( which is used for calculation of total task times) and my tick is 1 milli second.
My understanding is that,
Abs time is not related to tick time (1 ms) at all because my time base for run time stats is in micro seconds?
If i use 100 us period for my runtime stats timer ( of course this is different from tick timer ) my Abs value should be given in the multiples of 100 us. If the timer is 1 us then Abs time is given in the multiples of 1us. Is that correct?
Ok, so you are using the multicore version, but configured for only one core, since there is only one Idle task it seems.
The tick period is not important for run time stats (except how that affects how long tasks actually run). IF you change the run time stats counter to count once every 100us, then the stats would be in units of (and sampling resolution of) 100us, so if gathered over the same actual time period would be 1/100th the value you get with a 1us stats counter.
Yes i am using only one core in multi core version of port.
My time base is 1 us, if i take below task TaskeSCI example, runs totally for 29050639 micro seconds = 29050 milli seconds and approximately 29 secs? which is 5 % of total CPU time?
Yes, that line means (if the run time stats counter is running at 1MH/1us) that the TaskSCI task has used about 29 seconds of CPU time, in about a 10 minute sampling period (since 29 seconds is 5% of the total time, the total time needs to be about 10 minutes.
Hey @Krishna hope you’ve been doing well! I wanted to reach out and see if you were still facing any problems with this issue? If you are still blocked would you mind sharing what your current problem is so we can try and help you with it? Additionally, if you have everything working as intended if you could let us know that’d be great!
Okay. Thank you for the clarification Richard. However i need to understand little more on how the total CPU time is about 10 mins( is this calculated based on the stats timer?) i will dig into this little bit. And if i need any info i will get back to you.
Yes EVERYTHING in the stats table is based on the stats timer.
10 minutes is 600 seconds, or 600,000,000 microseconds, and 5% of that would be close to the given number for TaskeSCI. Looking at IDLE0, perhaps a bit less, that implies more like 9 minutes, but all are just approximate since we only have one or two digits in the percentile. If you printed the “total time” value, we would know exactly.
The run time of a task is update each time a task is switched out, when its run time is updated by the difference between the current timer value and the value it had last time a task was switched.
The total time is the sum of all those times, or just the difference between the current value of the timer and the value it had when things started.