[Design View / Design Solution]
Take The Guesswork Out Of Debugging
Move past the hit-and-miss game of “printf()” debugging, and instead look to streamline the task with run-time visualization tools.
By doing so, however, engineers would temporarily prevent an application from processing additional packets. Thus, when restarting execution, the application may not complete its expected state transitions. In fact, in response to the code’s lack of activity, the attached PC could assume that the device malfunctioned.
Given the drawbacks of stopping code, one might revert to p r i n t f ( )in this situation. However, that would be trading one set of problems for another. Neither p r i n t f ( ) nor a watch window would be an optimal means of monitoring the USB application’s variables.
RUNTIME VISUALIZATION To avoid the hassles of p r i n t f ( ) and watch windows, engineers can turn to a tool such as the µC/Probe. Developed by Micrium, µC/Probe monitors an application’s data non-intrusively, meaning that there’s no need to halt the processor to view updated variable values. Furthermore, µC/Probe isn’t text-based, since it presents data in a graphical format. As such, it’s considered a runtime visualization tool.
When using this tool, there are few limits on what can be observed. Importantly, it’s not necessary to write a new line of code whenever a new variable is viewed. Access to all global variables is gained by adding just a small amount of code to the application. No matter how much data one gathers, the amount of code that must be added to the application doesn’t change.
Since µC/Probe can leverage the advanced debugging features of ARM’s Cortex-M3 processor, engineers who are working with this processor can actually use the tool without adding any new code to their applications. All of the supplemental code needed to support µC/ Probe on these processors comes with the tool. The pseudocode in listing 3 provides an overview of this simple code’s functionality.
The code represented by Listing 3 can be viewed as one of two components that make up µC/Probe. You select, via #define constants, whether this code will comprise one of the application’s ISRs or (for RTOS users) will be repeatedly executed within a low-priority task. In either case, the Heisenberg effect is minimal. The tool doesn’t adversely impact system responsiveness.
The other component, which is an application that runs on a PC, regularly transmits commands that are ultimately processed by this code. Commands can be passed between the two components via any of the popular communication protocols supported by µC/Probe. Because this list of protocols includes JTAG, TCP/IP, USB, and RS-232, the tool can be used in the absence of debug probes and other specialized hardware.
As Listing 3 indicates, each of the commands transmitted by the Windows portion of µC/Probe instructs the embedded system to read or write a particular memory address. The addresses specified in the commands correspond to the application’s variables. The tool extracts these addresses from an executable file, provided that this file is in ELF format. Since most compilers can produce an ELF file, µC/Probe can be used with almost any tool chain, including, most likely, the one currently used to develop code.
Unlike p r i n t f ( ) or any watch window, the tool enables the creation of a visually appealing user interface for the embedded system (Fig. 3). Within the aforementioned Windows application comes a palate of graphical components, including gauges, graphs, dials, and switches. Dragging and dropping these components onto a µC/Probe data screen makes it possible to put together a control panel that allows you to read and write any application variables.
While the graphical paradigm underlying µC/Probe should be refreshing to users of p r i n t f ( ) and watch windows, it’s not unprecedented. For years, engineers have been using National Instruments’ LabVIEW to graphically develop virtual test instruments.
LabVIEW is actually a graphical programming language, and in many ways it’s just as powerful as a standard programming language. Accordingly, it has seemingly limitless uses. In recent years, an increasing number of embedded systems developers has discovered LabVIEW, harnessing this tool to design and prototype both hardware and software.
On the software side, LabVIEW gives engineers the potential to create incredibly helpful monitoring tools. If you’re not a LabVIEW expert, unlock this potential with the help of iSYSTEM’s winIDEA Embedded Test Integration Toolkit for LabVIEW. As its name indicates, this product weds LabVIEW and iSYSTEM’s winIDEA development environment.
With regards to monitoring an application’s data, the most important of the multiple tools that comprise the product is the LabVIEW Debugging Workbench for winIDEA VI Communication. Using this tool, it’s possible to combine a variety of graphical components into a front end for the embedded system, without actually doing any LabVIEW programming.
Reprints
