First Look – the Arduino Leonardo


Recently the Arduino Leonardo was released, and I’ve finally got my hands on one. Some have claimed that the Leonardo as the successor to the Arduino Uno board, however that is somewhat subjective.  In this article we have a look for ourselves and examine the differences between the Uno boards that we’re used to and the new Leonardo.

The board

Here it is unwrapped from the cardboard packet:

It uses the same physical footprint as the Uno, so no surprises there:

 Now to travel around the board and see what’s new. First is the microcontroller – we have the Atmel ATmega32U4:

There are several pros and cons to using the 32U4. The pros include:

  • More analogue inputs. As well as the usual A0~A5, digital pins 4,6,8,9,10 and 12 can be configured as A6~A11
  • It handles USB. So no more external USB controller MCU or the old FTDI chip. Supposedly this saves money, however the retail price in some markets don’t reflect this
  • More PWM pins – well one more. They’re now on D3, 5, 6, 9, 10, 11 and 13
  • There is a little more SRAM than the Uno, it is now 2.5 kB
  • SPI has moved – they’re now wired to the ICSP pins. So you now have D10~D13 seperate to SPI
And the cons:
  • SPI has moved – they’re now wired to the ICSP pins. So if you have any shields that use SPI – too bad, they’re out. The most common example of this will be Ethernet shields – you’ll need to modify them with some jumper leads to contact the ICSP pins
  • I2C has moved over to D2+3. So if you have any shields using I2C – they’ll need to be modified
  • Less flash memory – the bootloader uses 4 kB of the 32 kB flash (the Uno used 0.5 kB)

However you can get an adaptor shield to use older Arduino shields with the Leonardo.

For MCU to Arduino pin mapping, see here. Next, for more on the USB side of things – as the 32U4 takes care of USB – take heed of the following notes from

Since the Leonardo does not have a dedicated chip to handle serial communication, it means that the serial port is virtual— it’s a software routine, both on your operating system, and on the Leonardo itself. Just as your computer creates an instance of the serial port driver when you plug in any Arduino, the Leonardo creates a serial instance whenever it runs its bootloader. The Leonardo is an instance of USB’s Connected Device Class (CDC) driver.

This means that every time you reset the board, the Leonardo’s USB serial connection will be broken and re-established. The Leonardo will disappear from the list of serial ports, and the list will re-enumerate. Any program that has an open serial connection to the Leonardo will lose its connection. This is in contrast to the Arduino Uno, with which you can reset the main processor (the ATmega328P) without closing the USB connection (which is maintained by the secondaryATmega8U2 or ATmega16U2 processor).

There are some other changes to the board. Moving on, the next change is the USB socket. Do you recognise this socket?

Yes – micro USB. Thankfully (!) a growing number of mobile phones use this type for charging and USB connection, so you may already have a matching cable. Note that the Leonardo doesn’t include a cable, so if you’re an iPhone user – order yourself a cable with your Leonardo.

Next, the LEDs have been moved to the edge of the board. You can see them in the above image to the right of the USB socket. No more squinting through shields at strange angles to check the TX/RX lights. However this isn’t a new invention, our friends at Freetronics have been doing this for some time. Furthermore, the reset button has been moved to the corner for easier access.

There are also seperate connectors for the I2C bus – next to AREF, which should make modifying existing shields a little easier:

 Finally, due to the reduction in components and shift to SMD – there is what could almost be called a large waste of space on the board:

A few extra user LEDs wouldn’t have been a bad idea, or perhaps circuitry to support Li-Po rechargeable batteries. However the argument will be “that’s what a protoshield is for”. Just saying… As for the rest of the hardware, the specifications can be found here.

Finally, the Leonardo is available in two versions – with and without headers. This makes it easier to embed the Leonardo into fixed applications as you can directly solder to the various I/O pins. An alternative to this would instead be the Freetronics LeoStick, as it is much smaller yet fully compatible.


First – you need to drag yourself into Arduino IDE v1.0.1. Note you can run more than one version of the IDE on the same machine if you don’t mind sharing the same preferences file. Next, the Leonardo doesn’t reset when you open the serial monitor window (from –

That means you won’t see serial data that’s already been sent to the computer by the board, including, for example, most data sent in the setup() function. This change means that if you’re using any Serial print(), println() or write() statments in your setup, they won’t show up when you open the serial monitor. To work around this, you can check to see if the serial port is open like so:

Using the 32U4, you also have two serial ports. The first is the emulated one via the USB, and the second is the hardware UART on digital pins 0 and 1. Furthermore, the Leonardo can emulate a USB keyboard and mouse – however with a few caveats. There is a section on the Leonardo homepage that you should really read and take note of. But this emulation does sound interesting, and we look forward to developing some interesting tools to take use of them, so stay tuned.


There is nothing wrong with the Leonardo board, it works as described. However you could consider this a virtual “line in the sand”, or a new beginning. Due to the changes in the pinouts shields will need to be redesigned, and for those of you still programming in Arduino v23 – it’s time to get up to speed with v1.0.1. If you need the special USB functions, keyboard and/or mouse emulation, or are happy with the changes and can get one for less than the cost of a Uno – great.

Here’s a video from the main man Massimo Banzi:

However if you’re looking for your first Arduino board – this isn’t the board for you right now. There are too many incompatible shields out there, and the inability to cheaply replace the microcontroller will see some beginners burn out their first couple of boards rendering them useless. Get yourself an Arduino Uno or compatible board such as the Freetronics Eleven.

In conclusion, classifying the Leonardo board as good or bad is not a simple decision. It may or may not be an improvement – depending on your needs. Right now – for beginners, this is not the board for you. For those who understand the differences between a Uno and Leonardo, sure – no problem. Frankly, I would get a LeoStick instead.  At the end – it’s up to you to make an informed decision.

In the meanwhile have fun and keep checking into Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.
The following two tabs change content below.

John Boxall

Person. Founder and original author for VK3FJBX

23 thoughts on “First Look – the Arduino Leonardo

    1. Fractal

      That’s odd.
      I did think that my leostick, running the v1.0.1 bootloader, had broken auto reset – turns out I hadn’t selected the serial port for the ‘sketch’ USB device.
      Perhaps this is something similar, I don’t think the hardware is different enough to change the reset behaviour – you could try an unmodified bootloader, and selecting the serial port while the sketch is running.

      When it can’t find a leonardo to auto-reset, the IDE will upload to any usb serial device that appears in the 10s it says ‘uploading’. This led me to believe my auto reset wasn’t working, but in fact, I hadn’t selected the correct serial port.
      If not, then thanks for the patch!

  1. Davidb

    The issues with serial and the uno bug me enough now. The issues with the leonardo that you’ve described would have me throwing it through the window.

    Also you cannot run multiple IDE’s without conflict. They share the same preferences file which is an absolute pain if you’re trying to keep your v23 and v1 sketches separate.

    I think implementations like the leoStick are the real future of this because you can put up with the intricacies of the product for the convenience of the size. The leonardo as a replacement for the uno is unrealistic. There are a lot of people with atmega328 chips sitting in breadboards while they work on their next project. Not practical with a full arduino board.

    BTW seeing as you have one to play with… What’s the power consumption like?

    1. John Boxall

      Thanks for your feedback. I hadn’t considered the preferences file as I never tinker with that.
      I think we can all agree that the LeoStick is a great implementation, and can be considered ‘breadboard friendly’ with the pins in it 🙂
      Sorry but I gave the Leonardo away this morning so can’t measure it.

  2. Fractal

    Excellent post, especially highlighting the various serial comms changes!
    There are a few bugs in the leonardo implementation, mainly due to timer2 being used for USB.
    Turns out, if you use the tone() library, this crashes the IC (no auto reset, it’s properly borked (until manual reset))
    To do more fancy things with the keyboard emulation, a little bit of modification is required to do more useful functions (make the sendReport function public), though this could be seen as a ‘safety’ measure!
    Interrupts don’t work out the box – but a few lines in pins_arduino.h, and the macros from a teensy will fix that.

    Playing with the leostick, the very rapid USB prototyping is great! There’s an example sketch that does the appropriate keypresses to use the IDE to reprogram itself- that’s crazy!
    In addition, if not scared off by makefiles, it’s easy to modify the USB drivers, e.g. request 100ma instead of 500ma, if you run the arduino off an unpowered hub, with an OS that complains about power.

    Interesting that they have changed (in v1.0.1) not only the bootloader from what it was before the official release (‘diskloader’ to ‘caterina’), but now the IDE will wait for ~10s if it can’t connect (to a leonardo), and upload to any serial port that appears within those seconds. Why? Because now it’s very possible to break the USB connection by messing up in software, and windows can enumerates USB devices too slowly to beat the bootloader timeout.

    However, the most exiting thing is that whatever people do with this can be ported easily to the 8/16u2 controllers on all UNOs. Since the arduinoISP sketch is fixed in v1.0.1, with a Leonardo and an UNO, a great amount of USB possibilities arise. Already, people have made a prank UNO, that does keyboard malarkey when plugged in.

    The Leostick forums are a useful place for various modifications to the software, and I look forward to seeing what people do with the 32u4!

    1. John Boxall

      Thanks for your detailed reply. Yeah, the issues about the Leonardo came in this morning after posting. The retailers really need to tell people ‘this is not for beginners’ etc. I love the little LeoStick, Jon and Marc should be very proud 🙂

    2. Lauszus

      The USB functionality doesn’t use timer2 – the problem with the tone() library is that the Leonardo doesn’t have a timer2, so that’s why it crashes. But it has now been fixed:

      The external interrupt worked fine for me – I even added support for INT2 and INT3 as well. See:

      I must say that I’m actually very pleased with the Leonardo, but yes I wouldn’t recommend it to a beginner!

      1. Fractal

        Ah, that makes sense!
        Nice job contributing, you are an asset to the community 🙂
        Good to hear the interrupts are fixed now.
        Let’s hope v1.02 doesn’t introduce more bugs than it fixes!

      2. John Boxall

        Yeah, hopefully they can sit on the current framework for a few years.
        However I have a suspicious feeling that as newer technology appears (e.g. Cortex M0/M3) etc at a cheaper price, the Arduino world will become more fragmented and die “a death of a thousand cuts”. Frankly they should have stayed with the Uno R3 and held out until the Due was released. Such is life.

  3. David Zanetti

    I think this is probably a sign of things to come, the Arduino Due may very well have to adopt different pinout on the shield header as well. It is also going to become more complicated by a wave of 3.3V (or lower) requirements. Between shields needing to use IOREF and odd pin mappings, it will be much harder to make widely acceptable shields.

    1. Fractal

      Well, the writing has been on the wall since the UNO (R2): New pins for I2C, and an IOREF pin.
      Really, I guess the plans for the Due, and Leonardo need these changes.
      Due so far looks identical to the mega pinout, but with the new UNO/Leo pins.
      In some ways, I’d have personally preferred them moving the headers, to not have that awkward 0.16″ gap, though the loss in backwards compatibility from that would be huger than the option they have gone for.

      If the Due continues to use the ATSAM3X8E, it’s going to be 3.3v. Any new shield ought use the new IOREF pins. I2C can easily be duplicated on the A5, and A4 pins, probably with a solder bridge to attach/detach the analog pins for users of the latest boards. SPI is more complicated, but using the 6 pin header should work with most duemilanove clones.

      Unfortunately, the various changes add to the cost of shields – more varied headers (6, 8, 8, 10, and ICSP), voltage switching considerations, backwards compatibility traces, and solder bridges. I guess that the net price changes will be small in comparison to the cost of getting a shield fabbed, soldered, and shipped though.

      Interesting times for Arduino, it should be interesting to see how they cope with the ‘threat’ of what appears to be a new wave of small, cheap, ARM powered, linux computers.

      1. John Boxall

        Thanks for your commment. And yes, the new ARM stuff is looking good. I saw this the other day, have it on pre-order:

        The fragmentation of the Arduino system is not a good thing – there are still new waves of beginners who are just getting started. All these different boards will possibly raise a mental barrier against choosing a board and getting started.

  4. Dark Alchemist

    WOW, I am having flashbacks to my Commodore 64 days (1983-1988) where it’s serial port was all software. Did we just go forward in reverse? Don’t like it.

    1. David Zanetti

      It’s not quite the same, since the USB functions are provided by actual hardware on the MCU. What kind of USB device you want is implemented in software, sure. The serial drivers in the libraries actually do a lot of heavy lifting even with a hardware USART anyway.

      It also fixes an annoying problem with the 328P based Arduinos – only one serial port. Now you can get two, one on the shield headers and one available over USB, and they don’t conflict. That’s a really positive change.

      1. Dark Alchemist

        Well, I am not alone in not liking it and they should give us back our memory footprint and get it back to a dedicated chip. I don’t need to be told by them how much better it is to have it on board when really it isn’t for many reasons.

  5. Jernej Plesnar

    i have a problem to receive any message from arduino serial communication throught usb. can anyone please share a tested serial example for arduino leonardo, because i am losing my mind for searching hours on internet.

  6. programmer

    i have the same problem , i try to connect leonardo with bluetooth module but the serial com port for the bluetooth fire fly module “not appear with the other serial ports in tools of arduino IDE “, please what i have to do????:(


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.