I seem to find little mention of debugging techniques here.
Is the arduino IDE simply a compile and upload facility?
Yep, pretty much.
Maybe I'm just not looking in the right place but there seems oddly little talk of how to do debugging here.
Thanks for any pointers.
For any real sort of real debugging (which I assume you mean at the source level with variables, break points etc...)
you will want to use gdb or some GUI wrapper around it.
And to do that you will probably want/need to use makefiles to make sure you set
up everything the way you want it.
The Arduino IDE is simply too wimpy and didn't use Makefiles underneath so it is pretty
painful to use the debugging tools with the Arduino IDE.
You can choose to abandon the IDE (there are some makefiles out there that come close to working similarly)
or leave Arduino and its libraries behind and write your own code using avr gcc with makefiles,
or use AVR studio
You can use AVR studio if you are still using windows and want a GUI solution for Windows based OS's.
Alternatively you could use something like eclipse - I think they have some Arduino plugins now.
You will also then need some additional hardware that can access the chip on behalf of the
debugger. The AVR dragon is probably the most cost effective device for source level debugging.
It can use the ISP port, JTAG pins, or can use the reset line (debug wire mode) to access the internal chip resources.
Debug-Wire is very cool as it only uses a single pin that usually is not used for anything else anyway.
As far as "back to the world of the 80s" type debugging goes.
Boy do I wish it was that good on the AVR. By the late 80's gdb was already fully
working in many embedded environments
and true source level debugging with breakpoints and access to variables
was easily accomplished over a serial port
with the simple addition of a gdbmon to your embedded target code.
Today, on the AVR, life is not so simple nor as good. The Harvard architecture really throws
a wrench in things, (much of this issue has work arounds) but as far as having a gdmon goes
that allows source level debugging over a serial port goes, it is non existent.
There are some technical issues in making something like a gdbmon interface fully work
on the AVR so at this point everyone that wants
source level debugging is using a h/w tool that can be controlled by a debugger - usually gdb.
Tools like the AVR dragon or JTAGice are used. This is what avr studio and packages like DDD use)
I've often thought about doing a gdbmon for the AVR. Break points and single stepping
can be made to work but are ugly under the hood as you have to steal one of the interrupt pins.
I've just not had the time and an AVR dragon using debug-wire is actually better anyway.
For now, you are kind of stuck with a few options.
- use IDE "as is" and revert to using primitive debugging techniques like
"printf()", toggling pins, LEDs, etc...
- switch over to a more advanced build/development environment and use a h/w debugging tool
like the AVR dragon or JTAGice
If you switch build environments, you will have to decide if you want to stick with
the Arduino s/w environment or leave it behind as well.
If using a windows platform, AVR studio is a pretty nice tool set and offers full debugging
as well as a simulator.
You could use AVR studio with some "Arduino" makefiles to allow using AVR studio and its
debugging tools with the Arduino s/w environment and libraries.
You can also ask questions over on the AVR freaks site about AVR (non Arduino) development:
For realtime runtime debugging even having a source level debugger may not help.
For example you may need to see a certain stream of events in real time.
A break point won't help in that situation as it halts the processor.
For sure anything like a serial port transfer will kill the realtime timing.
kiss i2c goodbye it is WAY slower than a serial port, even SPI can be too slow.
For these situations, I use multiple output pins and a logic analyzer.
You can assign an event to a pin or use a collection of pins along with a "strobe" indicator pin
to indicate the event. On the AVR, this allows indicating an event in as little a single AVR clock cycle
since if you pick your pins carefully you can update them all in a single write to the port register.
This is very unobtrusive to timing.
I've used this output pin strobing technique on many systems over the past 30 years especially for very
realtime systems where you simply can't do much of anything or something bad can actually happen
(like corrupt the format of the hard disk - in the case of disk controller)
It is very easy to implement, uses a very small amount of code in the target
and gives you realtime visibility into the code flow.
It is great for profiling routines as you can do strobes around portions of code to time it.