I did look at the other posts.
What is the recommended Timer to Tick ratio? I’m running 10x, 10KHz Timer & 1KHz Tick.
I suspect I have aliasing.
Some tasks react to hardware events, ie receiving a CAN message or a serial message.
These are reading “<1%”. I suspect they are using more than that. IDLE is about 80% & a Display Task thats at about 16%. The Display Task % is reasonable.
Also, vTaskGetRunTimeStats() function call returns a string. The order of the tasks is jumping around. It appears to sort highest 5 to lowest. And output formating is a problem.
Is there a way to get the (more) raw numbers instead of a formatted output?
Thanks.
Thank you.
What about Timer rate?
Is it correct to assume that one or multiple Timer counts are required t get reasonably accurate usage times?
Also, what happens when the counter overflows? are the returned values “junk” for a bit?
There is no generic answer to how fast the clock should be. Naturally the faster the clock the more accurate the results will be, but also the sooner the clock will overflow. If you have tasks that run fleetingly and the timer clock is too slow then they may never register as having been executed. The data is only good until the clock overflows.
One thing that at times would be useful would be the ability to change the type of the members that store accumulated time used to accumulate the run-time accumulation. It currently is fixed as a 32 bit type, which limits the running time/resolution for the states. For 32 bit processors, being able to use a 64 bit accumulator would still be reasonably efficient and allow much longer (virtually unlimited) run times even at high resolution. I would expect it to stay defaulted to 32 bits for backwards compatibility, and for use on 16 bit processors (where 64 bits would likely be to inefficient to use in the scheduler). Adding an optional #define for this type in FreeRTOSConfig.h shouldn’t be too hard.
1 Like