Category: Insight

Something you have not known before

Surprise, Surprise!

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. 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 plenty of surprising situations: Split personality MCUs, stuck-at-one bits in program counters, secret I/O addresses, half-legal opcodes, and more.

Continue reading

Debugging a Debugger With Itself

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.

Continue reading

Link-Time Optimization and Debugging of Object-Oriented Programs on AVR MCUs

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.

Continue reading

Is any Input Available?

The featured image of this post is by rawpixel.com – de.freepik.com

The SoftwareSerial class has the available() method, which returns the number of characters that have been already received but not yet read. This is very similar to what the standard Serial.available() method offers. There is an interesting difference, though. A call to SoftwareSerial.available() is significantly slower than a call to Serial.available(). We will look for the deeper reason for this strange behavior and I will show you three ways how to fix it.

EDIT: The problem will vanish with Arduino version 1.8.17

Continue reading

Copyright © 2024 Arduino Craft Corner

Theme by Anders NorenUp ↑