Embedded Muse 54 Copyright 2000 TGG October 30, 2000
You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
EDITOR: Jack Ganssle, email@example.com
- Measuring Latency
- Upcoming Embedded Seminar
- Thought for the Week
- About The Embedded Muse
CPU vendors define interrupt latency in terms of the longest non-interruptible instruction. I figure this is a meaningless definition; after all, what we developers really care about is the time between when the interrupt occurs and when the ISR (Interrupt Service Routine) starts. Usually the delays are more a factor of how we write the firmware than raw processor capabilities. Code that spends lots of time with interrupts disabled will have long latencies.
There are a number of ways to measure this, but hereís a novel and rather cool approach. Youíll need a spare timer and just a bit of code.
Start the timer counting up, and set it to interrupt when the count overflows to zero.
The timer ISR should be dead simple with as little overhead as possible; itís best coded in assembly language so you can minimize the number of register saves (so many compilers push *everything* inside C-coded ISRs).
Immediately read the timer count register and sum this value into a long variable. Increment a counter. Then clean up and return.
Note that, though the timer read zero when it issued the interrupt, it continues to count before the ISR starts. The value we read inside the ISR is the systemís latency (less some ISR overhead).
Figure the raw overhead of this ISR by counting T-states (instruction times) before the timer read happens. Now just run your application for a while, and then stop the program with a debugger.
Average system latency is the long variable (normalized to microseconds), divided by the number of iterations of the ISR, with the ISR overhead removed.
Embedded Seminar in Chicago
Iíll present the seminar "The Best Ideas for Developing Better Firmware FasterĒ in Chicago on November 15.
The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. If youíre interested reserve early as these seminars fill completely.
A lot of folks have asked me to bring this seminar to their company. Email me at mailto:firstname.lastname@example.org if youíre interested.
Thought for the Week
Your friend might be a hacker if..........
-Everyone who ticks him or her off gets a $26,000 phone bill.
-Has won the Publisher's Clearing House Sweepstakes three years running.
-When asked for their phone number, they give it in hex.
-Seems strangely calm whenever the office LAN goes down.
-Somehow gets HBO on their PC at work.
-Mumbled, "Oh, puh-leeeez!" 295 times during the movie "The Net."
-Massive 401k contribution made in half-cent increments.
-Their video dating profile lists "public-key encryption" among turn-ons.
-Instead of the "Welcome" voice on AOL, you overhear, "Good Morning, Mr./Mrs. President."
-You hear them murmur, "Let's see you use that VISA card now, Professor "I-Don't-Give-A's-In-Computer-Science!"