One of my goals over the past couple of years has been to find a suitable replacement for the Raspberry Pi 4B as supplies have been low and costs have been high. During the past couple of years, I’ve purchased several different boards to test out. Now that I have a GPIO abstraction layer and test library (you can read about it here or read the library documentation here) I am ready to start sharing some results. So without further ado, here is the first installment of the sbc_gpio: Pi 4B vs Rock 5B.
The purpose of the comparisons is not to showcase CPU, memory, NIC’s etc. The test library I’ll be using is intended to test GPIO and other functionality from Python. The idea is to compare the setup and functionality of the following:
- IR – using LIRC to both send and receive an infrared signal
- BMX – using SPI to read from a BME280 or BMP280 sensor
- I2C_DISPLAY – writes content to an 16×2 LCD display connected via I2C
- DHT_SPI – uses the SPI bus to read from a DHT11 or DHT22. See the DHT11_SPI class for more details on how to set this up
- LED – Flash an LED using the GPIO
- BUTTON – Watch for input on a GPIO
- UART – Send and receive data between a UART and USB to serial adapter
The purpose of the test isn’t to compare CPU and memory specs, but it is good to start with an understanding of how the hardware stacks up.
Hardware Specs
| Raspberry Pi 4B | Radxa Rock 5B | |
|---|---|---|
| CPU | Broadcom BCM2711 4x ARM Cortex-A72 (600Mhz – 1.8GHz) | Rockchip RK3588 4x ARM Cortex-A76 (408Mhz – 2.4Ghz) 4x ARM Cortex-A55 (408Mhz – 1.8Ghz) |
| NPU | N/A | 6 TOPS INT4/INT8/INT16/FP16 TensorFlow/MXNet/PyTorch/Caffe can be easily converted 300Mhz – 1Ghz (per /sys/class/devfreq/fdab0000.npu/available_frequencies |
| Memory | 1/2/4/8GB LPDDR4 3200Mhz 32-bit bus | 4/8/16GB LPDDR4 2112Mhz 64-bit bus |
| GPU | Broadcom VideoCore VI 4 cores (200 – 500Mhz) | ARM Mali-G610 MP4 3D GPU 4 cores (300Mhz – 1Ghz) |
| Video Decoding | H.264, H.265 HEVC (8/10bit), VP8, VP9, VC-1, AVC, JPEG | H.264, H.265 HEVC (8/10bit), VP8, VP9, VC-1, AVC, JPEG |
| Video Encoding | H.264, JPEG | H.264, H.265 HEVC (8/10bit), VP8, VP9, VC-1, AVC, JPEG |
| GPU FP16/FP32/FP64 | 64 / 32 / 8 GFLOPS | ? / 610 / ? GFLOPS |
| Video Out | 2x micro HDMI + MIPI DSI | 2x HDMI + MIPI DSI |
| Video In | MIPI CSI | 1x micro HDMI + MIPI CSI |
| Storage | MicroSD USB 3.0 attached storage is supported | PCIe 3.0 x4 M.2 M-key (up to 2280) MicroSD eMMC socket (ODroid compatible) 16MB SPI flash bootloader |
| USB | 2x USB 2.0 Type-A 2x USB 3.0 Type-A | 2x USB 2.0 Type-A 2x USB 3.0 Type-A |
| PCIe | N/A | PCIe 3.0 x4 M.2 M key (up to 2280 SSD for storage) PCIe 2.0 M.2 E key (for WiFi/Bluetooth module) |
| Networking | 1Gbps Broadcom (BCM54213PE) 802.11ac 2.4/5Ghz (Infineon CYW43455) | 2.5Gbps RTL8125 NIC No builtin wireless (requires PCIe M.2 E key module) |
| Bluetooth | Bluetooth 5.0, BLE (BCM54213PE) | No builtin wireless (requires PCIe M.2 E key module) |
| I2C | up to 6x | up to 5x |
| SPI | up to 6x (however some SPI pins overlap with other SPI devices so all can’t be used at once) | up to 3x |
| UART | up to 6x UART | up to 4x (5x listed on GPIO pinout, uart1 on pinout doesn’t have an overlay file. There are 2 additional overlay files that don’t match to pins on the GPIO header – uart 6 and 8) |
| PWM | up to 4x (2 PWM controllers with 2 outputs each) | up to 10x (10x listed on GPIO pinout, 4 additional overlay files that don’t match to pins on the GPIO header) |
| ADC (analog to digital) | N/A | 1x (could not find an overlay or any documentation for it yet) |
| CAN Bus | N/A | 1x (listed on GPIO pinout but no builtin overlay and driver isn’t compiled in the default kernel) |
| General GPIO / Other | up to 28x | up to 26x |
| Power | 5v DC with USB-C plug 3A 5v DC on pins 2&4 3A | USB PD 2.0 12/15/20v with 2amp or higher 9-20v DC power with USB-C plug 5v PoE power on pins 2&4 |
| Kernel Support | 6.1 (RPI fork, updates are pushed back to mainline) | 5.10 (Radxa fork, RK3588 mainline integration status) |
| Purchase Links | Amazon (1/2/4GB models) Amazon (8GB model) | Amazon (8GB model) OKDO (8GB model) |
The Raspberry Pi 4B in particular was impressive when it came out in 2019 the power boost over the Pi 3B was massive. I still found though that using the GUI with anything more than bare basics was way to slow for it to operate as a desktop replacement. The Rock 5B by comparison has become my defacto desktop for everything except for some apps that are Windows specific or that just aren’t available on Linux ARM yet. You can read about the software setup I have running here (includes Chromium with Chrome sync, XRDP for remote access, SSSD for AD Authentication, Blender and Cura for 3D Printing).
Hardware Setup
In order to keep the document a resonable length, I broke out the hardware configuration for both the Raspberry Pi 4B and Radxa Rock 5B into separate documents. The Pi 4B setup was straightforward and only required some edits in the /boot/config.txt file. The Rock 5B on the other hand required a kernel recompile (in order to add the IR drivers) and new overlay files. I documented the process for both:
Raspberry Pi 4B sbc_gpio hardware setup
Radxa Rock 5B sbc_gpio hardware setup
Results
I figured I would start with the results, then walk back through the setup and differences. I executed an hour long run of my sbc_gpio test using threading to run all tests simultaneously (FYI I also tested with async and didn’t see any appreciable differences).
| Pi 4B (RPi.GPIO) | Pi 4B (gpiod) | Rock 5B (gpiod) | |
|---|---|---|---|
| LED | OK | OK | OK |
| Button | OK | OK | OK |
| I2C Display | 3188 / 3188 – 100% | 3163 / 3163 – 100% | 3218 / 3218 – 100% |
| BMP/BME280 SPI | 3253 / 3253 – 100% | 3255 / 3255 – 100% | 3247 / 3247 – 100% |
| DHT11/22 (over SPI) | 1676 / 1701 – 99% | 1662 / 1698 – 98% | 1605 / 1685 – 95% |
| IR Tx/Rx | 1609 / 2545 – 63% | 1376 / 2544 – 54% | 2540 / 2540 – 100% |
| UART <-> CP2102 | 13155 / 14266 – 92% | 12663 / 13992 – 91% | 15148 / 15150 – 99.99% |
The results here were a bit startling. I expected the Pi4B to take everything I threw at it and not miss a beat. The DHT11 over SPI (which you can read more about here) I expected some failures. My SPI library is still vastly better than the old bit banging DHT11 library, but it isn’t perfect.
The infrared failures surprised me. I ran multiple tests and had varying results, but in general rarely saw much higher than the 54% above. Not sure what is causing IR to perform so poorly. I am using the same IR LED and IR receiver as I did on the Rock 5B, and both use the gpio-ir-tx and gpio-ir-recv kernel drivers. I’ll need to do some further tests to determine if it is a send or receive problem.
I was also shocked at the UART results. I didn’t expect as many failures as I saw. While it was only about 9%, this was a lot higher than I expected for basic serial communication. For my test the UART connects directly to a CP2102 USB to serial adapter that connects back to the SBC. I iterate through a range of baud rates (9600, 115200, 230400, 460800, 576000 and 921600) and data sizes (64, 128, 256, 512, 1024 and 2048) and track the results. I also track the send from the UART port (and received on USB) separately from the reverse. Here is a breakdown of the UART results on the Pi 4B.
Pi4B UART Breakdown – Transmission Size
| Size (bytes) | UART -> USB CP2102 | USB CP2102 -> UART |
|---|---|---|
| 64 | 1166 / 1166 – 100% | 1123 / 1166 – 96.3% |
| 128 | 1166 / 1166 – 100% | 903 / 1166 – 77.4% |
| 256 | 1081 / 1166 – 92.7% | 1055 / 1166 – 90.5% |
| 512 | 1081 / 1166 – 92.7% | 988 / 1166 – 84.7% |
| 1024 | 1166 / 1166 – 100% | 953 / 1166 – 81.7% |
| 2048 | 1166 / 1166 – 100% | 815 / 1166 – 69.9% |
| TOTAL | 6826 / 6996 – 97.6% | 5837 / 6996 – 83.4% |
Looking at the breakdown we see that there is a BIG difference depending on which side is sending vs receiving. I haven’t been able to determine if the issue is on the USB sending side, or the UART receiving side yet, but there is a very definitive issue and from the spread across data sizes it doesn’t appear to be directly related to the size (although we do see a drop in success rates as we move from 256 to 2048 bytes).
| Baudrate | UART -> USB | USB -> UART |
|---|---|---|
| 9600 | 1000 / 1170 – 85.5% | 635 / 1170 – 54.3% |
| 115200 | 1170 / 1170 – 100% | 910 / 1170 – 77.8% |
| 230400 | 1164 / 1164 – 100% | 1033 / 1164 – 88.7% |
| 460800 | 1164 / 1164 – 100% | 1043 / 1164 – 89.6% |
| 576000 | 1164 / 1164 – 100% | 1132 / 1164 – 97.3% |
| 921600 | 1164 / 1164 – 100% | 1084 / 1164 – 93.1% |
| TOTAL | 6826 / 6996 – 97.6% | 5837 / 6996 – 83.4% |
When we look at the data grouped by baud, we see some interesting results. ALL the drops from UART to USB happened at 9600 which seems counterintuitive. This leads me to believe there may be a buffering issue. The lower data rate requires the UART driver / hardware to hold data for a longer period of time while the bits are transmitted. We see a similar pattern from USB to UART. As the data rate moves up from 9600 to 57600 we see the success rate IMPROVE. At 921600 we see a slight drop off. This again makes me think buffering issues. Lower data rates that take longer to finish a transmission have a higher failure rate.
Looking at all this makes me lean toward an issue on the UART side sending at low data rates as well as receiving at low data rates. I used the same CP2102 on the Rock 5B and saw no issues so I wouldn’t expect that this is the issue. I’ll keep digging for more details and post and update if I find anything, but for now I’m going to say this is most likely due to a difference between how the Broadcom BCM2711 and Rockchip RK35688 handle the UART.
Setting up the SBC’s
Due to the length it takes to run through the setup, I’ll break these out into separate posts for each board.
As a summary though, configuring the Pi 4B was a breeze. The raspi-config tool can be used to configure the I2C, 1st SPI and UART. For the 2nd SPI, IR Tx and IR Rx, the configuration needs to be done in the /boot/config.txt file directly. After adding the relevant overlay config all that is required is to save and reboot. The Raspberry Pi even provides a mechanism for dynamically applying overlays without rebooting! (I haven’t tested this, but documentation is available here)
The Rock 5B is considerably more difficult. There is no equivalent to the raspi-config tool, so edits need to be made to the /boot/config.txt file directly. Adding the I2C, both SPI and UART overlays is straightfoward, however there is a problem with the IR. The stock kernel from Radxa didn’t include the necessary kernel drivers, so we had to recompile the kernel to include them. I addition there are no overlay files for IR so those need to be created as well. I walk through the process in my setup guide for the Rock 5B, however this is a far more complicated process than the Pi 4B.
Conclusion
Setting up the Rock 5B can be a bit of a headache if you need an overlay that isn’t included by default, and the Rock 5B doesn’t have an overlay available for IR, CAN or ADC. If you plan to use anything beyond I2C, SPI, UART or general GPIO expect the Rock 5B to be more complex to setup and use. That being said the results speak for themselves. If the Pi 4B is the gold standard, the Rock 5B has the potential to take the crown! All we need is some improvements in compiled drivers and overlays to call the Rock 5B the new gold standard!
NOTE: I’ve seen many articules reviewing the Rock 5B call out the lack of builtin wireless as the reason the Rock 5B isn’t ready to take over the crown. Personally I disagree with that assessment. Radxa provides a PCIe M-key slot that can be used with multiple different wireless cards (see supported lists here). Adding a wifi card does add a bit to the price but allows for more options and an upgrade path down the road.