For as popular as the Arduino platform is, it’s not without its problems. Among those is the fact that most practical debugging is often done by placing various print statements throughout the code and watching for them in the serial monitor. There’s not really a great way of placing breakpoints or stepping through code, either. But this project, known as eye2see, hopes to change that by using the i2c bus found in most Arduinos to provide a more robust set of debugging tools.

The eye2see software is set up to run on an Arduino or other compatible microcontroller, called the “probe”, which is connected to the i2c bus on another Arduino whose code needs to be debugged. Code running on this Arduino, which is part of the eye2see library, allows it to send debugging information to the eye2see probe. With a screen, the probe can act as a much more powerful debugger than would otherwise typically be available, being able to keep track of variables in the main program, setting up breakpoints, and outputting various messages on its screen.

The tool is not without its downsides, though. The library that needs to run on the host Arduino slows down the original program significantly. But for more complex programs, the tradeoff with powerful debugging tools may be worth it until these pieces of code can be removed and the program allowed to run unencumbered. If you’d like to skip needing to use a second Arduino, we’ve seen some other tools available for debugging Arduino code that can run straight from a connected PC instead.

Being able to track down a bug in a mountain of source code is a skill in its own right, and it’s a hard skill to learn from a book or online tutorial. Besides the trial-by-fire of learning while debugging your own project, the next best thing is to observe someone else’s process. [Uri Shaked] has given us a great opportunity to brush up on our debugging skills, as he demonstrates how to track down and squish a bug in the Wokwi Arduino simulator.

A user was kind enough to report the bug and include the offending Arduino sketch. [Uri]’s first step was to reduce the sketch to the smallest possible program that would still produce the bug.

Once a minimal program had been produced, it was time to check whether the problem was in one of the Arduino libraries or in the Wokwi simulator. [Uri] compiled the sketch, loaded it onto a ATtiny85, and compared the behavior of the simulator and the real thing. It turns out the code ran just fine on a physical ATtiny, so the problem must have been in the Arduino simulator itself.

To track down the bug in the simulator, [Uri] decided to break out the big gun—GDB. What follows is an excellent demonstration of how to use GDB to isolate a problem by examining the source code and using breakpoints and print statements. In the end, [Uri] managed to isolate the problem to a mis-placed bit in the simulation of the timer/counter interrupt flag register.

If you’d like to see more of [Uri]’s debugging prowess, check out his dive into an ATtiny’s write protection and configuration fuses. If you’ve been wowed by the power of GDB and want to learn more, check out this quick tutorial!

There have been plenty of Z80 computer builds here on Hackaday, but what sets them apart is what you do with them. [Andrew] writes in with his Z80 single-board computer made from scratch, using the Arduino standard headers for its I/O. In turn, since he needed an easy way to program the flash memory which holds the software to run on the Z80, he used an Arduino Mega as a debugger, making the SBC an Arduino shield itself.

Using such a common header pinout for the Z80 computer allows it to be used with a variety of readily-available Arduino shields. This compatibility is achieved with an analog-digital converter and a 3.3 V regulator, mimicking the pins found in an Arduino Uno. The code, available on GitHub, includes an extensive explanation and walkthrough over the process in which the Mega takes over the bus from the Z80 to function as a fully-featured debugger. Programs can be loaded through embedding an assembly listing into the Mega’s sketch, or, once the debugger is up you can also upload a compiled hex file through the serial connection.

This isn’t the first time [Andrew] has been featured here, and his past projects are just as interesting. If you need to translate a Soviet-era calculator’s buttons into English, hack a metallurgical microscope or even investigate what’s that Clacking Clanking Scraping Sound, he’s the one you should call.

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?

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.

Debugging microcontroller projects can be a huge time saver when your code starts running on real hardware, but often takes some hacking to get working.

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.

This could be great for teaching Arduino in classrooms or when you want to do some development in a hotel room. The layout is very visual, so if you are accustomed to reading schematics, you may not appreciate the style. In addition, the selection of components is somewhat limited (including only supporting the Arduino UNO, as far as we could tell). So for educational purposes, it is great. For breadboarding your next great Arduino-powered robot, maybe not so much.

If you remember Circuits123 (or circuits.io), this is the same underlying technology. They’ve just integrated it with Tinkercad. However, there doesn’t seem to be any real integration between the two other than they are on the same web page now. Perhaps in the future, they’ll let you drop components on the circuit that also show up in the 3D design (or, at least, with sockets or holders for those components).

However, having a simulated Arduino with a debugger could come in handy even if you don’t care about the circuit simulations. If you really want to do circuit simulation, it is hard to go wrong with LTSpice. If you really want it to be in your browser, there’s always Falstad.

I took a photograph this afternoon of three of the boards that can be used with the PteroDAQ data acquisition system:

On the left is the Arduino Leonardo, the slowest and most expensive of the boards here. In the middle is the KL25Z, which I’ve been using in my class for a couple of years—it is the cheapest and most featureful of the boards. On the right is the Teensy 3.1 (without headers yet), which is the fastest and smallest of the supported boards.

I’m considering switching to the Teensy 3.1 for the class, despite its higher price than the KL25Z board, because adding male headers to the bottom of the board makes it possible to plug the Teensy 3.1 into a bread board, which makes for more secure wiring than running separate wires to the KL25Z board.  We don’t really need the 64 pins of the KL25Z board, we’re not mounting Arduino shields, and we’re not using the accelerometer or the touch sensor, so the main question is whether it is better to have the data-acquisition board be standalone or be inserted into a bread board. The RGB light on the KL25Z board is a nice feature for providing feedback that is missing from the other boards (which only have a single-color LED).

I’ve also thought about usefulness to the students after the course, though few of the students will go on to do anything other than PteroDAQ with the boards.  The Arduino IDE is much easier to deal with for beginners than any of the development environments for the KL25Z, and Teensyduino is pretty easy to install on top of the Arduino environment.  So if students are going to go on to do hobbyist-level programming on the boards, then an Arduino board or the Teensy 3.1 might be a better choice. Given how much more powerful the Teensy 3.1 is than the old ATMega-based Arduinos, I see no reason to recommend buying Arduino boards (though clones from China have gotten down to about $3).

Erich Styger, in a comment, mentioned that he is frustrated by the Teensy’s lack of a SWD (serial wire debug) connector, which he is used to using for debugging. Since I’m from an older generation of programmers, I don’t miss it—I’ve not used the SWD connector on the KL25Z boards (though my son has, to use the OpenSDA chip as a programmer).  For me, it is a luxury to have a serial port for getting print messages from the board—I started microprocessor programming in the days when having one or two LEDs was about all the information you got back from the board. Having debuggers like GDB was a luxury available on computers that cost thousands of dollars.

Of course, the ARM processors on the Teensy 3.1 and the FRDM KL25Z boards are very much more complicated than the old 8080A, Z80, and 6800 8-bit processors I started with, and people are writing much larger programs for them, so I can see the advantage of having a debugger. But there is a large startup cost to learning to use a debugger and setting up the complicated software development tools they expect you to use, so I’m happy recommending the very limited, but easy-to-use Arduino interface for bioengineering students who want to go a bit further.

I’m curious what my readers think about the choice between a FRDM KL25Z board and a Teensy 3.1 board for the Applied Electronics class, given that most of the students will only use the boards for that class.  What tradeoffs might I have missed?  If you were in the class, which board would you rather work with?

It’s a pleasure to announce the latest development board, Arduino Zero, expanding the Arduino family by providing increased creative opportunities to the maker community.

Arduino and Atmel unveil the Arduino Zero, a simple and powerful 32-bit extension of the platform established by Arduino UNO. It aims to provide creative individuals with the potential to realize truly innovative ideas especially for smart IoT devices, wearable technology, high-tech automation, crazy robotics, and projects not yet imagined.

The board is powered by Atmel’s SAMD21 MCU, which features a 32-bit ARM Cortex® M0+ core and one of its most important feature is Atmel’s Embedded Debugger (EDBG), which provides a full debug interface without the need for additional hardware, significantly increasing the ease-of-use for software debugging. EDBG also supports a virtual COM port that can be used for device programming and traditional Arduino boot loader functionality.

Massimo Banzi, Arduino co-founder and CEO said:

“The flexible feature set enables endless project opportunities for devices and acts as a great educational tool for learning about 32-bit application development.”

Reza Kazerounian, senior vice president and general manager, microcontroller business unit at Atmel added:

“Leveraging more than 15 years of experience since the inception of AVR, simplicity and ease-of-use have been at the core of Atmel’s technology, Atmel is pleased to see the continued growth of the global maker community stemming from the increasing access and availability to open source platforms such as Arduino. We enable makers, but the power lies within the makers themselves.”

The first prototypes of Arduino Zero will be on display at Maker Faire Bay Area 2014 in San Mateo on May 17 and 18 at the following booths:
Arduino Booth: #204
Atmel Booth: #205
ARM Booth: #405

See you there!