Page 160 - The Art of Designing Embedded Systems
P. 160

Troubleshooting Tools  147

                        OrCillO~opeS

                        Emulators, ROM monitors, and the like are great for viewing your
                   code from the perspective of the CPU. Their tentacles into your target sys-
                   tem stop at the CPU socket, so events occurring beyond that point (say, in
                   an YO  device) are almost invisible. You can see the IN and OUT instruc-
                   tions and the transferred data, but it’s pretty hard to check out timing rela-
                   tionships, or how the software interacts with the hardware.
                        Sure, most of these tools have external inputs that you can couple to
                   any point in the system. Few programmers use them. Perhaps this is be-
                   cause the display is so static. You have to actively recollect data and then
                   tediously sort it all out. For example, if you feed an external input to a real-
                   time trace buffer, you’ll collect tons of bus activity that may or may not be
                   important.
                        If  all you  really care about is the relationship  between two events
                   (say, a switch closure and the resultant interrupt), why dig through thou-
                   sands of cycles? It is important to arm ourselves with as many tools as pos-
                   sible. No one tool is perfect for every problem.
                        One of my all-time favorite software debugging tools is the oscillo-
                   scope, colloquially known as the “scope.” Hardware guys seem to have a
                   scope attached as a pseudopod to one arm. Any development lab is invari-
                   ably filled with benches of scope-happy troubleshooters probing the mys-
                   teries of  some electronic  marvel.  The software community  seems less
                   comfortable with this tool, which is a shame because it can painlessly yield
                   crucial information about the operation of your code.
                        A  scope is really  nothing  more than a device that displays  one or
                   more signals. Most can simultaneously show two independent values.
                        The scope’s raison d’etre is displaying the signals’ voltage (ampli-
                   tude) over time.
                        A  simple time-varying  signal is the power coming from your wall
                   outlet. This is a 60-Hz sine wave (i.e., the voltage smoothly rises from 0 to
                   120 and back to zero again 60 times a second). It moves too fast to follow
                   with a voltmeter. On a scope display, the waveform’s voltage at any point
                   in time is crystal clear.
                        Software folks used to working with only a keyboard are sometimes
                   intimidated by the sea of knobs on any decent scope’s front panel. A bit of
                   experience makes working with this tool natural.
                        From the user’s standpoint the average scope has three major sec-
                   tions. A “vertical” amplifier sets the display’s up/down limits. The “hori-
                   zontal’’ portion controls the beam’s lefvright scanning. “Trigger” circuitry
                   synchronizes the scan to your input waveform.
   155   156   157   158   159   160   161   162   163   164   165