Journey vs. Destination

A podcast listener requested a show about debugging. I’m still working out just what he meant by that but between that and working on a Trinket, I find I have a few things to ponder aloud for you.

First, the Trinket is a small board with an ATTiny85 on it. It is a very low power, deeply embedded sort of processor. With all of 8k of code space and 512 bytes of RAM (and 512 bytes of EEPROM), this is a dinky little thing. Plus, with the on-board bootloader, there is only about 5000 bytes of code space. I feel like a kid again.

So why in the world would anyone use the Arduino interface with this? Well, it is what I have, it is what Adafruit had in their tutorial, and I’m too unmotivated to set up a GCC cross compiler (yet).

Usually when I use the Arduino compiler, it is with a proper Arduino board (or the MicroView which is a “proper Arduino board” for this discussion). Debugging is done via printf because there is a serial connection via USB after the bootloader has finished programming the board.

Under “Debugging Tools” on my resume, I have “DVM, oscilloscope, logic analyzer, JTAG, ICE, printf” so I’m fine with printf as a way to determine what is going on with my code. On the other hand, if I can have an on-chip stepping debugger, I much prefer that. But that isn’t an option with the Arduino compiler so I limp along. Nothing I do on an Arduino is all that complicated.

All that said, the ATTiny doesn’t have the serial debug interface. There is no on-chip debugger and no printf. That means debug is usually through GPIO lines and prayer.

There are tools that could help me. I think. But I’m trying to do it the way everyone else is. Or the way I think they are. I’m writing little pieces of code and running them. I’m blinking the little onboard LED once for good, three times for an error. It look a stupidly long time for me to figure out why my byte variable wasn’t getting to 256. It isn’t impossible to work like this but it is a lot harder.

So, yeah, maybe it is time to talk about debugging. We could start with Arduino (and mbed) and debug through printf. Then go into the tools available for that space. Then the SWD interface for the ARMs (i.e. Cortex-M0). What are ITMs and ETMs anyway? We could talk about timing errors due to debugging (both serial and on-chip). We could talk about the extras that are available on some IDEs (mmm… profiling and backtraces!). We could talk about GDB, how it is super powerful but opaque and a pain to the beginner. We could even talk a bit about data logging and error handling (other listeners have requested shows about these).  I wonder if we’d even get into unit tests since some systems I’ve developed for run on-target-hardware via debugger.

I feel a lot more secure and confident when I can see what my chip is doing. I don’t mind using printf but I’m better at getting things done with better tools. Most tools are cheap compared to my time.

So yeah, debugging…