The Specs

I included the Pi 4B in addition to the Pi 5 and Radxa Rock 5B for comparison. I don’t believe anyone would argue that the Pi 5 isn’t a very welcome upgrade to the Pi 4B, but how does it stack up to the top line RK3588 based SBC’s that you can get from Radxa, Orange Pi or others?

CPU – Advantage Rock 5B

The 4x A76 cores of the Pi 5 are a big update from the 4x A72’s in the 4B. Personally I never felt that the Pi 4B was powerful enough for a GUI if you intend to use it as a regular desktop. The Rock 5B on the other hand has become my defacto standard desktop.

It is a bit disapointing to see that the RPI5 went with 4x A76 cores without the added 4x A55 cores of the RK3588. This seems even more odd when you look at the release dates of the different ARM cores:

• A72 – 2016 (RPI4)
• A76 – 2018 (RPI5 / RK3588)
• A78 – 2020
• A710 – 2021
• A715 – 2022
• A720 – 2023

It does take some time from an ARM release before new cores start showing up in devices, but I’m surprised that the RPI5 didn’t take advantage of the A78 to leapfrog the competition. Based on benchmarks of others with pre-release RPI5’s (https://www.youtube.com/watch?v=nBtOEmUqASQ) the RPI5 is coming out already at a performance disadvantage.

RAM – Draw

Both platforms are running LPDDR4. The Rock 5B lists 2112Mhz vs RPI5’s 4267Mhz, but don’t be fooled by that. From what I have seen, some platforms double the frequency if it is setup in dual channel. The 2112Mhz reported by the Rock 5B comes directly from UBoot. I have seen Radxa list it as 4224Mhz in some places.

Both platforms offer 4 and 8GB platforms. Rock 5B also offers a 16GB. Based on the datasheet the RK3588 is capable of addressing up to 32GB. I’m glad to see 4GB is the bottom end here. Given the CPU capabilities running 1 or 2GB of RAM seems like a waste. Personally I would run with 8GB unless there is a use case where you know 4GB will be sufficient.

NPU – Advantage Rock 5B

Personally I haven’t found an application to use the NPU available on the RK3588 yet, however it is surprising that in the day and age of everything AI that Raspberry Pi didn’t include one. This may come down to a Broadcom issue, but it does add another reason customers may choose a different platform. Given the number of years between Raspberry Pi releases, that means it could be 3+ years before we see a Raspberry Pi with an NPU.

GPU – Draw?

I generally don’t tax the GPU on my systems very heavily, and it is also difficult to compare GPU specs. Both systems seem to have a 4 core GPU. The Mali G610 MP4 on the RK3588 runs at 1Ghz and the Video Core VII on the RPI5 runs at 800Mhz. The Mali G610 MP4 data I could find reported 610 GFLOPS at FP32 vs the 51.2 GFLOPS for the Video Core VII. Does this mean that video is 10x better? Probably not. I’ll leave the video comparison to video experts.

Storage – Advantage Rock 5B

The Rock 5B comes with 3 storage options:

• Micro-SD with SDR104 support – Max at 104MBps
• eMMC port – Max at 400MBps
• M.2 PCIe 3.0 x4 supporting a standard 2280 SSD – Max at 4000MBps

Moving away from the typical SD card MASSIVELY boosts performance. The eMMC modules were quick, but nothing matches a PCIe SSD.

The RPI5 also has 3 options:

• Mircro-SD with SDR104 support – Max at 104MBps
• PCIe 2.0 x1 (requires a HAT with M.2 port as there is none onboard) – Max at 500MBps
• USB 3.0 (each USB3 port runs as a separate USB 3.0 controller with a full 5Gbps throughput) – Max at ~500MBps

The RPI5 increases the throughput on the MicroSD over the Pi4B, but doesn’t give anywhere near desktop level performance. This may be adaquate for a headless IOT device, but for anything running a desktop application this level of performance is abysmal.

PCIe 2.0×1 or USB3 could be used to increase storage throughput, but you are still maxed out at 500MBps. For comparison I have a Crucial P3 500GB SSD in my Rock 5B rated for 3500MBps read and 3000MBps write (PCIe 3.0 x4). I am surprised that Raspberry Pi didn’t provide any ability to handle the typical SSD’s that are available in desktops today.

I had to dig to find out that the Rock 5B / RK3588 does in fact support SDR104. For confirmation I popped a SanDisk Extreme microSD card in:

[4578960.554989] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 200000000Hz, actual 198000000HZ div = 0)
[4578960.665326] dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 360
[4578960.665358] mmc1: new ultra high speed SDR104 SDXC card at address e624
[4578960.666296] mmcblk1: mmc1:e624 SN64G 59.5 GiB 

The RPI5 still suffers from what I believe is the worst drawback to the PI4B, slow storage.

USB – Draw

The RPI5 documentation specifically calls out that the 2x USB 3.0 ports are controlled individually which means full 5Gbps on EACH port. This is great when you compare to the Pi 4B which has a single USB3 controller that supports both ports.

After digging through Rockchip RK3588 datasheets and testing different USB 3 devices on my Rock 5B, I can confirm that the Rock 5B also has dual USB3 controllers. It can be a bit tough to discern from the datasheet, but it appears that the RK3588 chip was designed to run displayport over those dual USB3 controllers (although I should note it does not appear that Radxa configured the Rock 5B to support displayport over USB3).

GPIO / I2C / SPI / UART / etc – Draw

I’m calling GPIO and other functions on the 40 pin header a draw. There is some variance on how many I2C and SPI buses each can handle, but both are highly configurable and can support multiple of each. The Rock 5B documentation does also call out an ADC sensor (which I have never found documentation or overlay files for) as well as a CAN bus (which I haven’t had a use for yet).

The only drawback I have for the Rock 5B is the issue I found will pull-up/pull-down (detailed here for the Orange Pi 5, but applies to the Rock 5B as well). I have been unable to get any information on why these don’t work or if they should. For now I’ve stuck to external pull-up/down resistors.

Power – Draw

It appears that Raspberry Pi has in fact added support for USB-C PD! That means the dreaded undervolt message may finally be a thing of the past! There does seem to be a drawback though. Using USB-C PD the PI5 does not have full power available for USB devices. I don’t have information on exactly what the limit is, but apparently this is not a factor with the 5V 5A official power supply.

I wish more companies would adopt USB-C PD! I’ve now acculumated quite a few power supplies that are looking for a new use!

Kernel and Software – Advantage RPI5

Software is where Raspberry Pi devices truely shine. They have by far the most mature and well maintained software ecosystem. Raspberry Pi 4’s are running kernel 6.1 while Rock 5B’s are stuck on 5.10. I also see VERY few kernel updates from Radxa which means we aren’t getting security updates even though 5.10 is an LTS release.

Raspberry Pi also has by far the best confguraiton tool (raspi-config) that other platforms are typically lacking. Radxa has no interface that can be used to select overlays or other board configuration options. The only other company I’ve seen with a near-peer tool is Orange Pi (covered it in detail here).

If you are new to SBC’s and GPIO’s, the Raspberry Pi is by FAR the easiest to learn on. If you are familiar enough with applying overlays, the Rock 5B provides a high level of capability, you just have to know where to look.

Networking – RPI5

Over the past few years we’ve seen a slow shift to 2.5Gbps Ethernet as a pseudo standard. More deivces are shipping with 2.5Gbps NIC’s, and retail switches are coming down in price to make it a reasonable option for home use. We are also starting to see 1Gbps+ home internet, so the shift to faster Ethernet switches is now starting to be a necessity.

That being said, the Rock 5B ships with 2.5Gbps Ethernet, but the RPI5 does not (1Gbps only). While I don’t count this as a big red mark against the Pi, it is an odd choice since it will likely be 3+ years before we get another Raspberry Pi.

While the Rock 5B does come with 2.5Gbps ethernet, it comes without WiFi or Bluetooth. There is a PCIe 2.0 x1 E-Key M.2 port (separate from the PCIe 3.0 x4 M.2 used for storage) for a WiFi / Bluetooth card so it can be added. This does just introduce additional cost if WiFi or Bluetooth is required, The RPI5 comes equipped with 802.11ac 2.4/5Ghz WiFi and Bluetooth 5.0 with BLE built-in.

Size – Depends on your need

The RPI5 follows the typical (now defacto standard) Raspberry Pi size: 85x56mm (3.370×2.224in). The Rock 5B actually follows the Pico-ITX form factor: 100x72mm (3.93×2.83in). This is a bit larger, but is still a compact system. If size is the biggest concern there is either the Pi Zero 2 W or multiple other similar sized boards available. There are also RK3588 boards that are smaller if size is truely a deciding factor. Personally I’m ok with the larger size coming with vastly increased storage speed, USB-C PD support, more and faster PCI-e, NPU, etc.

Summary

There are quite a few odd design choices with the RPI5 that I feel put it behind the curve:

• Quad core A76 – Missing the added 4x A55 cores of the RK3588, and not sure why newer A78 cores weren’t used.
• 1Gbps Ethernet – The standard today for new devices is moving to 2.5Gbps.
• No NPU – Other high end boards (i.e. anything based on the RK3588) include NPU’s. It would still be possible to add an external NPU via PCIe or USB3, it just consumes valuable ports.
• Faster storage! The SD104 update to the microSD is a nice addition, but the platform can’t compete with even years old desktop storage.

It seems like Raspberry Pi has become the slow moving Titantic and other vendors are pushing the boundaries further. I will certainly get a RPI5 as soon as I can find one. (I still haven’t found a Zero 2 W for less than an exorbitant price.) It is very unlikely that I’ll replace my Rock 5B as a desktop anytime soon.

Final Notes

If you are new to SBC’s the RPI5 (or even a PI4B if you can find them) is the best place to start. If you are looking for something with higher capacity to act as a file server, media server, etc, I think the Rock 5B and other equivalent RK3588 based systems are still the best option. Since the shortage of Pi’s during the pandemic, I’ve branched out and now don’t feel the Raspberry Pi is king of the hill any longer. I’m looking forward to seeing what the next generation of boards will bring!

The post RPI5 or Rock 5B? appeared first on Learning to Pi.

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

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). 

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

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).

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.

The post sbc_gpio: Pi 4B vs Rock 5B appeared first on Learning to Pi.

If you are looking for the results of the sbc_gpio tests, please check out our sbc_gpio Pi 4B vs Rock 5B comparison.

Configuring the sbc_gpio for the Raspberry Pi 4B test requires 1x I2C, 2x SPI, 1x UART and 2x IR (1 Tx and 1 Rx). All the configuration can be done directly in the /boot/config.txt file. Alternatively, some of the overlays may use the raspi-config tool (1x I2C, 1x SPI, 1x UART).

In all, the setup is quick and easy and only takes a few minutes. RPI does support applying overlays without a reboot, however I generally just add the configuration and reboot to apply the changes.

Raspi-config vs /boot/config.txt

The raspi-config tool is a quick and easy way to setup your Raspberry Pi SBC for some of the typical overlays, but not all overlays are exposed using this tool. For anything beyond the basics, you’ll need to edit the /boot/config.txt file directly. You can also bypass the raspi-config tool and edit the /boot/config.txt file manually for all overlays if you prefer. Where applicable I’ll show both methods for reference.

You can find a full breakdown of available /boot/config.txt file options on the Raspberry Pi website.

In the raspi-config tool, overlays can be accessed from the “Interface Options” menu:

I2C0 – 16×2 LCD display

Only the 1st I2C bus can be configured from the raspi-config tool:

Alternatively the following can be set in the /boot/config.txt file:

dtparam=i2c_arm=on

SPI0 – BME280 / BMP280

This uses our dht11_spi python library that uses the input on the SPI bus in conjunction with an output GPIO pin and a transistor to trigger and read the DHT11 sensor. You can read more about the dht11_spi library here. Only the 1st SPI bus (spi0) can be configured using the raspi-config tool:

Alternatively the following can be set in the /boot/config.txt file:

dtparam=spi=on
dtoverlay=spi0-1cs

SPI1 – BME280 / BMP280

Any SPI buses after the first need to be enabled from the /boot/config.txt file directly. The following will enable the SPI1 bus with 1 CS.

dtoverlay=spi1-1cs

UART0 – for serial communication

The UART0 interface will be used for sending serial traffic to a CP2102 USB to serial converter. The CP2102 USB port will connect back to the SBC. No drivers are needed for the CP2102 (necessary drivers are already present in the Linux kernel).

The UART0 serial port can be enabled using raspi-config. The first question is used to enable a console port to the Raspberry Pi over UART0 (select NO). The second question enables the UART0 interface for use by applications (select YES):

Alternatively, the UART can be enabled in the /boot/config.txt file:

enable_uart=1

Infrared Transmit and Receive

Infrared transmit or receive ports cannot be set using the raspi-config tool. In the /boot/config.txt file the following will enable a transmit (gpio-ir-tx) and receive (gpio-ir) pin. Replace the gpio_pin value with the appropriate number.

dtoverlay=gpio-ir,gpio_pin=23
dtoverlay=gpio-ir-tx,gpio_pin=24

You can create additional transmit or receive IR devices by simply adding another dtoverlay line with a new gpio pin number.

Summary

You will find that the Raspberry Pi platform is EXTREMELY well documented and running through the setup is a breeze. None of the overlays required any complex configuration. Most could be setup using the raspi-config wizard. There was also no need to run any update tools after modifying the /boot/config.txt file (like on some other platforms).

If you came here from our sbc_gpio test result page, feel free to jump back over to the results!

The post Raspberry Pi 4B Setup for sbc_gpio appeared first on Learning to Pi.