Design Con 2015

Two completely unique products

March 30, 2008

JackGanssle-March 30, 2008

Most of the many dozens of press releases that daily flood my in-box gush over minor product upgrades or wax poetic about a contract award. But once in a while I run into a truly novel product that is exciting or important. Micrium's new µC/Probe fits that description.

One of the classic distinctions between embedded systems and other types of computer applications is visibility. A PC programmer can seed his programs with printf()s and even populate special windows with variables and classes. An embedded system often has no display, or one that's very limited, so those sorts of debugging strategies just don't work.

On top of that, about 70% of embedded apps have a real-time operating system. Multiple activities competing for scarce resources furiously sequence themselves, creating and releasing stacks and other resources, yet the developer has only the slightest insight into what is going on.

Intel addressed this issue in the '70s with the introduction of the MDS-800, the first in-circuit emulator, which gave developers hardware breakpoints and real-time trace to capture program flow and variable states. But that sort of great technology, still in use today though usually manifested in BDM and JTAG debuggers, only gives snapshots of activity rather than a real-time and uninterrupted view of what was going on. It's like operating a nuclear power plant by stopping the dynamos once in a while and dipping a ladle into the cooling water to take temperature measurements.

Wouldn't it be nice to see the A/D's output all the time? A continuous graph might be even nicer. Or watch all of the stack pointers' high water marks? That's how industrial plants work: operators have an array of gauges that continuously read out critical parameters.

Micrium, of µC/OS-II fame, (www.micrium.com) has a tool that does all of this and more. µC/Probe is a hard-to-describe application that samples any number of your program's variables in real-time and displays them in pretty much any manner you'd like. Connect them to virtual gauges, spreadsheets, LEDs, or other sorts of widgets to create an industrial control room for your code.

A few kilobytes of code or less lives in your firmware to provide a communications channel to your PC, via a serial port, USB, TCP/IP, or the ARM J-Link protocol. A Windows application forms the meat of the product. In "design mode" µC/Probe offers a big palette of graphical resources ("widgets") that you drag onto the screen. A symbol browser shows your program's variables and classes. Click on a display widget (like a gauge) to bring it into focus, and with just one more click you associate a variable with that widget. You'll need a toolchain that produces Elf or IEEE-695 so µC/Probe knows about your symbols.

Enter "run" mode and µC/Probe starts sending periodic request for the variable values to the target, which are then displayed in the appropriate widgets, shown in Figure 1.

View the full-size image

In the figure, two spreadsheet widgets monitor a number of variables associated with multitasking (in this case via µC/OS-II, although it will work with any RTOS, and, of course, with no RTOS). Notice that in this case the spreadsheet shows the stack's current and high-water marks, as well as the CPU loading by task. Think how easy it would be to find performance problems! The gauge displays another variable in both an analog and digital format (in the odometer).

"CPU Usage:" and "%" are text blocks I defined in design mode. They're static, unchanging, and not terribly interesting. But as shown, even text blocks can have associated variables. It takes seconds to connect a symbol to a widget, so is far easier than adding the printfs our PC friends merrily sprinkle throughout their code.

In design mode, choose from lots of widgets, like a variety of moving graphs, LEDs, several sorts of gauges, bar charts, spreadsheets, and switches and knobs. That's right: data can flow both ways. Want to stress test an application? Connect a knob to an update rate and crank it up to see, perhaps on a graph, how CPU utilization climbs.

The spreadsheet widget is essentially Excel with most of that application's functions and capabilities. So it's trivial to convert a binary A/D reading to engineering units or implement a filter or curve fit. Hyperlink support means you could display a value from a web-enabled instrument in a cell or use that input to compute some other value. The possibilities for creating a test harness are simply breathtaking.

I think there's tremendous value in setting up µC/Probe to run all the time, not just when you're looking for a particular problem. Display task status, stack usage, and the other parameters so critical to building a reliable embedded system. Toss in widgets monitoring analog parameters or computed results. My computer has dual monitors, so I put µC/Probe on one and the IDE on the other, giving me both sorts of views into the code. That gives me a tremendous amount of visibility under the hood of a normally inscrutable embedded system.

With a lot of widgets, the communications channel to the target can get pretty busy, but it's possible to control the update rate and to allocate variables to slow or fast queues. On a 25-MHz ARM9 at the max update rate, about 200 kbytes/sec were being transferred, burning 60% of the CPU's cycles. But at a more reasonable 10 kbytes/sec, that dropped to an inconsequential 2.5%. Micrium has versions for a number of processors (it will run on any CPU from 8 bits on up), but the source includes complete porting instructions and test cases.

µC/Probe is a big application and wants some decent PC horsepower, a situation getting more common in these Eclipse days. Priced at about $1,000, it's a tool I've wanted for a long time. Highly recommended.

< Previous
Page 1 of 2
Next >

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER