How to calculate a RTOS task's time

I have written a code in c for Arm7 using RTOS. There are multiple tasks who's priority is set to same level. So the tasks executes on round-robin base.

There is an exception that one task (Default) has set to lower priority then the other task in rtos. So that if no task is running, the default or lower priority task runs.

Now i want to calculate the exact total timing (time duration) for that default task runs.

Can开发者_如何学JAVA any one give some idea what to do .... and how to do in code..

Regards Dani

A very simple way to see when the default or idle task is running is to make this task toggle an unused (but accessible) GPIO pin or an indicator LED, if your hardware has such a thing. Then if you connect an oscilloscope to the I/O line you can see how long the processor remains in the idle task by the duration of the oscillation period seen on the 'scope. The line will remain in a steady state whenever the other tasks are running.

An alternative method, if you can get to the OS code, is to make the line go high whenever the default task is selected and low for any other task.

It would be helpful if you gave us more information about your platform (CPU, RTOS) but the general idea is this:

Most RTOSs have some type of "task switch" callout or hook. Most embedded platforms have easily-accessible timer peripherals (hardware timers).

So: every time you switch into & out of the low-priority task, take a snapshot of the timer & calculate the time interval.

All sorts of caveats apply, such as accounting for timer rollover (including multiple rollovers if your timer period is very short), low-power / sleep modes (if you use them), time spent in ISRs, etc...

I agree with Dan's answer - here are some additions/enhancements:

(1) Window-based calculations. because default presumably has no periodicity, you will need to calculate it's run-time in terms of a percentage spent in that task over some window (say 1000msec). You will need to define a static variable used for accumulating timer clicks. Once your window has expired (ie: 1000msec have passed) you can calculate time spent in default as compared to 1000msec which will be percentage spent in default. As I'm reading your description, it seems like the Default state is basically an idle state - which means that this percentage is roughly your available micro utilization.

(2) one rollover per hour.. If you can use a 32-bit counter and you capture usec timestamps you can make it just over 1 hour before any rollover occurs. If you are using this for a home project you have the option of ignoring rollovers. It will contribute to a single distorted 1000msec window, and that's all. If, on the other hand, you are going to monitor for maximum utilization and set a fault or diagnostic because of this... then you want to consider it.

(3) ISR skew. Determining if you need to handle time spent in ISRs differently than time spent in another task is dependent on how your RTOS handles context switching. As Dan mentions, most RTOSs have some sort of callback or hook that will trigger when a task switch occurs. Some RTOSs have a separate hook just for ISRs. I'm not exactly sure what the motivation for this is other than a general theory that users are less likely to care about time spent in (hopefully) brief ISRs than about the user tasks themselves. In any case, check out how your RTOS handle this switching and go from there.

If you don't handle this correctly, time spent in the ISR will be attributed to whatever task was running at the time when the ISR fired. If you happen to be in Default then your Default task was "absorb" ISR time. If you don't have a lot of ISRs running, then I would ignore this completely.

Good luck! I've done this with the PowerPC 551X family, and it was for production automotive SW so it had to be perfect! You should have it much easier :)