How to measure code execution time...?

I am not familiar with your specific processor and tool, but here are three approaches:

1. Use a code simulator. Subtract the value of the cycle counter before and after your code runs. Divide by the appropriate clock, or divided down clock, to get the execution time on a real processor.
2. Run the code on your target system. Set a spare output high when your code starts and low when it ends. Look at the pulse on a scope or measure with an external timer.
3. Use an internal timer with suitable range and resolution to measure the execution time. Read it before and after the code, then subtract. Multiply by the time per tick.

Thad

Do you have an extra output pin you can take high when entering the code and low when exiting the code? Do you have an oscilloscope (and know how to use it) to look at that pin with? I've used this technique innumerable times - it's good not just for timing, but for debugging, to make sure the routine executes at all. You can save a timer count at the start of the routine and take the difference at the end (and account for rollover). It sounds like this is the way your boss is suggesting you do it. Do you have a simulator for the device? It should count cycles. Just record the cycle count at the start, run to the end and subtract. You need to know the cycle frequency (not neccesarily the crystal frequency) to convert the cycle count to time, and likewise for using the timer, you need to know the timer increment frequency.

-----

There are a number of ways, depending on the hardware & software tools at your disposal and the accuracy you require. I'm not familiar with Codewarrior specifically, but you might check the user's manual for code profiling.

If you have to do it yourself, the general idea is to create some condition (raising or lowering a signal, outputting a value to an I/O port, etc.) that indicates entering/exiting the code section and watching for that condition with something that measures time. ICEs (In-Circuit Emulators) and Logic Analyzers are ideal for this.

Probably the minimal solution, requiring a single channel storage scope and giving you a pretty good number, is to connect a scope probe to a line whose signal you can raise or lower at will. Start with the signal low and raise it just before entering the section being measured. Lower it again when exiting the section. Set the scope to its largest time per division and have it trigger on the signal going from high to low (if it shows activity up to the trigger; trigger on low to high if it shows activity starting at the trigger.) This should capture the duration of the code execution. Reduce the time per division setting until the entire event just fits on the screen and determine the time from the length of the signal.

Something to consider - does the execution time depend on some external condition (amount of data to process, presence or absence of signals, etc.) Also, is the clocking variable? (example: the RCA 1802 processor's speed varied by the amount of voltage supplied)

What you might want to do is compute the theoretical time the code section should take by figuring out the cycles for each instruction and dividing by the clock rate (cycles per second). That should give you a sanity check to use.

hope that helps

Joe

Ben Bradley wrote:

This is precisely the sort of situation where I'm vaguely frustrated by the lack of a trivial, 32-or-more-bit counter running at the same rate as, or some unalterable factor of, the machine clock. The x86 got one around about the Pentium, presumably for precisely this purpose.

ANSI gives you clock(), which counts up at CLOCKS_PER_SEC clocks per second. If your compiler+library is kind enough to implement ANSI functions in an embedded environment and handles all the hardware for you and happens to use a suitable value for CLOCKS_PER_SEC then this should work:

clock_t start, stop; unsigned long milliseconds;

start = clock();

do_stuff();

stop = clock();

milliseconds = 1000UL * (unsigned long)(stop - start) / CLOCKS_PER_SEC;

printf("elapsed time: %lums\n", milliseconds);

Adjustments should be made to bring values into the scale you require.

boss

on

The Motorola part most likely has a 64-bit counter that ticks at some fraction of the processor clock rate. For a pure software solution, I've read the register at the start of the routine, read the register at the completion of the routine, then calculated the difference. The difference between the two 64-bit values is the time required to execute the code. This value will change according to interrupt processing, logic branching, and cache updates.

To increase portability, use

milliseconds = 1000UL * (stop - start) / CLOCKS_PER_SEC;

If clock_t is an integer type, this will be equivalent because of integer promotion. If clock_t is a floating point type, say with units = seconds, the first method will lose precision by casting, while the second method carries full precision.

Thad

boss

on

If the code you want to time can be put into a subroutine and repeatedly called, here's a low-tech solution, requiring nothing but a wristwatch:

1. Create a calling routine that can give some sort of external signal when it starts and when it ends (an ASCII character sent on a serial line, an LED illuminated, etc.)
2. Make the calling routine call your target code a sufficiently large number of times, say, N = 1,000,000, and time the interval from when it starts to when it ends. Record that as T(1).
3. Now modify the calling routine to just call a null subroutine instead of your target code. Time the interval from its start to its end. Record that as T(0).
4. The time required to execute your target code is then (T(1) - T(0)) / N.

Wayne

The OP may well have this facility.

The Motorola PowerPC has an 'mftb' instruction which reads the processor timebase. It is fairly easy to configure this to run at 1 Mhz.

Maybe the OP should specify the processor he is using?

Andy

Thad Smith wrote:

oops. Yes indeed. I have other parentheses in there and moved stuff about when I thought better of assuming the sorts of numbers involved.

boss

on

Thanks for all your help everyone. Andy Sinclair won the prize...... it's in the mail... However I tried as many of the other suggestions as I could and now I know different ways of accomplishing this task, so thanks. And thanks to Ben Bradley for the tip with the scope... I'm sure that'll come in handy in the future.

Simp