Open side-bar Menu
 Embedded Software
Colin Walls
Colin Walls
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »

Measurement of interrupt latency

December 19th, 2017 by Colin Walls

The term “interrupt latency” is widely used, but, like a lot of technical terms, its meaning is sometimes unclear. This is our first challenge – to define our terms. The second challenge is to make a meaningful measurement.

Most RTOS vendors quote interrupt latency figures for their products. However, they may be referring to either one of two time intervals. In both cases, they are talking about the delay before an interrupt is serviced, but there are two ways to see this:

  1. System interrupt latency – the interval between the assertion of the interrupt signal and the starting of the code to process that interrupt. This is represented by the long orange arrow in the diagram below.
  2. OS interrupt latency – the time overhead added by the RTOS to the “normal” processing of an interrupt. This is represented by the short arrow.

Many vendors use definition #2 because it looks good. Some even quote “zero latency”, which sounds even better. However, this value is not really very useful. #1 has much more practical significance.

Figures quoted by RTOS vendors may be useful, once the terminology is figured out, but remember the figure is dependent on a number of factors which may not align with your system design:

  • which platform and interrupt controller is being used?
  • clock speed
  • cache configuration
  • timer frequency
  • what kind of memory is the RTOS running out of?
  • was the kernel built optimized for speed?

Clearly it might be more useful to make the measurement yourself.

To measure short time intervals in any electronic system, you need an instrument. And the best tool for this kind of job is an oscilloscope. One approach is to use one pin on a GPIO interface to generate the interrupt. This pin can be monitored on the ‘scope. At the start of the interrupt service routine, another pin, which is also being monitored, is toggled. The interval between the two signals may be easily read from the instrument.

I can imagine that a software engineer may be appalled by the thought of using an oscilloscope, but this might be an ideal opportunity to liaise with your hardware design counterpart. Actually, such liaison might be a good idea anyway …

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


ClioSoft at DAC
TrueCircuits: IoTPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise