# Category: Insight

Something you have not known before

The featured image of this post is by Emphyrio on Pixabay

In parasitic power supply mode, a device sucks its juice from a data line instead of from the power rail. This can be intended or unintended. In the latter case, all sorts of funny things can happen.

Make it Fail

(David J. Agans)

The quote is from Dave’s book Debugging: the 9 indispensable rules for finding even the most elusive software and hardware problems, which I recommend to everybody who has to debug a technical artifact.

Another xkcd comic that hits the spot. Except, with my new hardware debugger, this is the past 😎. Recently, I debugged one of my electronic geocaching gadgets and was positively surprised how easy it was to figure out ones own mistakes and to come up with the right fix.

The featured image of this post is by WikiImages on Pixabay

You want to make a single step in your program, but the debugger takes you to some unknown area of the program. This was, in fact, my first experience when I tried out Microchip’s MPLAB X IDE debugger on the innocent blinking sketch. Is this a bug or a feature?

There has never been an unexpectedly short debugging period in the history of computers

… but the periods might have become shorter with the right tools

The featured image of this post is by Albert Guillaume – Gils Blas, 24 décembre 1895, Public Domain, Link

When you develop a tool for a protocol that is undocumented, it is not surprising that you will encounter situations you will not have be anticipated. And this was exactly what I experienced developing the hardware debugger dw-link, which connects debugWIRE MCUs to the GDB debugger. Although a substantial part of the debugWIRE protocol has been reverse engineered, I encountered still plenty of surprising situations: Split personality MCUs, stuck-at-one bits in program counters, secret I/O addresses, half-legal opcodes, and more.

The featured image of this post is is a comic from xkcd.com.

The above xkcd comic, which is titled Debugger, alludes to the concern that when you try to apply a particular method to itself, you might not get what you asked for. Turing’s Halting problem is a very famous example of this, i.e., you cannot algorithmically decide whether an algorithm terminates on an input. So, does that issue apply to debuggers as well? In particular, I asked myself whether it makes sense to debug the hardware debugger I am developing with itself.

The featured image of this post is based on a picture by TheDigitalArtist on Pixabay.

Link-time optimization (LTO) is a very powerful compiler-optimization technique. As I noticed, it does not go very well together with debugging object-oriented programs under GCC, at least for AVR MCUs. I noticed that in the context of debugging an Arduino program, and it took me quite a while to figure out that LTO is the culprit.

The featured image of this post is by Vladimir163rus on Pixabay.

A new Arduino library has seen the light of day: SingleWireSerial. It supports single-wire, asynchronous serial, half-duplex communication. By using the input capture feature of the AVR MCUs, it is extremely accurate and supports bit rates up to 250 kbps robustly. And contrary to its title, one can even use it in a two-wire setting.