With the popularity of the Arduino, PICAXE, Propeller, Raspberry Pi, BeagleBone, and other micros now on the market (with some of them
prominently featured in this magazine), the choices for the
hobbyist have no real bounds these days. Given all these
great microcontrollers, building a cool circuit and
programming one of them is a great first step.
When things go wrong, however — especially in the
firmware area where it then becomes a show stopper —
what mechanisms do you have to debug your code? One
way, of course, is to examine your code line by line and
“hope” that you’ll discover the error in your ways. It’s
worked for us in the past as we’re sure it has for you, but
it’s time-consuming and iffy at best.
Once you find the errant instruction(s), you can recompile the code and test it again (and again, and again)
until it works. This takes a lot of discipline and a good
“feel” for what your code is supposed to be doing. It’s
doable, but it’s not the most efficient in terms of time
spent debugging. As a result, it may take lots of head
scratching — not to mention many compiles — to solve the
problem. Using this method, you don’t have any visibility
into what’s going on inside your micro; your thought
process is all you have.
To Plot or Not To Plot
Another way to debug your code is to output the
analog or digital data that your code generates to your
monitor in order to get a visual image of what’s
happening. Terminal programs like Hyper Terminal can do
this, but the data are all numbers. This makes a lot more
sense compared to just “visual” code parsing as it can
lend some hints to what’s wrong, but numbers alone don’t
tell the whole story of what’s going on that’s causing your
problems. Instead, a picture is worth a thousand words
So, if the internal data you’re displaying is graphic in
nature (like plot lines of individual data), it’s even simpler.
With this graphical information, you can locate your
problems much faster and with greater precision as
compared with just number-based debugging or manually
stepping through your code to try and find the problem.
This is especially true if you’re trying to isolate
intermittent problems that occur infrequently, like those
that depend on an external input voltage source — a
potentiometer or light sensor value that’s converted by an
A2D converter into a digital value (threshold and alarm
settings come to mind), for example. Let your code run
normally, adjust the pot and light levels, and the graphic
display will probably show you where the problem lies
Unless you’re a purest that nearly always builds their
own handmade circuits, you’re generally going to purchase
an off-the-shelf “working” hardware board with your favorite
micro embedded into it. Since you didn’t design and build
the hardware portion yourself, you can (correctly) assume
the hardware part of your project is working given that
you’ve applied the correct wire hookups, voltage inputs,
etc. All these new micro boards are great hardware animals,
and they all generate analog and digital data. So, the
questions remain: “How do you plot, log, and display this
data?” and “How do you debug your code without an
external reference as to what’s going on?”
The DIY Software Kit
By John Gavlik and
Go to www.nutsvolts.com/index.php?/magazine/
You can also post comments.
Since you’re a Nuts & Volts reader, you
probably have done — or will do — a
microcontroller project at some point.
When you do, you’re probably going to
generate data with your micro. So, have
you thought about how that data is
displayed, logged, debugged, or
otherwise gets presented to you for
display and analysis?
48 October 2013
MakerPlot is available as a FREE 30 day trial
download from www.makerplot.com.
If you like what you see and what it does, you can
order it from the NV Webstore at a discounted price!