Tweet Follow @jack_ganssle

Embedded Muse 55 Copyright 2000 TGG November 8, 2000


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Tires That Are Too Smart
- More On Measuring Latency
- Upcoming Embedded Seminar
- Thought for the Week
- About The Embedded Muse


Tires That Are Too Smart


From: http://dailynews.yahoo.com/h/nm/20001023/tc/tires_phones_dc_1.html

Reuters reports that in Finland work is afoot to embed chips inside of your carís tires. When the pressure falls too low theyíll call you on your cell phone.

Technology run amok? Can I block calls from my tires? Iíll have to get call waiting in case the tires want to break in on another conversation!


More on Measuring Latency


Gary Bergstrom wrote:
The other very interesting thing one could do with your counter is to log the time when the ISR finished. e.g. Read the hardware timer as the last thing you do. This catches overflows, and sometimes the higher priority interrupt that interrupts the current interrupt.


And Alf Katz commented:
Of course, you're right, but of much more interest to most embedded programmers is the longest system latency. This can easily be found by keeping the highest overrun reached in another variable, and updating only when a higher one is found. Of course you could go overboard & collect means & standard deviations of the latency time, but you wouldn't want to do it in an interrupt - and the longest latency is *usually* the most important metric.


Finally, from Dean TerHaar:
I use a similar approach to time the duration of an ISR. I define a struct of two variables: TimerIn and TimerOut, and then declare a global array of this struct. On entry to the ISR I read the system timer and store it in Array[i].TimerIn and on exit from the ISR I read the system timer again and store it in Array[i].TimerOut. I also have a control variable that I can set dynamically to enable/disable this ISR duration monitor. After I execute a sample run of the program (in real time), I'm use these timer values to calculate the min, max, and average durations of the ISR and display a report. (without the aid of a debugger or oscilloscope!)

The routine that calculates the ISR time also calculates the overhead of the duration test (i.e. the time it takes to read the system timer and store its value). It subtracts this overhead (or bias) from the calculated ISR time to compensate for the additional time it takes to perform the test. This routine also normalizes the result in microseconds and handles cases where the system timer rolled over during the execution of the ISR under test.

This test, as it is written in C, however, does not account for the overhead of the ISR under test (working register pushes and pops), but this fixed time could be calculated manually and included into the final result returned by the routine that calculates the ISR execution time.


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.

For more information check out http://www.ganssle.com or email mailto:info@ganssle.com.

A lot of folks have asked me to bring this seminar to their company. Email me at mailto:jack@ganssle.com if youíre interested.


Thought for the Week


A tourist walked into a pet shop and was looking at
the animals on display. While he was there, another
customer walked in and said to the shop keeper,
"I'll have a C monkey please".

The shopkeeper nodded, went over to a cage at the side
of the shop and took out a monkey. He fit a collar and
leash, handed it to the customer, saying, "That'll be
$5000." The customer paid and walked out with his
monkey.

Startled, the tourist went over to the shopkeeper and
said, "That was a very expensive monkey. Most of them
are only a few hundred dollars. Why did it cost so
much?"

The shopkeeper answered, "Ah, that monkey can program
in C - very fast, tight code, no bugs, well worth the
money."

The tourist looked at the monkey in another cage.
"That one's even more expensive - $10,000! What does
it do?"

"Oh, that one's a C++ monkey; it can manage
object-oriented programming, Visual C++, even some
Java. All the really useful stuff," said the
shopkeeper.

The tourist looked around for a little longer and saw
a third monkey in a cage of its own. The price tag
around its neck read $50,000. He gasped to the
shopkeeper, "That one costs more than all the others
put together! What on earth does it do?"

The shopkeeper replied, "Well, I haven't actually seen
it do anything, but it says it's a consultant."