The Arduino Leonardo

The Arduino whose USB socket goes to the chip itself: an ATmega32U4 at 16 MHz, with Serial on the USB and Serial1 a port of its own on pins 0 and 1.

What it is

An ATmega32U4 in its 44-pin package, on the same AVR core as the Uno, with 32 KB of flash, 2560 bytes of SRAM and 1 KB of EEPROM. The registers are at their real addresses, so a sketch built here runs on the board on your desk. The reference page is The Arduino Leonardo model.

The board is 68.6 by 53.3 mm (an Uno's outline to a tenth of a millimeter), and the shield headers are an Uno's hole for hole. Like an Uno it does not go into a breadboard: wire it with jumpers from the headers.

Serial is the USB

This is the thing to understand about a Leonardo, and the thing that surprises people who arrive from an Uno.

On an Uno a second chip turns USB into a UART, and Serial is the microcontroller's USART0. On a Leonardo there is no second chip: the USB device is on the ATmega32U4 itself, and Serial is a CDC endpoint that the sketch's own firmware opens. Serial1 is the real USART, and it comes out on header pins 0 and 1.

So in the editor:

• What you print to Serial appears in the serial monitor.
• What you print to Serial1 comes out of pin 1 as bits. Wire it to something (pin 0, a scope, another board) or it reaches nothing at all.

The built-in Serial program prints to both, so the difference is on screen.

Mokxi models the USB as a byte pipe at the real endpoint registers: enough for a serial port, and nothing above it. There is no enumeration, no descriptors and no host, so while (!Serial) {} returns at once here and waits on a desk, and Keyboard and Mouse are not available.

Pins

Thirty of them, and a sketch counts them the way the silkscreen does:

• 0 to 13 along the digital header, with the L LED on 13.
• A0 to A5 along the bottom.
• A6 to A11 are second names for digital pins 4, 12, 6, 8, 9 and 10, because on this chip the ADC reaches ports B and D as well as port F.

Seven pins do hardware PWM with analogWrite: 3, 5, 6, 9, 10, 11 and 13.

SDA and SCL are pins 2 and 3, not A4 and A5 as on an Uno. The two holes beside AREF are the same metal as pins 3 and 2. That is the one place the shared shield footprint is not the shared chip, and it is the first thing to check when a sketch moves across.

A timer nothing else here has

Timer 4 on this chip is ten bits wide, its TOP is a register rather than a mode, and its compare channels are A, B and D. There is no channel C, because OCR4C is TOP. It drives pins 6 and 13.

analogWrite hides all of that, so the sketch looks ordinary. The built-in Fade program puts an LED on pin 13 and another on pin 9, which is an ordinary 16-bit timer, so both kinds of PWM hardware are running at once: 976 Hz on 13 and 490 Hz on 9.

Interrupts

Five pins have an external interrupt: 3, 2, 0, 1 and 7. Pin 7 is the interesting one. It is INT6, the only one this board brings out that is not one of the first four pins, and the built-in Button program uses it.

Pass a pin through digitalPinToInterrupt() and attachInterrupt() does the rest, as on the real board.

Stock Arduino libraries

A tutorial that includes Servo.h, Wire.h, SPI.h, EEPROM.h, LiquidCrystal_I2C.h, Adafruit_GFX.h with Adafruit_SSD1306.h and DHT.h compiles here as it stands. Each is Mokxi's own header under the upstream name, written on the drivers for the parts in the bin, and none of it is the upstream library's code.

• Wire.begin() puts the I2C bus on 2 (SDA) and 3 (SCL).
• EEPROM.h uses the chip's own 1 KB of EEPROM, through its real registers. It keeps what you wrote across a press of the board's reset, and a fresh Run starts it erased, every byte 255, because a Run is a new board.
• Adafruit_NeoPixel.h stops with a message: a WS2812 bit is too short to make by hand on this board, and only the ESP32-C3 and ESP32-C6 drive the strip.

The code editor and compiling lists what each one covers and how it differs from the upstream library.

The firmware

Four built-in programs: Blink, Button, Serial and Fade.

An Uno sketch's source will usually build for the Leonardo. An Uno's compiled ELF will not run on it: different chip, different register map, different vector table. Build it for the Leonardo and it runs.

What is not modeled

The USB stack above the byte pipe, and so Keyboard, Mouse and anything else that needs enumeration. Serial here is a byte pipe with no protocol under it: no enumeration, no descriptors, no endpoint configuration, no suspend or resume and no 1200-baud-touch reset, so the thing that makes a Leonardo a Leonardo (a sketch waiting on while (!Serial)) is a decision this model makes rather than a handshake it runs.

SPI, TWI/I2C, the analog comparator, the watchdog, the temperature sensor, and the PLL that would clock timer 4 faster than 16 MHz. Shields are not physical parts here; wire the same circuit on the breadboard. The Leonardo ETH is not modeled. The Micro and the Pro Micro are the same chip on other pinouts, and are in the parts bin as boards of their own.

The addresses are the data sheet's and none is guessed at; the approximations are behaviors, and section 8 of the Arduino Leonardo model sorts every one of them. The three that show at the bench: the ADC has no error in it (no sample-and-hold, no nonlinearity, no noise, no offset), so a divider reads the same count every time where a real one wobbles; the 16 MHz crystal is exact, with no drift or jitter; and the 5 V rail is an ideal source that cannot sag, so a circuit that would brown a real board out runs cleanly here.