Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!snorkelwacker!apple!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.realtime
Subject: Re: Measuring timing of Realtime Systems
Message-ID: <12582@netcom.UUCP>
Date: 25 Aug 90 08:17:33 GMT
References: <9724@tekigm2.MEN.TEK.COM>
Distribution: usa
Organization: Dave McMahan @ NetCom Services
Lines: 49


 In a previous article, gaulandm@tekigm2.MEN.TEK.COM writes:
>Timing is critical in most realtime applications.  Interrupts must be handled,
>inputs polled, and outputs updated in a timely manner.  How do *you* measure
>the time it takes your system to respond to an interrupt or input, or execute
>a subroutine?  I'm new at embedded systems programming, and am genuinely
>interested in hearing about any tools and tricks used by more experienced
>hands.  So far, I've just been toggling test pins and looking at the results
>on a scope, but that often produces a jumpy square wave that is difficult to
>interpret.

First, you have to determine the desired performance of the circuit.  You have
to know or calculate the worst case allowable constraints for the system (like:
I have to respond and do function X before 23 uSeconds, or it won't work). 
Then, you code up the system and debug the obvious defects.  There are many
possibilities after this, depending on the type of equipment you are running
on and the type of test equipment you have.  The simplest case would probably
be a two channel scope and a parallel I/O port that you can address quickly in
software.  You just need to toggle the output of one bit on the parallel port
when your software completes the task.  Trigger the scope on interrupt assertion
and set up the second channel so that it watches the bit that software toggles.
This will give you a good idea of the average, but is poor for the worst case
problems.  For finding the worst case, you have to use the same setup but
different equipment that can measure the longest period between the interrupt
being asserted and the software bit that states all processing is complete.
I have used logic analyzers for this task in the past, as well as some of the
fancier digital scopes.  My personal favorite is a good logic analyzer that
has a microprocessor interface so that you can get it to trigger when the event
should happen and have it capture when the code passes a certain address which
indicates that processing is complete.   For the 68000 family, I like to use
the HP-1630 or HP-1650 models with the proper uProcessor pod and software for
the logic analyzer.  I have found that a company called LeCroy makes a good
digital scope for lots of applications.  It has smart triggering so that it
will capture things like max pulse width, min pulse width, and any event that
takes longer than some time period.

Sometimes, you have to write your code so that it can determine when the scope
should be triggered and toggle the proper output line.  This is the case when
you have special conditions that are too complex for the scope to handle without
building bunches of external hardware.  The problem you have to watch out for
is the fact that calculating if the scope should trigger or not imposes more
time for the software process to run.  This amount of time may be trivial, but
it may not be.  You have to know if setting up such a test can affect your
results and give you false answers.

>Mike


  -dave