The Arduino project has been a great success. Lots of people are building hardware who wouldn’t have done were it not to exist. It’s also given us numerous cheap development boards.1

However, I don’t like the software. The IDE feels clunky, and increasingly I don’t like using the Arduino runtime because it hides so much from the programmer.

Here are some brief notes on my attempts to move away from the Arduino software to a standard avr-gcc and avr-glibc environment. Happily it’s quite a painless process.

Toolchain, library, and programmer

Besides the IDE, the Arduino application also provides all the GNU AVR tools,2 so we’ll need to install those ourselves.

GNU provide:

I found avrdude a bit complicated at first, and wrote some notes6 about using it.

All the tools are easy to install!

MacOS installation

Avrdude is in homebrew,7 and Lars Immisch has packaged the rest.8

$ brew tap larsimmisch/avr
$ brew install avr-libc avrdude

Debian/Ubuntu installation

Everything is already packaged:

$ sudo apt-get install avr-libc avrdude

Windows installation

No idea!


Better control of tools

Ages ago I wrote a Makefile to compile Arduino sketches from the command line.9 Other people have developed it further10 and it now goes to heroic lengths to compile sketches without bothering the user with pesky details.

However, I find these Makefiles are complicated and difficult to adjust: they’re designed to hide the details of the compilation process just as the Arduino IDE does, but that makes it harder to take control of things yourself.

For example, I think a more traditional development environment11 makes it easier to experiment with GCC optimizations.12

Replacing the Arduino runtime with avr-libc also makes it more explicit which hardware resources are being used, and thus makes it easier to reason about potential races between e.g. user code and interrupt handlers.

Finally, having a smaller runtime and simpler Makefiles appears to make compilation cycles significantly shorter, though I’ve not timed this.

Fewer impedence mismatches

It’s hard to be objective about this, but I find myself much more receptive to interesting but slightly subtle issues when I’m dealing with the hardware directly rather than through the Arduino code.

For example:

Freedom from C++

The Arduino runtime is written in C++, so if you use it you’re committed to including the C++ runtime in your code too. Parts of this seem quite large.

Of course, there’s nothing stopping you writting your own application in C++, but I think that choice should be up to you.


Arduino Leonardo

Although I’ve been dismissive of the Arduino runtime above, it’s not without its merits. It’s particularly important on e.g. the Leonardo, where the runtime handles comms with the PC.

Older Arduino boards use the microcontroller’s UART to talk to a FTDI USB-serial chip. However some newer boards including the Leonardo16 sport a USB-aware microcontroller which provides a virtual serial port.

This means that if you want the program on the microcontroller to talk to the PC, you’ll need to implement a USB handler in your code. You’ll also need this if you want to support the Leonardo’s reset scheme.

You can read about the microcontroller, a ATmega32U417 on Atmel’s site. You might also find the USB CDC specification18 helpful.

Alternatively, you can wrench suitable code from the Arduino runtime (see .../hardware/arduino/cores/arduino/ in the Arduino tree), but I found it hard to disentangle the necessary code from the rest of the Arduino framework.

A better approach might be to look at the LUFA project,19 or perhaps Atmel’s own USB stack.20 I’ve not tried these though.

You’ll need to pay due attention to the licenses when doing this.


Besides the boards, one of the main strength’s of the platform is that libraries exist for all sorts of devices. Most of these target the Arduino API, and so won’t work without it.

A reasonable strategy seems to be:

Again, you’ll need to pay due attention to the licenses when doing this.

Is it worth it ?

The short answer is that I don’t know. Moving away from the Arduino software whilst continuing to use their development boards certainly feels like taking the path less travelled, and it’s not yet clear if that will make ‛all the difference’.

Most of the process has been easy and felt like the right thing to do, but getting the USB connection working to the PC proved complicated, and I’m still not sure that it works properly.

Having got this far I suspect that most of my future projects won’t use the Arduino software, but ultimately even if I do go back, I’m glad I’ve do the experiment.