gaulandm@tekigm2.MEN.TEK.COM (08/25/90)
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. Thanks, Mike
mcmahan@netcom.UUCP (Dave Mc Mahan) (08/25/90)
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
dave@hp-lsd.COS.HP.COM (David C. Mueller) (08/27/90)
Using a scope or even a logic analyzer you can make the type of measurement you're talking about. However, you should look to your emulator (assuming one is available). In addition to making the normal state analysis measurements, some emulators (read HP's emulators) have a class of measurements called "Software Performance Measurements". The type of measurement you're making is included in that class. Statistics on the latency you're measuring can be given as well so that you can get a feel for the max/min latency as well as the average and distribution of particular latency measurements. Dave (can you tell I work for HP?) Mueller hp-lsd!dave
rlk@telesoft.com (Bob Kitzberger @sation) (08/30/90)
In article <15630007@hp-lsd.COS.HP.COM>, dave@hp-lsd.COS.HP.COM (David C. Mueller) writes: > > However, you should look to your emulator (assuming one is available). > In addition to making the normal state analysis measurements, some emulators > (read HP's emulators) have a class of measurements called "Software > Performance Measurements". The type of measurement you're making is > included in that class. > > Statistics on the latency you're measuring can be given as > well so that you can get a feel for the max/min latency as well as the > average and distribution of particular latency measurements. This is a nice feature, but as you say, it IS statistical, i.e. sampled. Unless things have changed in the past few months, HP's performance measurement feature sampled the instruction/address stream, filling the trace buffer. Once the trace buffer was full, the input stream is ignored and the samples are merged with the rest of the statistical sample. Hence, potentially critical information may be lost. If this is wrong, I'm sure someone at HP will correct me (and please accept apologies in advance). What would be a GREAT feature for timing analysis would be to add the ability to trigger on TIME DELTAS in addition to address/data bus values, etc. For example, define event A and event B. Then, set the analyzer to trigger whenever B occurs > 200 usecs after A. _That_ would be immensely usefull in determining when timing constraints are missed. HP, cabn this be done? Please? Back to the original request... hardened real-time developers tend to develop a toolbox full of timing techniques, each applicable to differing situations. Here's a couple of mine, though I'm not hardened too much yet ;-) Ordering is from high-budget to low-budget. 1. Logic analyzer / emulator monitoring events (as others have attested to) + allows max/min measurements (for a given analyzer buffer size) + very flexible in defining events + high-resolution measurements (in the nsec range for some) + no need to instrument your code - expensive - emulators sometimes introduce wait states that skew timings 2. Toggle pins on an output port, measure with oscilloscope + visual representation + cheap, easy - hard to get a decent trace for jittery cycles - non-cyclic events require a storage scope - can't meassure max/min, only average 3. Hardware timer chip. Start the timer at the start of the event of interest, stop it at the end. Shove the resulting time into an event timestamp array somewhere in RAM. You can timestamp as many events as you have available RAM. Then, perform a post-mortem dump of the timestamp array, and shove into a spreadsheet for analysis. - intrusive, though this can be kept low - requires a couple words of RAM for each measurement + easy to code + can get every measurement, not just a sample (given enough RAM) + can easily add other events into the log, each with a unique tag and timestamp. A simple procedural interface to the logging facility makes this easier: procedure Log_Event( Event: in Event_Types ) is ... Variation: keep track of min/max/average on the fly, avoiding the need for a large RAM event buffer. - additional overhead due to run-time calculations + cuts down on RAM. No need for post-mortem analysis. 4. Flash a red LED on and off, and use a stopwatch ;-) Good luck! .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West San Diego, CA 92121-9891 "There's too much caffeine in your bloodstream..." (619) 457-2700 x163 -- The Smiths ------------------------------------------------------------------------------