Follow @jack_ganssle

The logo for The Embedded Muse

For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.

Want a Want a copy of Jean Labrosse's excellent uC/OS-III, The Real-Time Kernel book? Enter the contest here.

The Embedded Muse Video Blog

(Go to the complete list of videos)

Episode 12: How to Turn a $25 VOM Into a $10k Performance Analyzer

September 15, 2014

If you're building a real-time system, you must understand the firmware's real-time behavior. For instance, how much idle time is available? Some pricey tools exist for this. In this video Jack shows how a $25 VOM can give tons of insight into how busy the system is.

Video Transcription

Hi, I'm Jack Ganssle and welcome to my Embedded Muse Video Blog, which is a companion to my free online newsletter, "The Embedded Muse."

Today, we're going to do a short talk about measuring idle time in real time systems. It's interesting, we build these real time systems where we know that if we violate any time perimeters, the system's going to fail, and all too often we don't measure time. To me, engineering is all about measuring things. If you don't measure things, it's not engineering, it's art. When it comes to something that's critical to the performance of the system, like the real time behavior, we've got to take some data. It's pretty easy to do. If you have a free GPIO bit, you can toggle that bit when nothing's going on. But, things tend to get a little bit more complicated than that. It can be difficult to understand the results sometimes.

So here's my board. My program is driving a GPIO bit high whenever the system is idle. I'm monitoring that bit with the oscilloscope. That data is pretty hard to interpret. What does any of this mean? This is of course a real program in which idle time is not constant, it varies depending upon the workload of the software. The scope's giving us a lot of data, but it's hard to make sense of it. But, it gets worse. In the real world of embedded systems, often we use an RTOS. If you're using an RTOS, there is no idle loop. There's nothing to instrument, what do we do?

There is a cool trick. Get this meter from Radio Shack. It's $25. Don't get a digital multi meter. Don't get a digital anything. Get this really bottom of the line meter with a needle. Then, like I said, instrument your code to drive a GPIO bit high when a system is idle and low when it's not. It's not going to work with an RTOS, so in that case what you do is you find the idle test hook. This is a function that most RTOSs provides. It's a null function that gets called when the RTOS says,"Nothing to do. There's nothing inside of it." It's there for us to instrument. In this case, with this code, you can see this is for a Micrium MicroC/OS. I've instrumented that function in order to drive this bit up when there's nothing going on.

The next part of the equation is to solve this equation, which is basically the voltage. Max volt, it's the voltage of your system. If it's a five volt system, it's five. A three volt system is three. This will give you a resister. Find a potentiometer that is somewhat bigger than the resister value that was calculated in this equation. Now take the meter apart. There's one screw that holds the back on. You remove the back and you'll see this 29K resister in there. You can either clip that resister out or in this case what I needed was a 5K put, so I just soldered it across the 29K resister. Because 29K and parallel with 5K, it's pretty close to 5K.

Now you set the volt meter to measure DC volts. Connect the ground lead to your system and connect the hot lead to the GPIO bit that you're toggling in that idle task loop. What we're effectively doing is using the mechanical inertia of the needle to damp out out all those rapid variations that you saw on the oscilloscope.

The next step is to calibrate the meter. Have your system 100% idle, so it's just running that idle task hook and really nothing else. Turn the pot so that the needle is all the way over at the right. Now the volt meter is an idle meter. When the needle's all the way to the right it's 100% idle. When it's all the way to the left it's 0% idle. Of course, in between represents other levels of idleness, so to speak.

So check it out. The volt meter is giving us the idle time. You can see it varying in real time as the behavior of the program changes. The scope is showing the same stuff, but it means absolutely nothing to me. I like to hook up a meter like this to a system on the very first day of the project so that you track where the idle time is going. I mean, supposed you're debugging along. You've got 80% idle, 78% idle, 76% idle, whoops 30, what's gone wrong? Well, whatever the last step you took is where the problem is.

Of course, this isn't going to work in every circumstance. If your idle time changes rapidly, well the silly little needle won't be able to keep up. But, in a large number of cases this is a really cheap way of getting some good performance data.

So there you have it. A $25 volt meter can give you tons of insight into the real time behavior of your system. Thanks for watching and don't forget to go to where there are over a 1000 articles and plenty more videos about better ways of building embedded systems.