RoadTest: Enroll to Review the Arduino Uno R4 Minima
Author: JWx
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Arduino UNO R3
What were the biggest problems encountered?: Incidental incompatibility issues
Detailed Review:
I was inspired to write this review by the story of my friend, who have bought Arduino UNO R4 WiFi shortly after it's debut (along with some modules) for one of his children, only to discover that some libraries - working perfectly on R3 - are not producing expected results on his new hardware. Long story short - he has also bought R3 to interface those stubborn modules whose software was not yet ported to R4, but this situation made me wonder exactly to what level R4 is compatible with previous revisions.
Current test set is conducted to try to answer the question how much Arduino UNO R4 can be treated a direct replacement of R3 and - if not - what kind of surprises await for someone trying to use it as such. Because of this I have decided to try to re-use as much as possible of my existing development setup, used to develop software for UNO R3 boards. This setup consists of aged MS Windows 7 computer with Arduino IDE (v. 1.8.10) installed.
To this date there were three revisions of Arduino UNO board - original one, revision 2 and revision 3.
All based on ATmega328P MCU, with a second ATmega working as USB to UART bridge (and replaced with dedicated bridge chip in various third-party clones), allowing for both in system programming and serial communication.
There is detailed comparison of those three revisions here: https://startingelectronics.org/articles/arduino/uno-r3-r2-differences/ and it seems that changes between versions are really minor: replacing secondary ATmega chip with one with more memory (in R3), addition of a diode or resistor, some additional pins or headers...
And then comes R4 - with Arm Cortex M4 processor (clocked at 48MHz), hardware floating point unit, 256 kB Flash memory, 32 kB SRAM, 8kB EEPROM, RTC, better ADC (up to 14 bit), additional DAC and powered from 5V like previous UNO versions.
It seems to be much better - faster, more memory and additional peripherals while retaining the same operating voltage and pinout. Can it be treated as direct replacement of R3? Name suggests that it can - there are many different Arm based Arduino board families, so calling it UNO R4 (given revision history of this family) holds certain promise that I will try to verify.
Arduino board for this RoadTest has arrived as OEM package, without familiar cardboard box, but with additional acrylic base, protecting it from accidental short-circuits when placed on something conductive
Visual inspection revealed familiar construction, with headers marked with pin descriptions and USB-C connector - time to prepare new cables!
Arduino UNO R4 is officially supported both in new (2.0) version of Arduino IDE and the old one (1.8) - but, as the architecture has changed, new board package needs to be installed (using board manager in 1.8 IDE).
After installation and connecting of the board, driver installation failure pop-up appeared, informing about problem with installation of CDC Port driver. IDE version update to the last available (1.8.19) didn't resolve this problem.
Board could still be programmed using Arduino IDE (Blink example was successfully built and uploaded), but serial emulation features were not present (Tools->Port was greyed-out and Serial Monitor was returning errors).
Moving development to more modern OS (MS Windows 10) have resolved this problem - everything started to work as usual.
CDC port driver problem needs to be addressed if someone wants to use out-of-support operating system (MS Windows 7) through. Ticket #1465 was created to address this issue but was resolved as belonging to the documentation area - MS Windows 7 is not supported anymore.
On the side note - Blink example for R4 consumes about 54kB of Flash (20% total) and 4.5kB of RAM (13% total), where the same code built for ATmega MCU (Arduino UNO R3) consumes 1.9kB of Flash (5% total) and 188B of RAM (9% total), so it seems that architecture overhead is eating up some of the extra resources R4 is providing, but still leaving plenty for user code.
Another observation when using 1.8 IDE was that serial monitor doesn't reconnect after board is reset - moving to IDE version 2 resolves this: after reset there is warning about loss of communication but it reconnects automatically after a while, so migration to new IDE seems recommended (ticket #11932 was created to ask if it is something that can be corrected).
Manufacturer's FAQ states that:
Can I use hardware compatible with the Arduino UNO R3 with the Arduino UNO R4 WiFi?
Yes, the Arduino UNO R4 WiFi was specifically designed to ensure compatibility with previous shields and compatible hardware developed for the Arduino UNO R3. The UNO R4 WiFi maintains the same mechanical and electrical compatibility, allowing you to seamlessly use your existing shields and hardware with the new board. This makes it easy to upgrade to the UNO R4 WiFi without the need for significant changes or adaptations to your projects.
Are all libraries compatible with the UNO R3 also compatible with the UNO R4 WiFi?
No, some UNO R3 libraries use instructions of the AVR architecture that are not compatible with the architecture of the UNO R4 WiFi, however there are libraries that have already been ported as part of our early adopters program or are based on the Arduino API.
More specific information about compatibility can be found under following links:
https://docs.arduino.cc/tutorials/uno-r4-minima/shield-compatibility (hardware)
https://github.com/arduino/uno-r4-library-compatibility (software)
Second one is particularly interesting - it provides list of libraries tested on Arduino UNO R4 along with test results.
As we have gathered some theoretical background about this board, let's do some testing.
All the test cases were repeated using Arduino UNO R3 (clone) and Arduino UNO R4 minima using the same code (usually exact copy of an example provided with the library tested - in rare cases slightly customized to reflect the configuration used - usually selecting of hardware type or a pin number) and the same hardware - installed as-is (in the case of UNO compatible shields) or over the prototype shield like below, that was moved from R3 to R4 to compare results.
As there was service ticket some time ago about slower than expected SPI performance of R4 (reported as "worse than R3"), let's first check SD library compatibility. We will start with CardInfo example, then perform read test on pre-generated files (1MB and bigger, filled with zeroes using dd if=/dev/zero of=./filename.bin bs=1000 count=1000 Linux command).
Initializing SD card...Wiring is correct and a card is present. Card type: SDHC Clusters: 485936 Blocks x Cluster: 64 Total Blocks: 31099904 Volume type is: FAT32 Volume size (Kb): 15549952 Volume size (Mb): 15185 Volume size (Gb): 14.83 Files found on the card (name, date and size in bytes): 1MB.BIN 2023-11-07 11:27:34 1000000 10MB.BIN 2023-11-07 11:27:42 10000000 100MB.BIN 2023-11-07 11:27:48 100000000 1000MB.BIN 2023-11-07 11:29:18 1000000000
So far, so good - card was detected correctly both on R3 and R4. Next - read performance testing.
Read test performs buffered read of the whole file using different buffer sizes and calculate total read time
while(dataFile.avaliable()) { cnt += dataFile.read(buf, LEN); }
and results are like below (for 1MB file):
buffer size | 1 | 16 | 128 |
UNO R3 | 37.8s | 7.0s | 5.2s |
UNO R4 | 9.4s | 4.3s | 4.0s |
So it seems that (using toolchain version 1.0.5) SPI performance has improved and greatly surpasses UNO R3 - especially for single byte reads. This test is a success.
Another test is Adafruit Neopixel library controlling WS2812 LED strip. This one is a failure - although it builds correctly for both R3 and R4 boards, simple example works only on R3. To be honest,, library repository doesn't state R4 as supported architecture yet, so it may improve in near future.
Our next test will be MQ-5 gas sensor module, using dedicated example named MQ-5 from MQUnifiedsensor library.
It could be interesting because Author is defining board type during library initialization (but - it seems - mainly for serial output customization):
#define placa "Arduino UNO"
//[...]
MQUnifiedsensor MQ5(placa, Voltage_Resolution, ADC_Bit_Resolution, pin, type);
Under R3 it is working correctly:
17:56:10.236 -> Development board: Arduino UNO
17:56:10.269 -> | ********************************************************************MQ-5*********************************************************************|
17:56:10.430 -> |ADC_In | Equation_V_ADC | Voltage_ADC | Equation_RS | Resistance_RS | EQ_Ratio | Ratio (RS/R0) | Equation_PPM | PPM |
17:56:11.103 -> |243.00| v = ADC*5.00/1023.00 | 1.19 | RS = ((5.00*RL)/Voltage) - RL| 32.01 | Ratio = RS/R0| 6.48 | ratio*a + b | 0.83 |
17:56:11.722 -> |243.00| v = ADC*5.00/1023.00 | 1.19 | RS = ((5.00*RL)/Voltage) - RL| 32.01 | Ratio = RS/R0| 6.48 | ratio*a + b | 0.83 |
During the compilation for R4, warning about untested architecture appears, library seems to work, but results are about tenfold bigger than obtained from R3:
18:02:06.876 -> |226.00| v = ADC*5.00/1023.00 | 1.10 | RS = ((5.00*RL)/Voltage) - RL| 35.27 | Ratio = RS/R0| 4.22 | ratio*a + b | 4.39 |
18:02:07.376 -> |231.00| v = ADC*5.00/1023.00 | 1.13 | RS = ((5.00*RL)/Voltage) - RL| 34.29 | Ratio = RS/R0| 4.11 | ratio*a + b | 4.89 |
18:02:08.224 -> |236.00| v = ADC*5.00/1023.00 | 1.15 | RS = ((5.00*RL)/Voltage) - RL| 33.35 | Ratio = RS/R0| 3.99 | ratio*a + b | 5.45 |
18:02:08.543 -> |241.00| v = ADC*5.00/1023.00 | 1.18 | RS = ((5.00*RL)/Voltage) - RL| 32.45 | Ratio = RS/R0| 3.89 | ratio*a + b | 6.05 |
18:02:09.175 -> |243.00| v = ADC*5.00/1023.00 | 1.19 | RS = ((5.00*RL)/Voltage) - RL| 32.10 | Ratio = RS/R0| 3.84 | ratio*a + b | 6.31 |
18:02:09.865 -> |245.00| v = ADC*5.00/1023.00 | 1.20 | RS = ((5.00*RL)/Voltage) - RL| 31.76 | Ratio = RS/R0| 3.80 | ratio*a + b | 6.58 |
So - partial success: library compiles, warns user about potentially unsupported hardware, works but provides data different than on UNO R3. Difference in readings is affecting sensor operation - when detecting gas stream from the gas lighter, R3 responds quicker and reading difference is far bigger (< 1ppm when no gas present to > 3ppm when exposed to gas leakage - compared to about 6ppm when no gas was present and > 8ppm when in the presence of leak on R4).
UPDATE - read difference between boards seems nondeterministic. Sometimes test results from R3 and R4 are very similar but in other cases difference is significant. This case needs further investigation (and maybe some additional sensors to eliminate the possibility of component fault).
Lcdkeypad_up_down_change_backlight example from ardiono-display-lcdkeypad library have compiled and worked correctly both on UNO R3 and R4 - so: another success.
Next test was reading from DHT11 sensor - this time without dedicated module, so additional pull-up resistor was needed. Using DHT_Unified_Sensor example (with modified sensor type and data pin) provided with DHT sensor library from Adafruit, sensor was read without problem from both UNO R3 and R4.
16:34:38.340 -> Humidity: 31.00%
16:34:39.412 -> Temperature: 26.20°C
16:34:39.412 -> Humidity: 31.00%
16:34:40.449 -> Temperature: 26.20°C
Success again.
Sweep example form Servo library was used to test servomotor integration. It has compiled and worked correctly for both UNO R3 and R4 - with somewhat different sound of operating servo under R4. The sound was not as monotonic as under R3 - more cyclic, maybe because better performance of R4 made servo running more like a series of start-stop operations than continuous move like under R3. Success.
Final test was integration of RC522 RFID reader. It was performed using DumpInfo example of MFRC522 library and was a success - despite architecture compatibility warning during compilation, it has compiled and executed on both R3 and R4 boards.
17:52:46.489 -> Card UID: B0 35 6E CA
17:52:46.564 -> Card SAK: 08
17:52:46.564 -> PICC type: MIFARE 1KB
This use case can really show some of real-life advantages of UNO R4, especially it's higher amount of RAM. Some of more advanced examples from this library tend to run unstable on R3, probably because of memory pressure when 1KB of data is being read into static buffer created in 2KB of RAM of ATmega328. This problem shouldn't happen in 32KB of RAM provided by the R4.
Now it's time for drawing some conclusions. Arduino UNO R4 is very useful board, to the high degree compatible with UNO R3, but much faster and with more resources. Big step forward with the familiar form factor and possibility of reusing existing shields. If it was named - for example - UNO+, I wouldn't say a word: compatibility level is remarkable - almost everything works out of the box.
But - in my opinion, naming it UNO (especially given the history of hardware revisions in UNO family - when one can buy R2 or R3 and doesn't even notice the difference) raises expectations to the level that no module of different architecture can truly fulfill.
There are myriads of different libraries or code snippets, in great part not supported anymore (which means - not going to be corrected, even by adding "R3" into the drawing) that are being copied and reused all the time, different howto's and tutorials using Arduino UNO as an example - so there will be incompatibilities from time to time.
To not get discouraged by them (especially if one is a beginner, eager to run some existing code but not prepared to debug and/or correct it), for now at least, one should remember than UNO R3 and UNO R4 are different architectures and board selection should be preceded by checking the compatibility of software that would be executed on it.