When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead”→
While you can get somewhat similar functionality out of standard debuggers, penguinTrace was purpose-built to facilitate exploration of how the whole process works. You can single-step through the instructions your code compiled to, examine variables, and look at the stack — the usual debugger stuff — but structured more for exploration and learning than full-on debugging. Based on our experiences when we learned low-level programming, anything that can help novices build that all-important mental picture of what’s going on underneath is a good thing. But, since it was written with a secondary purpose of learning how debuggers themselves work, it’s a great opportunity for exploring that space, too.
The UI harnesses CodeMirror to provide a browser-based interface, and is configurable to use Clang or GCC for compilation. It supports AMD64/X86-64 and AArch64 architectures, and will run on Windows using WSL: if you’ve got a PC running Linux, a Raspberry Pi, or a Windows box, you’re good to go. The code is AGPL-licensed and available on GitHub. So, if you want to gain a better understanding of what happens when you compile and run “hello, world,” grab a copy and start exploring.
We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.
[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging”→
Debuggers come in all shapes and sizes, offering a variety of options to track down your software problems and inspecting internal states at any given time. Yet some developers have a hard time breaking the habit of simply adding print statements into their code instead, performing manual work their tools could do for them. We say, to each their own — the best tools won’t be of much help if they are out of your comfort zone or work against your natural flow. Sometimes, a retrospective analysis using your custom-tailored debug output is just what you need to tackle an issue.
If the last part sounds familiar and your language of choice happens to be Python, [Alex Hall] created the Bird’s Eye Python debugger that records every expression inside a function and displays them interactively in a web browser. Every result, both partial and completed, and every value can then be inspected at any point inside each individual function call, turning this debugger into an educational tool along the way.
With a little bit of tweaking, the web interface can be made remote accessible, and for example, analyze code running on a Raspberry Pi. However, taking it further and using Bird’s Eye with MicroPython or CircuitPython would require more than just a little bit of tweaking, assuming there will be enough memory for it. Although it wouldn’t be first time that someone got creative and ran Python on a memory limited microcontroller.
As every Hackaday reader knows, and tells us at every opportunity in the comments, adding an Arduino to your project instantly makes it twice as cool. But what if, in the course of adding an Arduino to your project, you run into a problem and need to debug the code? What if you could use a second Arduino to debug the first? That would bring your project up to two Arduinos, instantly making it four times as awesome as before you started! Who could say no to such exponential gains?
Debugging an ATTiny85
Not [Wayne Holder], that’s for sure. He writes in to let us know about a project he’s been working on for a while that allows you to debug the execution of code on an Arduino with a second Arduino. In fact, the target chip could even be another AVR series microcontroller such as a the ATTiny85. With his software you can single-step through the code, view and modify values in memory, set breakpoints, and even disassemble the code. Not everything is working fully yet, but what he has so far is very impressive.
The trick is exploiting a feature known as “debugWIRE” that’s included in many AVR microcontrollers. Unfortunately documentation on this feature is hard to come by, but with some work [Wayne] has managed to figure out how most of it works and create an Arduino Sketch that lets the user interact with the target chip using a simple menu system over the serial monitor, similar to the Bus Pirate.
[Wayne] goes into plenty of detail on his site and in the video included after the break, showing many of the functions he’s got working so far in his software against an ATTiny85. If you spend a lot of time working on AVR projects, this looks like something you might want to keep installed on an Arduino in your tool bag for the future.
If you’ve done 3D printing, you’ve probably at least heard of Tinkercad. This popular CAD package runs in your browser and was rescued from oblivion by Autodesk a few years ago. [Chuck] recently did a video about a new Tinkercad feature: building and simulating virtual Arduino circuits. You can watch it below.
There are a variety of components you can add to your design. You’ll find an integrated code editor and a debugger. You can even get to the serial monitor, all in your browser with no actual Arduino hardware. You can also build simple circuits that don’t use an Arduino, although the component selection is somewhat limited.
One of the best feature of the ESP8266 is its ability to self-host a web server, allowing for fairly complicated user interactions. The dEEbugger by [S-March] is a nifty little ESP8266 based device with a plethora of features in a small package.
The USB-powered device has a web user interface that enables it to be used as a low-bandwidth oscilloscope, I2C terminal, or UART terminal. As a scope, you may connect to it via your tablet and then use it as a remote voltage monitor. There is a peak detection feature which is a nice touch and gives the entire project a premium feel.
The serial terminal on an ESP8266 is not something new yet it is helpful in disconnecting the console window from the bench. The I2C terminal is where the device really shines as it can scan for connected devices on the connected bus. This Bus-Pirate like feature is useful for beginners as the software can scan the registers addresses of the devices as well.
[S-March] has made the schematic in PDF format as well as the entire code for the project available on GitHub so go right ahead and make it your own. We have had an ESP8266 based VT Terminal device in the past and merging the two would make for an excellent maker tool.
