Calculating processor usage (M68K)

Do you mean a polling loop that is looking for activitity or are the activitites interrupt driven?

If you are trying to decide whether you can utilize a faster processor, are there other things you need to measure, such as latency?

I assume that you have development capability on the existing application and are not trying to anaylze a "black box". The distinction between doing effective work and spinning in an idle loop is one that can only be made by knowing the application code itself. You will need to find where the processor is when it is "idle". Then, make a temporary modification to the code to leave some evidence of the time that is spent in idle. That can be either hardware or software. In software, you might sample a high-speed clock on entry and exit from the idle code and accumulate the time spent in some counters that are eventually reported out. In hardware, you might set a digital output to indicate idle vs. non-idle, then monitor that bit with a scope and estimate the duty-cycle, or low-pass filter it and measure the average voltage with a voltmeter.

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

How about a 'working' flag and two counters?

- When in the idle loop, set the flag to 'idle'

- When entering any activity, set the flag to 'at work'

- Use a timer interrupt at some arbitrary interval.

- In the ISR do something like: void TimerIsr(void) { if(working) atwork++; else idling++; }

This should give you a reasonable indication what percentage of time is spent.

Rob

The following article describes two techniques for measuring processor utilization:

Sandeep

--

And how do you know that you are back at work (without modifying the scheduler) ?

You may write a timer interrupt (period depends on how accurated your figures must be) and check which is the return address i.e. the interrupted function. Then count numbers of interrupts and number of times where you did interrupt the idle loop (or a self written low-prio task).

This works well in a monolithic state-engine design. It doesn't work when a scheduler preemptively interrupts tasks, as the scheduling is (should be) transparent to the tasks.

Rob

pSOS gives you a hook that gets called whenever there's a task switch. If you have access to a good real-time clock, this can give you lots of information about idle time.

This works well if you have a spare timer that can be programmed to issue a non-maskable (level 7 on 68k) interrupt. You can use a buffer to capture the value of the program counter and use the data to analyse the systems steady-state behaviour (if it has one!).

I have also used the abort button for this purpose but it made my finger tired.

It depends a lot on whether tasks are suspended when idle/waiting for I/O or just busy-looping in their slice until interrupted.

I'm wire-wrapping a "junkbox wars" hobby project. If I have 3 I/O lines left over, I'm planning to drive 8 LEDs on the front panel. When the switcher swaps tasks, it'll turn on that task's (or class of tasks') LED. One LED reserved for the idle loop. I'm planning to use cooperative multitasking, but it should also work pre-emptive. The overhead is a few cycles per context-switch.

An empirical indicator of limited use except for the fun of watching one LED flare and the others dim as one task grabs the CPU...

Which frequency did you achieve ?

(Sorry, could not resist :-)

In the past I have used spare bits on a parallel port to monitor each task. By putting a line of code at the beginning & end of each task to set its corresponding I/O bit as below, you can monitor the absolute service times as well as the % utilisation of the CPU by that task with a CRO.

taskN(normal param list) { *IOPort |= (1