Arduino Comparison in Detail: UNO R3, Leonardo, UNO R4 Minima and UNO R4 WiFi

This article compares four similar Arduino boards from the "classic family" shown above and listed below.

1. Arduino UNO R3 (top left) - uses a ATmega328P microcontroller in a DIL socket with an ATmega16u2 microcontroller for the USB interface.
2. Arduino Leonardo (bottom left) - ATmega32u4 microcontroller.
3. Arduino R4 Minima (bottom right) - Renesas RA4M1 microcontroller.
4. Arduino R4 WiFi (top right) - Renesas RA4M1 microcontroller with ESP32-S3 for WiFi/Bluetooth 5.

These all use 5V logic levels and have the same female headers. They can be powered from a 2.1mm centre-positive barrel connector/jack, a VIN header pin or USB power. If someone refers to a board as an "Arduino" it is likely to be the UNO R3 but this is always worth confirming.

The UNO R3 and Leonardo use 8bit AVR microcontrollers and are very similar but have some interesting, subtle differences which may be important for certain projects. There are more differences between the R3 and R4 and some surprising ones between the R4 Minima and R4 WiFi.

The boards used for this article are all genuine Arduino boards, i.e. not clones and not counterfeit boards.

The measured values from tests are hopefully representative but these values will vary between samples. All tests were conducted at 22 degrees Celsius unless otherwise noted - the temperature will affect some characteristics.

1. Some Arduino boards, the ones here are from the "classic" range.
2. A multimeter, 10k resistor, breadboard and wires for measuring the internal pull-up resistors on GPIO.
3. A multimeter, potentiometer, pair of 6.3k resistors, breadboard and wires for measuring digital input voltage thresholds on GPIO.
4. A host computer with good time-keeping for some basic Arduino clock testing.

Here's a summary of the features of the four boards.

1. Arduino UNO R3
2. ATmega328P AVR 8bit 16MHz CPU, 32k Flash (-0.5k for bootloader), 2k RAM, 1k EEPROM.
3. USB type-B.
4. IO: 18 digital pins: 6 of those have analogue input capability, 6 have 8bit PWM, 2*2 for hardware i2c, 4 for hardware SPI. There are 2 extra ones, D0 and D1, used for UART comms for USB serial.
5. Arduino Leonardo
6. ATmega32u4 AVR 8bit 16MHz CPU, 32k Flash (-4k for bootloader), 2.5k RAM, 8k EEPROM.
7. USB micro-B.
8. IO: 20 digital pins: 6 of those have analogue input capability and another 6 have analogue input capability (only labelled on the underside of board), 7 have 8bit PWM, 2 for hardware i2c. There are separate pins on the ICSP connector which support hardware SPI.
9. Arduino R4 Minima
10. Renesas RA4M1 (Cortex M4 with FPU) 32bit 48MHz CPU, 256k Flash, 32k RAM, 8k EEPROM.
11. USB-C.
12. IO: 20 digital pins: 12bit DAC on A0, 6 of those have analogue input capability, 6 have PWM, 2*2 for hardware i2c, 4 for hardware SPI, 2 for CAN, 3 for internal op-amp.
13. SWD header for a JTAG hardware probe for debugging.
14. Arduino R4 WiFi
15. CPU RA4M1 (Cortex M4 with FPU) 32bit 48MHz CPU, 256k Flash, 32k RAM, 8k EEPROM.
16. USB-C.
17. IO: 20 digital pins: 12bit DAC on A0, 6 of those have analogue input capability, 6 have PWM, 2*2 for hardware i2c, 4 for hardware SPI, 2 for CAN, 3 for internal op-amp. Dedicated i2c on Qwiic connector, 12x8 red matrix LED display.
18. WiFi and Bluetooth 5 courtesy of ESP32-S3.
19. Software debugging over USB using CMSIS-DAP. Arduino IDE has support for this.

All of the boards have the classic UNO female headers. As noted above, not all the pins have the exact same features per board.

The micro-B and USB-C connectors are designed for frequent insertion unlike the USB type-B connector. A USB-C power source is more likely to support higher currents.

The CAN bus, digital-to-analogue converter (DAC) for "true analogue" output and real-time clock (RTC) are unique to the R4 boards. The R4 WiFi has a Qwiic connector with 3.3V power which is useful for connecting peripherals and an extra male header with VRTC and OFF pins.

For the Leonardo, the Arduino Store page mentions the absence of hardware SPI support on headers pins:

This means that if you have a shield that uses SPI, but does NOT have a 6-pin ICSP connector that connects to the Leonardo's 6-pin ICSP header, the shield will not work.

The UNO R3 is unique in having a socketed DIP microcontroller. This can make it useful as a board for programming other ATmega328P chips.

Here's a summary of power limits for the four boards.

1. Arduino UNO R3
2. USB type-B, barrel jack 7-12V, VIN 6-20V.
3. 5V pin output: not specified, below 500mA if powered by USB due to polyfuse.
4. 3.3V output: 50mA
5. Arduino Leonardo
6. USB micro-B, barrel jack 7-12V, VIN 6-20V.
7. 5V pin output: not specified, below 500mA if powered by USB due to polyfuse.
8. 3.3V pin output: 50mA.
9. Arduino R4 Minima
10. USB-C (1.5A), barrel jack 6-24V, VIN 6-24V
11. 5V pin output: 1.2A minus onboard usage (cheat sheet), buck converter has 1.2A limit, USB has 1.5A, however these are high currents for the narrow PCB traces on the board.
12. 3.3V pin output: 100mA (Renesas RA4M1 "USB LDO" limit)
13. Arduino R4 WiFi
14. USB-C (1.5A), barrel jack 6-24V, VIN 6-24V
15. 5V pin output: 1.2A minus onboard usage (cheat sheet), buck converter has 1.2A limit, USB has 1.5A, however these are high currents for the narrow PCB traces on the board.
16. 3.3V pin output: less than 800mA minus onboard usage (SGM2205 regulator limit)
17. Qwiic connector 3.3V pin: less than 500mA (polyfuse limit)

The UNO R4 boards have a very significant difference for the 3.3V power. On the R4 Minima it's provided by a low-power regulator built into the microcontroller and is similar to the UNO R3 and Leonardo. On the R4 WiFi an external regulator is used with a much higher rating. It's clearly important to ensure you are using the appropriate R4 board when drawing higher currents from the 3V3 pin.

There is more detail for the UNO R3 in Instructables: Powering Peripherals From a Microcontroller - Arduino UNO R3, Pi Pico W, Adafruit Feather NRF52840, BBC Micro:bit and Cytron Maker Nano RP2040.

Reverse Polarity Protection

The polarity protection differs on these boards. The UNO R3 has a diode (D1) between the barrel jack and VIN whereas the Leonardo has the barrel jack and VIN both connected to a reversed diode (D1) to ground. For the Leonardo, this means an incorrect centre-negative power supply would put a huge amount of current through the diode possibly damaging the diode and defeating its protection depending on the failure mode. Both use the Onsemi NCP1117 LDO voltage regulator which may be reasonably robust for accidental negative input voltages with its two internal protection diodes.

The R4 boards are different again with the barrel connector and VIN connected to a buck converter via a single schottky diode (D2 on Minima, D1 on WiFi).

Linear Regulators vs Buck Converters

The UNO R3 and Leonardo have linear voltage regulators which will generate more heat for higher voltages when powered from the barrel jack or VIN pin. It's best to use low voltages particularly for high current projects.

The R4 boards have a buck converter (a Renesas ISL854102) which can convert higher voltages to 5V without generating excessive heat. The buck converter will create ripple on the power supply making it noisier than a linear regulator.

Resettable Fuse (Polyfuse)

Some of the boards feature a polymeric PTC resettable fuse, an electronic auto-resetting fuse, also known as a polyfuse.

1. Arduino UNO R3: 500mA on USB.
2. Arduino Leonardo: 500mA on USB.
3. Arduino R4 Minima: none.
4. Arduino R4 WiFi: 500mA on Qwiic connector.

Lower Voltage on USB Power

For normal 5.0V USB power, one of most obvious practical differences is the R4 boards are powered at around 4.7V due to the voltage drop from a schottky diode. This is attractive for offering more protection to the USB host but it's a significant departure from the original design of the UNO R3 board and the Leonardo. It will affect many things, for example:

1. the high logic output voltage level,
2. the default range of the analogue-to-digital converter and
3. the voltage on the 5V pin - this has implications for any peripherals powered by this.

The UNO R3 and Leonardo use AVR microcontrollers with a clock speed of 16MHz. These are very capable, feature-rich microcontrollers and adequate for many tasks but an 8bit processor, slow clock speed and lack of floating-point support in hardware can make them unsuitable for applications which need to do copious or complex processing of data. The Renesas RA4M1 on the UNO R4 boards is a 32bit ARM processor, clocked at three times the frequency and has a hardware floating-point unit (FPU).

A benchmark seeks to measure the resources needed for some code, typically focussing on the execution time. Four benchmarks are discussed below, two** were executed to provide results for the four boards. It's important to avoid compiler optimisations that remove redundant code if the aim is to measure how long that code takes to execute. The measurement of time is also important as this isn't always highly accurate on a microcontroller without an external (quartz) crystal oscillator.

** The next page features an extra benchmark for the random() function.

CoreMark Benchmark

The CoreMark Benchmark is the most obvious one to use as it was designed for embedded systems. Unfortunately the vast majority of it is too complex to run on a humble AVR microcontroller. Paul Stoffregen has some results for a few of the tests on some Arduino boards but even this abbreviated benchmark will not run on the UNO R3 and Leonardo due to memory constraints.

Basic Maths Benchmark

The Arduino Forum: Benchmark STM32 vs ATMega328 (nano) vs SAM3X8E (due) vs MK20DX256 (teensy 3.2) discussion included a very basic benchmark for gauging maths performance. A revised version of this with fp64lib additions was executed to compare the floating-point performance. The results are shown on three plots above.

The AVR microcontrollers are using software libraries to implement the floating point mathematics achieving around 0.2MFLOPS for 32bit and 0.05MFLOPS for 64bit using the types float*** and float64_t, respectively. The effect of the FPU on the ARM microcontrollers is clear with 32MFLOPS for 32bit multiplication and 4.0MFLOPS for 32bit division using the float type. The ARM 64bit performance using the double type is notably different at 1.1MFLOPS and 0.7MFLOPS and should be used judiciously.

*** The Arduino AVR gcc compiler's size for double is atypically the same size as float, both are 32bit.

Dhrystone Benchmark v2.1

Gareth Halfacree ported the Dhrystone benchmark which tests integer mathematics for AVR microcontrollers. The results can be seen plotted above and listed below.

1. Arduino UNO R3: 17218 Dhrystones per second.
2. Arduino Leonardo: 17307 Dhrystones per second.
3. Arduino R4 Minima: 62329 Dhrystones per second.
4. Arduino R4 WiFi: 62172 Dhrystones per second.

The ARM microcontrollers are faster as expected but the difference is not as large as might be expected.

SdFat Benchmark

The performance of the SdFat library (July 2023) on the UNO R4 boards is discussed in Arduino Forum: Uno R4 Poor SPI Performance. This is an unusual case where the UNO R3 is quicker than the UNO R4 boards due to differences in the performance of Serial Peripheral Interface (SPI) protocol data transfers.

The Arduino Forum: Random function on R4 terribly slow discussion raises the issue of the performance of hardware random number generators (HRNG) as these appear to be used on the UNO R4 boards for the random() library call. The Renesas RA4M1 has one inside its Secure Cryptographic Engine (SCE5) module. In general, hardware features are normally faster than software ones. In the case of true random number generators (TRNG) they aim to ensure there is enough entropy in the random numbers which can cause them to be slow or may cause slowness based on the rate of consumption of continuously generated and buffered data, i.e. how frequently random functions are used.

The first benchmark of random() produces reasonable results, the slower UNO R3 and Leonardo are approximately 52-56us and the faster UNO R4 boards are 3-5us. The plots show the arithmetic mean with a diamond. The delay parameter is the delay in milliseconds between each call to random() to explore any performance difference based on frequency of calling.

The second benchmark calling random(2025) produces very different results. The UNO R4 boards have a wide distribution taking up to 115000us. This doesn't make sense until the data is viewed based on the use of randomSeed(). The third plot (which has y axis that differ between subplots) shows this is terribly slow unless randomSeed() is called with a value. The (currently) undocumented functionality in the Arduno code is to use the Renesas RA4M1 HRNG unless randomSeed() has been called. This explains the results and provides one method to disable it, albeit one for the rest of the execution of the program. The other option is to use random() without arguments and convert the range in the application.

The output from the benchmark running random(2025) on an UNO R4 Minima is shown below.

One remaining mystery is the superior performance of the UNO R4 WiFi compared to the UNO R4 Minima despite having the same microcontroller.

USB Communication

The ubiquitous Arduino UNO R3 board is atypical amongst this collection as it uses a separate, dedicated ATmega16u2** microcontroller for USB communication to the host. This means a program running on the UNO R3 cannot (easily) use other USB protocols like the human interface device (HID) class used to emulate a keyboard or mouse or for MIDI over USB. The ATmega16u2 can be re-programmed but this is non trivial as can be witnessed from the discussion in Arduino Forum: Uno R3 as USB HID device/ Firmware update.

The Leonardo and UNO R4 Minima use the main microcontroller to perform USB communication. The UNO R4 WiFi uses the ESP32-S3 for USB by default but this can be changed by soldering across its SJ1 pads. These three boards are far easier to use with other USB protocols.

The Arduino Keyboard Serial program is a very simple example showing how the Leonardo or R4 boards can emulate a keyboard using the Keyboard object. There is also a Mouse object. The UNO R4 boards are capable of supporting MIDI over USB but it is not currently supported according to Control Surface's MIDI over USB table.

** Arduino UNO R3 clones and counterfeits are likely to use the CH340 chip.

Arduino Serial behaviour

The Serial object used to send data back to a USB host computer has different behaviour depending on whether the microcontroller communicates directly over USB or using a separate chip.

Some Arduino code has a tight while loop waiting until the Serial object returns true.

The UNO R3 will always return true, the other three boards will wait forever for the serial console over USB to be ready. This is problematic if the code is intended to run with and without a USB connection to a host computer. One solution to accommodate both scenarios is to add a timeout.

The finer points of this code's behaviour are discussed in Arduino StackExchange: What does the line "while (! Serial);" do in an Arduino program?.

The baud rate setting only has an effect on the UNO R3 where it's important for correct data transfer. If gibberish is appearing in the Arduino IDE's Serial Monitor then the most likely issue is a baud rate mismatch.

The TX and RX LEDs on the UNO R4 Minima unusually do not flicker with Serial transmissions nor when a program is downloaded to the microcontroller. This was discussed in Arduino Forum: Serial TX/RX LED.

A summary of the Arduino recommendation for GPIO current on the four boards.

1. Arduino UNO R3: 20mA.
2. Arduino Leonardo: 40mA.
3. Arduino R4 Minima: 8mA
4. Arduino R4 WiFi: 8mA

The AVR 8bit microcontrollers are unusual compared to many modern 3.3V microcontrollers with their fairly high current limits. The datasheets for the ATmega328P and ATmega32u4 used on the UNO R3 and Leonardo, respectively, give a an absolute maximum value of 40mA per GPIO. The Arduino recommendation is more conservative for the UNO R3 at 20mA. It's unclear why this caution isn't applied to the Leonardo. There is also an error in the some of the documentation for the Leonardo with a 10mA limit appearing.

The ATMega328P (page 258) and ATmega32u4 (page 383) datasheets add more detail for GPIO. It's tempting to extrapolate the Arduino 20mA per GPIO to all 14 digital and 6 analogue pins - this would total 20 * 20mA = 400mA. However, there is also a limit of 200mA total power for the processor and all GPIO pins. And certain groups of pins have an additional total limit of 150mA for sourcing current and 100mA for sinking current.

It's important to note the R4 boards have a far lower 8mA maximum current. It's easy to exceed this, the image above shows some testing with an LED drawing around 10mA. A project using high currents, e.g. 8 GPIO at 20mA each, could be migrated from an UNO R3 to an R4 board and appear to work but this could be become unreliable and damage the microcontroller from putting 160mA through the Renesas RA4M1.

There is a voltage drop with increased current sourcing and a voltage rise with current sinking. This can be considerable for more than a few milliamps and should be taken into account. There are some examples for GPIO current sourcing in Instructables: Measuring Peripheral Power With Arduino UNO R3 and R4 WiFi, Pi Pico W, Adafruit Feather NRF52840, BBC Micro:bit V1 and V2, Cytron Maker Nano RP2040.

The voltage can be gradually varied with a potentiometer to determine the voltage when the microcontroller decides the digital input has transitioned. The value may vary for the transition from low to high compared to the transition from high to low. The datasheet will state the minimum value for a high and maximum value for a low level with the values in between regarded as indeterminate.

A 10k potentiometer was used with a pair of 6.3k ohm resistors to offer a range of voltages between 1.39V and 3.61V using the 5V pin from the board. The boards were battery powered using the barrel jack to avoid the lower voltage on the UNO R4 boards on USB power. Four values were measured for each transition, shown above as a plot and below as mean values (percentage of 5V pin voltage in brackets).

1. Arduino UNO R3: 2.24V (45.0%), 2.50V (50.1%).
2. Arduino Leonardo: 1.55V (31.1%), 1.57V (31.5%).
3. Arduino R4 Minima: 3.22V (64.4%), 3.24V (64.7%).
4. Arduino R4 WiFi: 3.22V (64.5%), 3.23V (64.9%).

The first observation is the voltage is radically different for the three microcontrollers on the four boards. The second is the UNO R3 is the only board with useful hysteresis (a schmitt trigger) for the input. The voltage on the Leonardo is much lower and has a very narrow gap. On the R4 boards the output shown on the onboard LED (D13) appeared to vary in brightness rather than crisply transition from off to on and back to off. This implies the input value is unstable between the low and high thresholds with rapid oscillation and there is probably no hysteresis. The instability could be related to or exacerbated by power supply noise due to the buck converter on the R4 boards.

The values aren't an exact match but align with the plots (shown above) in the Electrical Characteristics sections of the Atmel/Microchip microcontroller datasheets. The datasheet "legal" maximum value for Vil and minimum value for Vih for GPIO are shown below in equation form using the supply voltage (Vcc).

1. Arduino UNO R3: 0.3*Vcc, 0.6*Vcc.
2. Arduino Leonardo: 0.2*Vcc-0.1, 0.2Vcc+0.9.
3. Arduino R4 Minima: 0.2*Vcc, 0.8*Vcc.
4. Arduino R4 WiFi: 0.2*Vcc, 0.8*Vcc.

The input voltage thresholds will be important for interfacing with devices with (notional) 3.3V outputs without level shifting. These may not work with an R4 board. Note: 5V outputs must not be used with a 3.3V microcontroller unless the inputs are known to be 5V safe.

A few niche applications will depend on this transition voltage and will need to be adapted in some way to accommodate these differences.

More accurate measured values could be achieved with a tailored voltage range per microcontroller and an extra potentiometer for fine adjustment.

Many microcontrollers offer built-in pull-up and pull-down resistors which can be enabled in software. The ones on these four boards only offer pull-up resistors. The ATmega328P equivalent schematic for a GPIO is shown above with Rpu representing the pull-up resistor.

The internal resistance can be calculated by measuring the voltage with and without an external pull down resistor. The values are shown below for the four boards using a 10k resistor (measured 9.878k) with the min-max values from datasheet in brackets. The boards were battery powered using the barrel jack to avoid the lower voltage on the UNO R4 boards on USB power.

1. Arduino UNO R3: 38.1k (20k-50k)
2. Arduino Leonardo: 36.7k (20k-50k)
3. Arduino R4 Minima: 18.7k (10k-50k, 20k typical)
4. Arduino R4 WiFi: 18.1k (10k-50k, 20k typical)

The resistance of the internal pull-up resistors is significantly lower on the R4 boards. A good design doesn't rely on exact pull-up resistor values...

These Arduino boards are notionally referred to as 5V boards but this does not mean the power applied to the microcontroller or present on the 5V pin is exactly 5.000V. This was recognised as an issue in the early days of the UNO R3 and a clever technique of measuring the supply voltage was devised using the internal 1.1V reference voltage against the supply voltage. This works on the Leonardo board too. The function is commonly called readVcc() and returns the supply voltage in millivolts.

The 5V rail on the UNO R4 boards goes through a 13.7k and 100k potential divider with precision resistors presenting the lowered voltage on a dedicated analogue input pin. This can be conveniently read using analogReference() (without arguments) but the voltage is only read once and then the same value is returned if the function is called again. An implementation of readVcc() using analogReference() suitable for the UNO R4 can be found in Arduino Forum: readVcc function using new UNO R4 RA4M1 ADC.

The readVcc() function was modified to read the voltage every time for some testing. The reported voltage from the function and voltage measured on the 5V pin with a multimeter are shown below, the latter in brackets.

1. Arduino UNO R3 (USB powered): 5028mV (5014mV).
2. Arduino Leonardo (USB powered): 5338mV (4998mV).
3. Arduino R4 Minima
4. USB powered: 4788mV (4706mV).
5. PP3 (9V) powered: 5048mV (5006mV).
6. Arduino R4 WiFi:
7. USB powered: 4700mV (4644mV).
8. PP3 (9V) powered: 5012mV (4988mV).

The values are all very close with the exception of the Leonardo. That warrants further investigation.

These values can also be corrected by calibrating the function based on measurement(s) from the specific board for additional accuracy. The EEPROM non-volatile memory presents a convenient place to store per-board calibration numbers.

The four boards have some subtle differences related to how the clock is generated for the microcontrollers.

1. Arduino UNO R3
2. ATmega328P 16MHz external ceramic resonator.
3. ATmega16u2 16MHz external crystal.
4. Arduino Leonardo
5. ATmega32u4 16MHz external crystal.
6. Arduino R4 Minima
7. Renesas RA4M1 High-speed on-chip oscillator (HOCO) running at 48MHz (schematic shows a crossed-out 16MHz crystal).
8. Arduino R4 WiFi
9. Renesas RA4M1 High-speed on-chip oscillator (HOCO) running at 48MHz.
10. ESP32-S3 internal clock.

The clock on a microcontroller only provides a series of pulses which are counted to determine the time since power-on or reset. This is not intended to be incredibly accurate. The Leonardo is likely to be the most accurate of these four boards with its external (quartz) crystal. The UNO R3 has a crystal for the microcontroller doing the USB communication where timing is important but uses a cheaper ceramic resonator for the main microcontroller. The UNO R4 boards use an internal oscillator inside the microcontroller. This must be accurate enough for USB communication but it's unlikely to be as accurate as an external crystal. An internal oscillator may be more prone to varying drift due to the microcontroller's internal temperature which will vary with activity and GPIO current usage.

The photograph above is one of the earliest quartz crystal clocks from 1927.

Real-Time Clock (RTC)

An external real-time clock (RTC) is one solution for good time-keeping over a period of weeks to years. A board based on a (genuine) Analog Devices DS3231 is a good choice. After setting once these can supply the date and accurate time to the Arduino. A small battery for the RTC can maintain the time for many years.

A GPS module is an alternative for very high quality time-keeping for applications which can use a GPS antenna with a good view of the sky. For important applications some caution is required due to risk of poor reception, jamming and spoofing.

An R4 WiFi board could potentially use the network time protocol (NTP) to query a remote service for time-keeping.

The Renesas RA4M1 has a built-in real-time-clock and the R4 WiFi has an extra male header to support this. The time-keeping is reportedly very poor and far worse than millis()/micros() rendering this of very limited use on the UNO R4 boards. This is discussed in Arduino Forum: RealTimeClock inaccurate and Arduino Forum: UNO R4 WiFi RTC runs fast by about 1 second per minute.

The accuracy of the clocks on the Arduino boards can be determined with a program that produces output periodically and compares the result against a good reference time. The simplest way to observe this is to print every hour using the Serial object and observe the output in the Arduino IDE's Serial Monitor. The Serial Monitor has timestamps from the host computer which can be used to compare the two.

Another simple way to do this is to produce more frequent serial output and collect this from all the boards under test on a host computer. This is an imperfect method due to the round-robin polling of the many serial connections and the collection program running on a general-purpose, multi-tasking operating system but it should be accurate enough for at least a few tens of milliseconds over a day. For the 86400 (24*60*60) seconds in day a 10ms difference can be expressed as 0.120 parts per million (ppm) - if this was consistent then this would be an excellent clock, drifting only 4 seconds over a year.

The results of a test with the micros() counter (millis() has documented accuracy issues) being printed every 10 seconds are shown above. The clock drift (based on fitting a straight line) over a day is listed below for the four boards. The temperature in the room near the boards ranged from 21.6 to 22.8 degrees Celsius during the test.

1. Arduino UNO R3: -91.7 seconds.
2. Arduino Leonardo: -2.1 seconds.
3. Arduino R4 Minima: -0.7 seconds.
4. Arduino R4 WiFi: -163.3 seconds.

The Leonardo's result is expected as it has an external crystal which should have good accuracy. A surprise here is the difference between the UNO R4 boards. The Minima and the WiFi have the same microcontroller and the same lack of external oscillator leaving them to run on the internal oscillator. This could possibly be explained by some sort of help with clock synchronization from the low level USB protocol. The Renesas RA4M1 microcontrollers appear to have a feature which can refine the clock synchronization from USB SOF (start-of-frame) packets from a USB host.

The mains-powered laptop used to collect the data has a variable-speed fan exhaust on one side - it was positioned to avoid this warming the Arduino boards. The operating system maintenance features were suspended and performance-related power saving features were disabled on the laptop to reduce their impact on this lengthy test. A plethora of maintenance tasks like software updates and anti-virus checks could still have a detrimental effect on the accuracy of the serial data collection. A compiled, multi-threaded collection program rather than a Python one running on an interpreter might also provide a slightl increase in the accuracy of the host's timestamping.

On USB power the R4 boards will be running at 4.7V rather than 5.0V may affect the internal oscillator used for the clock in some way.

Clock frequencies will always vary per board due to component tolerances. Measurements of one board cannot be used as correction factors for all boards of that model.

If a clock is known to run fast or slow at a constant rate then it can easily be corrected to achieve an accurate time. The photograph above shows the pennies used for fine tuning the mass of the pendulum for Denison's clock in the Elizabeth Tower often referred to as Big Ben.

The plot above shows the four Arduino boards with a simple linear correction applied per board.

The first anomaly observed here is three of the boards have an unusual and distinctive pattern - the clock speeds certainly do not look like straight lines! It looks like some event occurs approximately every 9 hours. This strongly suggests the (WiFi-connected, mains-powered) laptop running Windows 10 is a flawed time reference for this type of test! This could be due to periodic occasional fan runs on the laptop to cool it or general poor time-keeping on Windows 10.

The UNO R4 WiFi is all over the place with a range of about 1.6 seconds. This could be related to the use of the low quality internal oscillator.

This is a slightly shorter duration test with a window opened at night in winter which gradually cooled the room to a minimum of 9.8 degrees Celsius. The straight lines shown are based on the first constant temperature period. The UNO R3 and UNO R4 WiFi can be seen to significantly change with the temperature drop. The second zoomed-in version of the plot allows a better look at the Leonardo and UNO R4 Minima. The Leonardo experiences the least effect from the temperature drop, the UNO R4 Minima may appear unaffected but on a percentage basis it's actually the most affected.

This is a six hour test using a fan-less Raspberry Pi 4 running the serial collector program and acting as a time reference. The Pi 4 has a wired connection to the Internet and is running chrony for time synchronization against public servers. It was used for an hour before the test which should ensure it has warmed up and its running temperature is constant during the test.

1. Arduino UNO R3: -90.3 seconds per day.
2. Arduino Leonardo: -1.6 seconds per day.
3. Arduino R4 Minima: -11.6 seconds per day.
4. Arduino R4 WiFi: -148.8 seconds per day.

The state of chrony on the Pi 4 just after the test is shown below.

The drift on the Arduino boards is very similar to the previous results but the plots now look more like the expected values from the relevant oscillator types. The Arduino R4 Minima still differs radically to the Arduino R4 WiFi - its clock is likely to be getting some help via USB from the USB host. The Arduino R4 WiFi is clearly the worst but its +/- 150ms over the six hour period would still be suitable for many applications.

This is a 24 hour test with the window opened again overnight in the winter to provide a gradual shift to a lower temperature. Later on a small temperature-controlled fan heater warmed that area of the room. The hot period can be seen to start bringing the Leonardo's crystal-based clock and the UNO R3's ceramic resonator-based clock back to the original clock drift gradient.

One of the attractions of the Arduino UNO is the standard header layout replicated on many other boards. One type of peripheral is a "shield", a board which sits on top of the UNO with male headers on the underside connecting to the UNO's female headers.

The Arduino site lists the Arduino shields that are compatible for each board under the Compatibility tab. This is useful but it does not cover third-party shields. For the Leonardo, the Arduino Store page mentions the absence of hardware SPI support on headers pins - this means shields which transfer lots of data at high speed are unlikely to work. For any non-trivial shield it's worth checking the documentation or asking the manufacturer if it's compatible with a particular Arduino board.

The UNO R4 boards on USB power will only be supplying 4.7V (via 5V pin) to a shield. This could be confusing or problematic for boards with a tight voltage tolerance. For a 35 ohm heater coil on a gas sensor this 0.3V drop represents a 12% drop in power. This could produce results from testing on USB power which differ to real world values when the board is powered via the barrel connector.

The generated image above is Stable Diffusion's output with the prompt: "A Roman legionary on a hillside holding a shield made from Arduino boards and a short sword with large AVR letters on it and wearing a helmet with two Arduino shields embedded in it."

These were all compiled using the Arduino IDE 2.3.4 with

1. Arduino AVR Boards 1.8.6
2. Arduino UNO R4 Boards 1.3.1
3. fp64lib 1.1.20

Serial behaviour

serial-output-comparison

GPIO input voltage thresholds and pull-up resistance

gpio-input-tester

Basic Maths Benchmark

A revised version bench_test_101

Dhrystone Benchmark v2.1

Gareth Halfacree's port dhry21a

USB HID Keyboard Emulation

The Arduino Keyboard Serial program.

Power Supply Voltage Measurement

The readVcc() function/program.

Clock Speed Test

For the Arduino board serial-periodic-print and for the host computer collecting the serial output serial-collector.py.

Random Function Benchmark

benchmark-random

Some ideas to explore:

1. Perform some of the tests and benchmarks on some high quality clones and some rogue counterfeit boards from your Arduino stash.
2. Take a closer look at the noise on the Arduino's 5V power when powered from a typical desktop, laptop, USB power bank, 9V battery to 2.1mm barrel jack and a good quality linear power supply to VIN.
3. Carefully compare the 14bit ADC on the UNO R4 boards to the 10bit ADC on the UNO R3 and Leonardo to see if the extra bits provide a useful increase in accuracy (cf ENOB) or are just useless noise.
4. Compare the effect of high impedance source on ADC values as the Renesas RA4M1 appears to have a much lower input impedance than the AVR ADCs.
5. Check the GPIO voltage falls/rises for current sourcing and sinking. See Instructables: Measuring Peripheral Power With Arduino UNO R3 and R4 WiFi, Pi Pico W, Adafruit Feather NRF52840, BBC Micro:bit V1 and V2, Cytron Maker Nano RP2040 for some practical current sourcing examples.
6. Investigate the discrepancy in readVcc() output on the Arduino Leonardo to see if this is the one used for this article is just an "unlucky" board or if there's a genuine difference.
7. Investigate the difference in performance between UNO R4 Minima and UNO R4 WiFi hardware random number generators. This difference could be simply due to the hardware feature varying per chip and not a difference between those two boards.
8. DAC on UNO R4
9. Check the DAC output to ensure it produces expected values for some typical waveforms.
10. Use the DAC as a signal generator to test the ADC on another Arduino board.
11. Clock testing
12. Add a temperature sensor to the Arduino to measure the ambient temperature for clock tests.
13. Repeat clock testing with data sent over UART using GPIO and USB disconnected from a host computer. This should demonstrate if the UNO R4 Minima's clock performance is benefitting from the low-level USB protocol and USB host's clock.
14. Change the clock testing to be pulse based and use an additional microcontroller with a GPS module to do some precision clock testing similar to Joris van Rantwijk's Arduino clock frequency accuracy.

Other similar comparisons:

1. Joris van Rantwijk's Arduino clock frequency accuracy - a study of the accuracy of a crystal on the Arduino Duemilanove vs ceramic resonator on the Arduino Pro Mini 5V using GPS time from a module as a reference.
2. Underwater Arduino Data Loggers: Sync RTC time to a GPS & Calibrating the DS3231 Aging Offset Register to Reduce Clock Drift
3. Instructables: Timekeeping on ESP8266 & Arduino Uno WITHOUT an RTC (Real Time CLock)?

Further reading:

1. Arduino Store: Boards & Modules - Compare feature can be used to compare multiple boards.
2. Arduino Support: What's the difference between UNO R3 and UNO R4 boards?
3. Instructables: Step by Step Guide to the Arduino Leonardo - includes detail on header pin capabilities.
4. Arduino Forum: Oscillator on R4 Minima appears far better than R4 WiFi
5. DigiKey: TechForum: Arduino Uno R4 WiFi in Higher Education
6. Element 14: RoadTest Reviews: Arduino UNO R4 - revolution or evolution?
7. Inacio, Pedro & Guerra, Rui & Stallinga, P.. (2022). An Ultra-Low-Cost RCL-Meter (Sensors 2022) - in-depth look at making an LCR meter which depends on the digital input voltage thresholds with an Arduino UNO R3 and Arduino Leonardo.
8. GitHub: arduino/docs-content: Inconsistent values for GPIO current for Arduino Leonardo #2321
9. FSMLabs: Comparing NTP and PTP - a vendor showing the difference between Network Time Protocol (NTP) solutions like ntp and chrony vs their Precision Time Protocol (PTP) TimeKeeper system.
10. Altium: From RC to Atomic Clocks: All Clock Sources
11. CTS: Application Note: Crystal Basics
12. StackExchange: Electrical Engineering:
13. Crystals, Oscillators, and Resonators. What the difference?
14. Internal or external oscillator
15. Why does usb have start of frame packets?
16. Arduino Time library - a library to return the date/time based on a real-time clock (RTC), GPS, NTP or serial messages.
17. StackExchange: Retrocomputing: How much did IBM save by limiting the PC to 4.77 MHz?
18. Colorburst synchronisation signal on PAL/NTSC video signals.
19. USB HID
20. Arduino UNO R4 Minima USB HID
21. Arduino UNO R4 WiFi USB HID
22. Arduino Docs: Keyboard and Mouse Control
23. Arduino Forum: Uno R3 as USB HID device/ Firmware update.
24. Elektor Books: Mastering the Arduino UNO R4 by Dogan Ibrahim
25. The British Museum: Young explorers: a brief history of time telling (YouTube)
26. UW Space Place: A Brief History of Time(keeping): Optical Atomic Clocks and Their Applications (YouTube)
27. The Guardian: Clockmaker John Harrison vindicated 250 years after ‘absurd’ claims - the world's most accurate mechanical clock, John Harrison's design for Clock B implemented in modern materials by Martin Burgess tested over 100 days.
28. BBC Future: Why is Big Ben falling silent?