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.

Table of Contents

• Orange Pi 5 Specs
• SBC Scoring Results
• GPIO’s (0/1)
• IR (1/1)
• I2C (1/1)
• SPI (1/2)
• UART (1/1)
• Subjective Performance (2/2)
• Ease of Use (1/2)
• Software Updates (1/2)
  • Kernel
  • System
• Community (1/2)
• Issues
• Overall (9/14)

Orange Pi 5 Specs

The specs for the OrangePi 5 are similar to the Radxa Rock 5B, but there are a few variances. The OrangePi 5 is a smaller board that uses the RK3588S chip (as opposed to the RK3588). The RK3588S is essentially a cut down version of the RK3588. The PCIe 3.0 has been removed which means that an NVMe SSD will need to use the PCIe 2.0 that the Rock 5B has for the wireless module. This also means that if you want to use an NVMe SSD, you’ll need to use USB for your WiFi.

NOTE: My testing was all performed using the Orange Pi 5. There are two similar boards available that have some slightly different options:

• OrangePi 5B – Removes the PCIe port and replaces it with built-in WiFi and Bluetooth. Same RK3588S with a 26 pin header (rather than the standard 40)/
• OrangePi 5 Plus – This is more similar to the Radxa Rock 5B. Uses the RK3588, has dual PCIe (1x M-Key and 1x E-key), dual HDMI out, eMMC interface, 40pin GPIO

I intentionally chose to skip the OrangePi 5 Plus since it is nearly identical to the Raxda Rock 5B. The OrangePi 5 has less GPIO ports and less PCIe, but it is also smaller and costs less. Based on what I’ve seen I would expect the OrangePi 5 Plus to perform nearly identical to the Radxa Rock 5B.

SBC Scoring Results

GPIO’s (0/1)

Before you cry foul, I didn’t knock off points for the fewer number of GPIO’s (uses a 26 pin header instead of a 40 pin). I bought this board knowing that there were fewer GPIO pins. I knocked off the GPIO point because I was unable to get internal pull-up or pull-down resistors to work AT ALL. Using libgpiod tools, I tested setting the pull-up and pull-down on multiple different pins and was unable to see any change.

The lack of pull-up and pull-down made me go back and re-test this on multiple other systems including:

• Radxa Rock 5B (RK3588) – ALSO wouldn’t apply internal pull-up or pull-down
• Raspberry Pi 4B (Broadcom BCM2711) – Works perfectly!
• Visionfive Starfive 2 (RISC-V JH7110) – Works perfectly! (Happened to be sitting on my desk, stay tuned for an article for this device)
• BIGTREETECH CB1 (Allwinner H616) – Works perfectly (within the confines of the pull-up/down resistors being a different value on some pins, see my CB1 article for more)

I did find reference to the pull-up/down in the Rockchip datasheets for the RK3588/RK3588S but can’t seem to get it to work on either the OrangePi 5 or Radxa Rock 5B. For now, external pull-up/down resistors are required.

NOTE: I did post a question in the Radxa (for the Rock 5B) forum but haven’t had a single response as of yet.

IR (1/1)

Just like the Rock 5B, the OrangePi 5 handled all the IR tests with no problem at all. The only downside is that you need to create the overlays yourself since OrangePi doesn’t include them in the built-in overlays. However, all the necessary drivers are already compiled into the kernel, and the orangepi-config tool had a section to install LIRC daemon and tools:

I’ll get into the orangepi-config tool more in the Ease of Use section. A copy of the overlay files can be found on our GitHub files share. OrangePi uses UBOOT startup with boot.scr that already incorporates a mechanism to add your own custom overlays. Simply copy the compiled overlay files (dbto) to the /boot/overlay-user directory, then add the following line to the /boot/orangepiEnv.txt file:

user_overlays=gpio-ir-recv-1d2 gpio-ir-tx-1d3

After a reboot, both LIRC devices are initialized and ready to go! Not quite as easy as a Raspberry Pi, but pretty close.

I2C (1/1)

Not a lot to say here. Unlike the BIGTREETECH CB1 which used a software I2C driver, there are 3x I2C devices exposed from the RK3588S SOC. I was impressed that they managed to configure 3x as optional on the 26 pin header. The orangepi-config tool has the option to enable the I2C:

Alternatively, you can add i2c5-m3 to the overlays line in the /boot/orangepiEnv.txt file.

Everything with the I2C display worked perfectly.

SPI (1/2)

For the SPI test, I used both a BME280 and DHT22 connected to SPI. (I created a Python library for reading DHT from the SPI bus since bit-banging has become too unreliable). Both worked, but I couldn’t run them both at the same time since OrangePi only exposed one SPI bus on the 26 pin header. We can’t connect the DHT22 to the same SPI bus as another device due to pull-up issues on the MISO port. I docked a point due to the fact that only one SPI bus was available. (I am working on a way to make the DHT SPI Python setup work alongside other SPI devices, more to come.)

Enabling the SPI bus is again a breeze using the orangepi-config tool.

Alternatively, you can add spi4-m0-cs1-spidev to the overlays line in the /boot/orangepiEnv.txt file.

The only confusing part is making sure you select the right one. Only spi4-m0 is exposed on the 26 pin header. It would be nice if OrangePi would just list the available overlays.

UART (1/1)

The UART tests passed without a hitch on the OrangePi 5 just like with the Radxa Rock 5B. I had essentially 100% success except for 1 test out of 15,000 always seems to fail. The Raspberry Pi 4B and 3B always seemed to end up in the 90-93% success rate that struck me as a buffering issue. The OrangePi 5 and Rock 5B based on the Rockchip 3588(S) worked flawlessly.

The only minor irritation here is that separate from the 26 pin header is a 3 pin serial header that is used for debugging. I have not yet found a way to re-purpose this UART port for use in the OS. If this could be converted to a standard UART interface that would free up additional ports on the limited 26 pin header.

Enabling the UART is again a breeze using the orangepi-config tool.

Alternatively, you can add uart0-m2 to the overlays line in the /boot/orangepiEnv.txt file.

Subjective Performance (2/2)

The RK3588S in the OrangePi 5 is essentially the same as the RK3588 in the Rock 5B when it comes to CPU. Both have 4x A76 (up to 2.4Ghz) and 4x A55 (up to 1.8Ghz). My main bottleneck was the SD card I was booting from. I have an NVMe SSD to install, I just haven’t set it up yet. As far as I’m concerned, the RK3588(S) is good enough to use as a normal desktop.

OrangePi also has ZRAM pre-configured in their image (virtual swap space using compressed RAM, see my article on ZRAM for more info). I’ve found that swap setup isn’t configured by all vendors, so I was pleased to see this. I also saw that ZRAM was used to create a compressed mount point for /var/log. This is something I haven’t seen on other images from board vendors. Moving logging into RAM loses persistence, but for devices running on SD cards it will boost performance by eliminating a lot of background writes, and extend the life of your SD card.

Ease of Use (1/2)

I really want to give OrangePi props for their orangepi-config tool. This is the ONLY vendor I’ve found so far with a tool that can come close to matching the raspi-config tool. The orangepi-config tool even has several features that raspi-config doesn’t have.

I showed some parts of the orangepi-config tool above while configuring the I2C, SPI and UART overlays.

As you can see, we have a range of options available:

• Programming the bootloader to different devices
• Editing the orangepiEnv.txt file
• Selecting overlays
• Configuring network settings
• Installing / uninstalling LIRC
• Time zone
• SSH options (including OTP)
• Even some 3rd Party software

I really would give this a 2/2 if not for a few oddities:

• Overlay page lists overlays that are not applicable (i.e. SPI overlays that use pins not exposed on the OrangePi 5, although they may work on the OrangePi 5 Pro)
• Change some setting aren’t reflected until you close the app and re-open it (i.e. the time zone)
• It isn’t always clear what selecting something will do. For example, selecting “Avahi” from the system settings menu will kick off downloading and installing packages, as well as configuring them without any clear message as to what was about to happen.
• Crashed several times

The orangepi-config tool is excellent but has some rough edges. I would certainly start here to configure your SBC.

Software Updates (1/2)

Kernel

Just like with every SBC I’ve worked with that ISN’T a Raspberry Pi, the kernel doesn’t seem to be getting any updates. The OrangePi 5 uses the same 5.10.110 kernel that is used by the Radxa Rock 5B (not entirely surprising since they are almost the same chip). They both appear to use the same Rockchip kernel as their base, and I don’t see any security updates being applied.

It seems safe to assume that Rockchip selected 5.10 since it is an LTS release that is slated for support through December 2026. However, they forked at 5.10.110 and the kernel has continued on to 5.10.192 (as of August 2023). This seems to defeat the purpose of using an LTS kernel if you aren’t ever going to update it.

System

Here is where things get a bit strange. The image I downloaded was the official OrangePi 5 Ubuntu 22.04 (jammy) release. For some reason rather than using Ubuntu mirrors, the system is configured to use Huawei servers for Ubuntu and aliyun.com for Docker. Here are the apt sources (from /etc/apt/sources.list and /etc/apt/sources.list.d/docker.list):

deb http://repo.huaweicloud.com/ubuntu-ports/ jammy main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-security main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-updates main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-backports main restricted universe multiverse
deb [arch=arm64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu jammy stable

The aliyun.com mirror for docker seems to be a Docker supported mirror (based on its presence in the Docker install script). The Huawei mirror also seems legit based on https://launchpad.net/ubuntu/+mirror/repo.huaweicloud.com-archive. I get that OrangePi is a Chinese company, and these mirrors may make the most sense for them, but it would be nice to see an image for those of us not in China. Using a wired connection on my Gigabit internet, I was seeing up to 200ms latency to the Huawei mirrors (NOTE: repo.huaweicloud.com resolved to a CDN, so milage here may vary).

Unusual APT sources aside, they do appear to mirror the official Ubuntu release, so we are getting updates. It was also nice to see a 22.04 image rather than the 20.04 that some other vendors provide.

Community (1/2)

There is an OrangePi forum (http://www.orangepi.org/orangepibbsen/), however it seems relatively small. The forum also covers a wide range of SBC boards that OrangePi offers which can be good and bad. On the plus side, the OrangePi 5 is not their first board, so the setup seems well thought out. The downside is it has been difficult to find much for this specific board. Searching the forum for “OrangePi 5” only found 31 matches and quite a few of those weren’t for the OrangePi 5.

This also brings me to another issue, the name. OrangePi is the company, the model is “5”. There is also a “5B” (which is basically the same board with WiFi and BT in place of the PCIe slot) and a “5 Pro” which is a different chip (RK3588 instead of the RK3588S). The “5 Pro” has quite a few different features including two PCIe slots and a 40 pin GPIO header. Searching for the OrangePi 5 has actually been a bit of a struggle. I keep getting results for the “5 Pro” that don’t apply, or just end up with OrangePi articles that have the number “5” somewhere in them. More characters in the name would make searching a bit easier. Even making it a “5A” and “5B” would help.

Issues

In the GPIO section I covered the issue with the internal pull-up and pull-down. I was not able to get either to work on any of the pins I tested using multiple version of libgpiod. This isn’t a total show-stopper, it just means that external pull-up or pull-down resistors are required until I can figure out if they are just not supported on the RK3588/RK3588S or if it is a bug that needs fixing.

The other issues are pretty minor. I only have 1 SPI bus available which meant I couldn’t test the BME280 and DHT22 at the same time (this is a limitation of how I am reading the DHT22 sensor and not a limitation of the SPI bus itself). I was also a bit surprised by the APT repos, but that should be configurable.

Overall (9/14)

All in all, this is a very solid system. The orangepi-config utility gives a level of usability that my Radxa Rock 5B was missing. You can tell that OrangePi has been building SBC’s for some time now based of the effort put into the software.

The only real caution here is the limited number of GPIO’s and the issue with internal pull-up/pull-down resistors. If you think you’ll need 2x SPI or just more GPIO’s in general then I would suggest looking at the OrangePi 5 Pro instead (where the full 40 pin header is available). This board only scored lower than the Radxa Rock 5B due to the single SPI bus.

One last note on a performance perspective. the RK3588S appears to drop the PCIe 3.0 x4 bus that is present on the RK3588. That means that the NVMe slot is connected to the PCIe 2.0 x1 bus. The theoretical throughput limit is 500MB/sec which will still outperform eMMC or SD cards by a healthy margin.

I would highly recommend the OrangePi 5 (or one of the variants)!

The post OrangePi 5 – Testing with sbc_gpio appeared first on Learning to Pi.

I’ll walk through what I learned with this device and show some of the use cases it may come in handy, as well as where some of the shortfalls are.

Table of Contents

• Scoring and Specs
• SBC Scoring Results
• GPIO’s (1/1)
  • The Pinout Confusion
  • Official Pinout Table
  • Logic Level – 1.8v or 3.3v?
  • Pull-up / Pull-down Resistors
• IR (1/1)
• I2C (0/1)
• SPI (1/2)
• UART (0/1)
• Subjective Performance (1/2)
• Ease of Use (0/2)
• Software Updates (1/2)
• Community (0/2)
• Issues
  • Security Groups and UDEV not setup for I2C and SPI
  • No I2C only overlay
  • Pins that don’t work (PG6, PG7, PG8, PG9)
  • UART0 overlaps with TWI and PWM
  • UART0 doesn’t work over 115200
  • Pull-up / Pull-down Resistor Inconsistancy
• Overall (5/14)

Scoring and Specs

Here is a breakdown of the scoring. I’ll cover each section below to describe how I came to the numbers.

The specifications for the CB1 that I was able to collect are available below:

NOTE: The Pi4B carrier board has capabilities that the CB1 doesn’t (i.e. a Gigabit NIC). The specifications are specific to the CB1 itself.

SBC Scoring Results

GPIO’s (1/1)

I gave a point for GPIO’s because the CB1 has more than 8. However there are 8 pins on the 40 pin header that are not connected (per their documentation). I found an additional 4 that were present in the documentation but flat out wouldn’t work (PG6, PG7, PG8 and PG9).

NOTE: The Allwinner H616 has TONS of available GPIO’s, SPI, I2C, UART, etc, etc. For whatever reason they just aren’t connected to pins that you can use. This will become a common theme.

The Pinout Confusion

I copied the HTML directly from the CB1 readme file. Understanding the table took a bit. There are apparently two different versions of the CB1. Mine has no eMMC. I couldn’t find the eMMC version anywhere. You can also see that the pin layout is different between the two CB1’s (with and without eMMC). They throw in the Pi CM4 for reference as well as some other board (BTT Pi) which just adds to the confusion.

Official Pinout Table

Logic Level – 1.8v or 3.3v?

You’ll also find if you read through the manual (page 12) that if you have version 2.1 of the board PC6, PC7, PC8, PC9, PC10, PC11, PC12, PC13, PC14 and PC4 pins use logic voltage of 1.8v, but if you have version 2.2 it is 3.3v. I’ve never before seen anything like this. You’ll need to be sure of which version you have before laying out your project.

Pull-up / Pull-down Resistors

While testing my GPIO input that I’ve used on every other board I’ve tested I also discovered that the H616 SoC uses different pull-up/pull-down resistors for different blocks of pins. Directly from the H616 datasheet:

• For PL0~PL1 ports the Rpu and Rpd are 4.7kΩ ±20%
• For PC0, PC3 ~PC7, PF3 , PF6, a nd PG1~PG5 ports, the Rpu and Rpd are 15kΩ ±20%
• For other GPIO ports, the Rpu and Rpd are 100kΩ ±20%

For reference the Raspberry Pi uses pull-up / pull-down resistors that are 50-65kΩ. I happened to pick port that had a 4.7kΩ pull-down which caused my button which was connected to 3.3v through a 1kΩ resistor not to work. This is the first platform I’ve used that had different internal resistor values depending on the pin. BEWARE!

IR (1/1)

Here I was pleasantly suprised. The CB1 H616 SoC includes a hardware IR receiver. This resulted in a 85% success rate used in conjunction with the GPIO bit-banging IR transmitter. While 85% may not seem great it was actually an improvement over the Pi4B using the software IR receiver. Only the Rock 5B with it’s massive processing power managed a 100% success rate on the IR test so far.

Given that IR is subject to external interference, I believe that the CB1 would work for a project requiring an IR receiver.

I2C (0/1)

The H616 can support up to 6 TWI interfaces.

I had to look it up and apparently TWI is electrically compatible with I2C. It appears that the “TWI” (Two-Wire-Interface) was created to avoid trademark issues.

While the SoC can support up to 6 there are only 2 pins exposed that connect to a TWI/I2C interface (per the H616 documentation). That is PH0 and PH1. These ALSO are the only two ports that connect to a UART interface.

I did test disabling the UART and testing the ports as TWI/I2C but to no avail. I was unable to get it to pick up that I had any devices connected on the TWI/I2C bus. Given that Bigtreetech didn’t include any overalys for the TWI/I2C I have to assume that there was some other board design choice that makes this impossible.

Bigtreetech DID provide an overlay to enable a software based I2C bus which works about as well as it did on the Atomic Pi. Which is to say, it works ok as long as your device is idle, but trying to use the soft I2C bus during the tests resulted in an 18% success in writing to the display. The rest of the time I ended up with garbled text displaying.

I would avoid using software bit-banging I2C unless there is no other option. From my experience the soft I2C and SPI drivers are error prone.

Also as a note the “biqu” default user wasn’t added to the i2c group.

A copy of overlay files I created are available on our GitHub files here: https://learningtopi.github.io/cb1

SPI (1/2)

I gave the CB1 one of two possible points. This was because only ONE if the TWO SPI interfaces on the H616 were exposed on pins (SPI1 for some reason). I was able to get the SPI bus to work with both my bmx280_spi and dht11_spi packages, but can’t use both at the same time (DHT11 setup causes a conflict which I’ll have to look into later).

Also once the overlay was enabled and the SPI devices were created the system wasn’t setup for anyone other than root. Running the following and rebooting will resolve this issue. It is an inconvienience that this isn’t setup out of the box.

groupadd spi 
echo 'SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"' > /etc/udev/rules.d/99-spi.rules 
usermod -G spi -a biqu 

Last note on SPI, Bigtreetech provides an overlay to enable SPI1_cs0 and SPI1_cs1, however regardless if which one you use both CS0 and CS1 are enabled for SPI1. After digging through the dtb files (using fdtdump) it appears that they are not propperly setting CS pins to disabled. This CAN be done with an overlay (I tested it to verify), but it is a bit odd to provide specific SPI1_CS0 and SPI1_CS1 overlays if they aren’t being controlled individually.

A copy of overlay files I created are available on our GitHub files here: https://learningtopi.github.io/cb1

UART (0/1)

UART was an extreme disapointment. Everything worked great up to 115200 baud. Once I moved from 115200 to 230400 I started to see issues when receiveing on the UART interface (sending from the USB), however traffic going from UART to USB still worked. At 460800 UART to USB failed far more often then not. 576000 and 921600 were a lost cause.

I did test moving the USB interface to my Rock 5B and just used pySerial to send and receive back and forth. I experienced the exact issues at the same speeds. There has to be something either with the carrier board or the setup on the CB1 itself causing this problem.

I ended up with a 42% overall success rate which I consider a failure. Unless you know you won’t need higher than a 115200 baud, I would suggest looking at a different platform. Basically any other SBC.

Subjective Performance (1/2)

Performance-wise, the CB1 feels pretty snappy. I will note that I am running a trimmed down Debian Bookworm image from Bigtreetech with no GUI. Given that we only have 1GB of RAM I would only consider this for a non-GUI headless system anyway.

I’ll also note that the positive performance may be partially due to the fact that Bigtreetech disabled CPU speed scaling in their kernel. This may make some sense if you look at the board as a controller for a 3D printer, but for an IOT device this is not my ideal setup. I mentioned earlier that the heatsink is really required and this is why. This system runs HOT. WAY hotter than other SBC’s given that this only has 4x A53 cores.

For comparison, on the left is my Rock 5B which has the Rk3588 (4x A76 + 4x A55 cores) running at 52-53°C (125-127°F) compared to 57°C (134°F). Both systems have a passive heatsink (albiet the Rock 5B has a much larger one).

Since they disabled CPU scaling in the kernel, as far as I know this means that the kernel can’t throttle the CPU if temperature reaches critical.

Ease of Use (0/2)

I would say the biggest issue with usability is overlays. There are only a handful available:

• disable_uart0: This one is pretty self explanitory and works as you would expect
• ir: This one is also self explanitory and enables the IR receiver
• light: Not clear why this is called “light”. It disables UART0, enables the bit-banging I2C as well as the PWM. Without dumping the DTBO file you really wouldn’t have a clue what this is doing
• mcp2515: This one enables the mcp2515 CAN bus, but also SPI1. Why SPI? I am not familiar with CAN buses, but from the system overlay it appears that the mcp2515 is a sub-object to spi@5011000 (SPI1).
• pwm: This enables the only available, PWM but DOESN’T disable the UART (which is on the same set of pins). So make sure you also include disable_uart0 if you use this.
• spidev0_0: Not sure why this is even here, SPI0 isn’t exposed on any pins
• spidev1_0, spidev1_1, spidev1_2: These are frustrating. They all turn on SPI1 with 2x CS (0 and 1). Under the spi@5011000 device, the cs pins are set uising the “cs-gpios” field. None of these overlays edit this field. You CAN edit or remove CS pins by creating your own overlay to edit this field, but having these overlays not do what they imply is confusing.

The CB1 kernel DOES include the configfs which is a great feature to adding overlays after boot. This doesn’t however overcome the lack of documentation, pins that aren’t connected, pins that are supposed to be connected and aren’t, lack of hardware I2C, single UART and overlaping functions on pins with no alternatives available.

If you decide to buy a CB1 for something other than running a 3D printer, be prepared to write your own overlay files.

A copy of overlay files I created are available on our GitHub files here: https://learningtopi.github.io/cb1

Software Updates (1/2)

The CB1 image I downloaded is a Debian Bookworm build which is very promising. It appears that they are up to date on their distributions! Bookworm (Debian 12) was only recently released. The downside is the kernel. The CB1 is running 5.16 which was NOT a long term train (5.15 was). 5.16 stopped receiving security updates over a year ago (April 2022). The bizzare thing is that they appear to have started with 5.16.17 in August of 2022 AFTER support was ended. And they didn’t even start with the last release which was 5.16.20.

You may be able to keep the system up to date, but the kernel was out of support when they started.

Community (0/2)

I could find practically no community for the CB1. The first discussion board I found for the CB1 (https://github.com/bigtreetech/CB1/discussions) says it is abandoned (not a good start) and only has a handful of discussions from 2022. The link at the top of this discussion board linked to another discussion board (https://github.com/bigtreetech/CB1/discussions/8) that ALSO says it is abandoned. This page had a total of 6 comments and 9 replies. This just takes you to a discussion for the Bullseye minimal image (which I’m not even running): https://github.com/bigtreetech/CB1/discussions/9. Again here there was still only 25 comments and 43 replies.

Don’t expect to find a lot of community feedback for this board.

Issues

Security Groups and UDEV not setup for I2C and SPI

I mentioned under the I2C section that the biqu default user wasn’t in the i2c user group. For SPI, devices were created with only root access. I had to create the spi group, create a udev rule and add the biqu user to the spi group. While this is not extraordinarily complicated to do, if you are are not familiar with the udev rules it may take some time to setup non-root access. More mature SBC platforms have this configured out of the box ready to use.

No I2C only overlay

Also in the I2C section I called out the lack of a dedicated I2C overlay (even though it is a bit-banging software overlay and not a hardware one). The “light” and “tft” overlays turn on I2C in addition to other functions that you may or may not want. (For example “tft” also disables the HDMI port, “light” disables the only UART and enables PWM in its place.)

There is of course nothing stopping you from creating your own overlay files. The CB1 uses a boot.cmd UBOOT script that includes a check for user provided overlays. Simply create the /boot/overlay-user directory and place your compiled DTBO files here. In the BoardEnv.txt file, add a line for user_overlays. Then just add a space separated list of overlays you want to create.

Pins that don’t work (PG6, PG7, PG8, PG9)

For some unknown reason these 4 pins just wouldn’t work. They are documented in the pinout, I could reserve the pins but setting them high or low had no affect. Using my oscilliscope I was never able to get a signal on these pins. All I get is background static the same as I get on the pins that Bigtreetech marked as “not connected”. Not sure why these pins don’t work since they are listed on the schematic (https://github.com/bigtreetech/CB1/blob/master/Hardware/BIGTREETECH_CB1_V22_220812_SCH.pdf) on connector A1-100.

UART0 overlaps with TWI and PWM

The PH0 and PH1 pins are the only pins that can be used for UART0, TWI (I2C although I still couldn’t get this to work) and PWM. You get to pick one of these three functions. None of the other connected pins support any of these functions (other than running the soft I2C driver). This is severly limiting in terms of what functions are available.

UART0 doesn’t work over 115200

I was not able to figure out what caused this, but the only UART interface doesn’t work consistently (or at all) over 115200 baud. While this may work for some projects, it does show that SOMETHING is wrong design wise. Unfortunately I don’t have another board with an H616 for comparison so I don’t know if this is an Allwinner H616 chip level issue or if this is a Bigtreetech CB1 issue.

Pull-up / Pull-down Resistor Inconsistancy

I covered this above (#htoc-pull-up-pull-down-resistors). Some pins use different pull-up and pull-down resistors. This caused my input button setup on my breadboard not to function at all on certain pins. After I swapped the resistor I was using to the 3.3V rail it worked fine, it just took some time to sort out what the issue was. I have not run across this particular setup on other SoC’s. I’ll be on the lookout from now on.

Overall (5/14)

If you consider the original intended purpose of this board (to run a 3D printer), most of the issues and problems I ran across are probably non-issues. Trying to use this board as a general IOT device is far more problematic. The lack of functions exposed on pins make it extremely hard to find a good use for this device. The only 2 things that I didn’t have any major issues with was SPI (other than missing udev setup and security groups) and IR. I2C is software based, the UART didn’t work consistently (or at all) over 115200 and 4 of the GPIO’s documented in their notes wouldn’t work. There are also 6 pins that just aren’t connected to anything (on TOP of the 4 I couldn’t get to work).

All in all I would say if you aren’t planning to use this for a 3D printer I would suggest looking for an alternative. It may work for some specific use cases, but you will likely need to recompile the kernel to get CPU throttling turned back on and you have limited IO functionality.

A copy of overlay files I created are available on our GitHub files here: https://learningtopi.github.io/cb1

The post Bigtreetech CB1 appeared first on Learning to Pi.

Table of Contents

• Scoring and Specs
• SBC Scoring Results
• GPIO’s (1/1)
  • Updated GPIO Table
  • Major GPIO limitations:
• IR (0/1)
• I2C (0/1)
• SPI (0/2)
• UART (1/1)
• Subjective Performance (1/2)
• Ease of Use (1/2)
• Software Updates (1/2)
• Community (0/2)
• Issues
  • Power Issues
  • CMOS Battery
  • eMMC
• Overall (5/14)

Scoring and Specs

Here is a breakdown of the scoring. I’ll cover each section below to describe how I came to the numbers.

SBC Scoring Results

The specifications for the Atomic Pi that I was able to collect are available below:

GPIO’s (1/1)

The main set of IO on the breakout board is the 11 screw terminals that connect off the 26-pin plug on the bottom of the main board. Here we have the following:

• 6x general GPIO pins
  • GPIO1 and GPIO2 also connect to LEDs on the breakout board
• 2x UART (RXD1/TXD1 and RXD2/TXD2)
  • These CANNOT be repurposed

In addition to the main IO block, there are two additional 3-pin blocks on the back of the board. J9 has 2 pins for volume that can be repurposed as general GPIO’s. J10 has another UART (also CANNOT be repurposed).

Schematics here: https://www.digital-loggers.com/enchillada.pdf

I’ll note this again later with documentation, but the GPIO info listed in the official documentation appears to be wrong. The main GPIO documentation (https://download.fosc.space/atomic_pi/guide/html/gpio.html) says that the GPIO’s are on GPIO chip 3, when they are actually on GPIO chip 2. It DOES list global pin numbers that are correct, but modern Python libraries using gpiod use the Chip/Pin combo which threw my testing for a loop.

Updated GPIO Table

The Green and Yellow LEDs are connected to VCC3 (3.3v) and the GPIO through a 1k resistor. Using GPIO1 and GPIO2 as an input is essentially impossible as these GPIO’s will be pulled high at all times.

Major GPIO limitations:

• As noted, UART pins cannot be reused as GPIO
• There are no pull up/pull down options available (can’t say if the hardware itself is capable, there does not appear to be any way to set it using the 5.4 kernel that the Atomic Pi is running). External pull up/down must be used
• Limited numbers – only 8 total GPIO’s can be used
• GPIO1 and GPIO2 are connected to 3.3v via the LEDs which means they are usable for output only.

I am technically passing the GPIO category, since there are 8 usable GPIO’s, but the limitations make it a tough call.

IR (0/1)

Enabling the GPIO UART was relatively simple. The 5.4 kernel has compiled in a patch that exposes the ability to create and delete (although deleting is not recommended) overlays on the fly. This means we just needed to create the DTS files, compile them, then load using the following:

sudo mkdir /sys/kernel/config/device-tree/overlays/{overlay-name}
sudo cat {overlay}.dtbo > /sys/kernel/config/device-tree/overlays/{overlay-name}/dtbo

You can find copy of the DTS files as well as the application script on our GitHub: https://github.com/LearningToPi/learningtopi.github.io/tree/main/files/atomicpi

Applying the overlay was simple, however the receiver would only occasionally pick up the transmitted signal. I was a bit surprised at this but given other issues didn’t see digging deeper as necessary.

I2C (0/1)

The Atomic Pi has no hardware I2C or SPI capabilities. Digital Logger provides a software-based driver that can be used to create I2C or SPI on the limited number of GPIOs. The I2C driver uses a daemon to load overlays based on files located in the /etc/i2c-gpio-custom.d folder. There is an existing bus for the BNO055 sensor built into the board. You can’t use the I2C bus used for the BNO055, so simply create a new file and provide the parameters outlined in the README file. I used pins 476 and 480 for my SDA and SCL pins (creating a new bus 41). Simply restart the board or restart the daemon:

sudo systemctl restart i2c-gpio-custom

The I2C bus shows up, and I’m able to see the device using i2cdetect. I am also able to connect to my 16×2 LCD and write content to the display! However, as soon as I loaded up the system with other tasks (in particular the IR) the number of successful writes to the I2C device plummeted. In the end a 52% success rate was all I could manage with IR enabled. Also note that due to the lack of GPIO’s, I was unable to run I2C and SPI at the same time. The best I could manage was simple GPIO in and out, UART and I2C together.

Please note that even the aged Raspberry Pi 3B+ is able to run the I2C bus with no issues since there is a hardware controller available. I have found numerous posts on the internet of people having success with I2C on the Atomic Pi, so before you call foul, your experience will vary depending on how busy the system is with other tasks. I wouldn’t depend on the software driver.

SPI (0/2)

The SPI driver works exactly the same as the I2C above. The SPI driver is configured using files in the /etc/spi-gpio-custom.d folder. Here you need to provide a bit more info. This includes a bus ID (0), CLK (335), MOSI (329), MISO (336), mode (0), max frequency (500,000), and CS pin (338). Restarting the service or the board will create your SPI bus:

sudo systemctl restart spi-gpio-custom

For reasons unknown this well for my BME280 sensor with no load. Under load I saw that the reads were successful, but the BME280 sensor was reporting my office was below freezing or approaching the boiling point of water. This is most likely due to bits getting flipped or mismatches in the timing. I would say that it is hard to trust your sensor data if you are reading over a software SPI interface.

When attempting to use my DHT22 over SPI (Python dht11_spi for details if this is new for you) was a complete failure. From what I can gather, the software SPI bus is not able to process the data quickly enough.

UART (1/1)

With UART we had great success! There are 3 available HARDWARE UART ports available. Two are available on the main breakout (J1) and one on the debug header (CN10). I left the debug header as a console interface and used UART1 on the breakout.

Traffic between the UART and USB CP2102 ran perfectly in both directions. With IR running I consistently saw 98% success (out of 14760 tests). With IR disabled it went to 100%. I can say that this was a complete success and performs even better than the RPi4B did.

UART was the ONLY test that passed with flying colors.

Subjective Performance (1/2)

This category is a bit open. I have 3 possible values:

• 0: The system is extraordinarily slow. It may be functional, but performance was an issue
• 1: The system works about like we would expect from an SBC. It was not excessivly slow and booted quickly. However, it doesn’t have any “wow”.
• 2: This is reserved for the “wow” devices. So far one device (the Radxa Rock 5B) fits into this category.

The Atomic Pi boots relatively quick. The BIOS POST is certainly slower than UBOOT on an ARM device. Out of the box the Atomic Pi comes with a built-in eMMC that was significantly quicker than a Micro SD Card and gave it a bit of an edge in performance. However, the eMMC failed and left me with SD. I’ll talk about the eMMC under the problems category below.

Ease of Use (1/2)

This wasn’t hard to grade. The software SPI and I2C buses are easy to set up and use. The sysfs driver for the overlays makes adding overlays for IR easy. Since we don’t have the ability to load overlays during the boot process on x86 like we do with ARM this is a must have.

I did have to doc a point for incorrect documentation. Not having correct GPIO Chip / Pin numbers listed for the few GPIOs that are available made using the system significantly more difficult than it should have been.

Software Updates (1/2)

This was a tough category. Given the issues that I have seen of late in the IOT world, any project should be able to be maintained and updated with security patches. On the plus side, as an x86 board, the Atomic Pi can run vanilla Ubuntu or really any other distribution that you want. The DOWNSIDE is that to maintain the “ease of use” we talked about above; you need to run the Digital Loggers kernel and here is where the problem comes in. The kernel is 5.4.30 and doesn’t appear to ever get updated. Digital Loggers GitHub does NOT have a repo for their kernel either.

5.4 is a long-term release, but 5.4.30 is from April in 2020. Since it is July 2023, it seems likely that this isn’t being actively maintained. This leaves you with a choice:

1. Keep the functionality for I2C/SPI and the ability to load overlays
2. Keep your system up to date on a supported kernel

Community (0/2)

I was able to find others that had purchased and used this board, but don’t expect anything like the community available for Raspberry Pi products. There is really only one “community” page here: http://ehxz.tk/atomicpi. There are some downloads available with different Ubuntu / Debian images as well as BIOS files, but that’s really about it. Don’t expect a large community with examples to pull from.

Issues

During setup, testing, or normal usage I ran into a few problems.

Power Issues

I tried using Pi 4B adapters and numerous other 5V power supplies to no avail. I even tried running the power directly into the pins on the bottom of the board (bypassing the breakout). The documentation says to use MULTIPLE pins if powering directly, which made me leery. In the end I ended up using my bench power supply (an EVGA SuperNova 550 ATX power supply).

I did find several other power supplies that would work, but quickly ran into stability issues (Atomic Pi would simply lock up after running for a period of time). Once I had the power sorted out, I had no issues with locking up.

CMOS Battery

Since the Atomic Pi is basically just a small Intel computer, it has a CMOS battery. Mine was dead out of the box and resulted in a reset of the BIOS and clock every time I removed power. I couldn’t find one with a matching plug, so ended up splicing a new battery in.

eMMC

I was happy that the Atomic Pi came with a built-in eMMC. These aren’t typically super fast but are generally way faster than running from an SD card. The downside here is that my eMMC went belly up after a while and stopped being recognized in the BIOS. I followed all the instructions I found on the web and couldn’t get it back working again. Eventually I gave up and reverted to an SD card.

I suppose if I ever decide to use this device long term, I could connect an external USB to eMMC similar to what I do with the Raspberry Pi 4B. SD cards are just not fast enough to run a graphical interface. Headless systems might work well enough, but GUI’s will just slow the system to a crawl.

Overall (5/14)

Overall, I would say that the Atomic Pi performs poorly in most circumstances. There are a few use cases though that I think the Atomic Pi could really shine (particularly given the low price):

• If you MUST have x86 for software binary compatibility
• If you need to run Windows (NOTE: I didn’t test any GPIO / I2C or SPI under Windows)
• If you have a project that needs 3x UARTs and only a couple of GPIOs

Unless you fit in the use cases above, you could probably do better with another system. As I wrap up testing on a range of different platforms, I’ll add a page to compare and contrast the different systems available.

The post Atomic Pi Pros, but mostly Cons 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 Radxa Rock 5B for our sbc_gpio test require 1x I2C, 2x SPI, 1x UART and 2x IR (1 Tx and 1 Rx). All the configuration will need to be done directly in the /boot/config.txt file. Radxa does not have a tool similar to raspi-config on the Raspberry Pi.

For reference the IR receiver we are using is a TSOP38238 receiver diode. You can find them here: https://amzn.to/3PjZm0x. We are also using IR LED’s that you can find here: https://amzn.to/3XdDlCw

We are an Amazon affiliate and may receive some compensation from any products purchased. Affiliations and ads are how we can provide the content that we do!

NOTE: After any changes to the /boot/config.txt file, you MUST run "sudo update_extlinux.sh" to update the /boot/extlinux/extlinux.conf file. If you don’t run the update_extlinux.sh script the changes to the /boot/config.txt file won’t ever be applied.

I2C, SPI and UART Overlays

The I2C, SPI and UART overlays are easily configured using the /boot/config.txt file. The following lines will add overlays for I2C7, SPI0, SPI1 and UART2:

dtoverlay=rk3588-i2c7-m3
dtoverlay=rk3588-spi0-m2-cs0-spidev
dtoverlay=rk3588-spi1-m1-cs0-spidev
dtoverlay=rk3588-urat2-m0

NOTE: After any changes to the /boot/config.txt file, you MUST run "sudo update_extlinux.sh" to update the /boot/extlinux/extlinux.conf file. If you don’t run the update_extlinux.sh script the changes to the /boot/config.txt file won’t ever be applied.

This gets everything except the infrared quickly and easily. Of course IR is where we run into an issue…

Infrared Transmit and Receive

There are two issues with setting up IR on the Rock 5B:

1. The stock Radxa kernel (5.10.110) does not have any IR Tx or Rx modules compiled in it
2. There is no overlay for IR Tx or Rx compiled and available

Before we can run an infrared tests, we will need to fix both of these issues.

Compile the kernel with IR modules

First step is we need to recompile the kernel. Radxa has decent instructions available on their website: https://wiki.radxa.com/Rock5/guide/build-kernel-on-5b

I put in a merge request to the Radxa kernel to enable IR modules in future kernel builds (https://github.com/radxa/kernel/pull/128). Before you recompile the kernel, check to see if the module is included for the Tx and Rx bit-banging driver. Run the following commands:

sudo modinfo gpio-ir-tx

sudo modinfo gpio-ir-recv

The Radxa kernel build instructions from the guide above assumes that you are compiling on the Rock 5B itself. It you are intending to compile on a different system, there are more steps that need to be performed to setup cross platform compilation.

Here is a summary of the steps (from the Radxa guide):

Install Prerequisites

sudo apt-get update
 && sudo apt-get install -y git  device-tree-compiler libncurses5 libncurses5-dev build-essential libssl-dev mtools bc python dosfstools bison flex rsync u-boot-tools make

Clone the Source Code

mkdir ~/rk3588-sdk && cd ~/rk3588-sdk
git clone -b linux-5.10-gen-rkr3.4 https://github.com/radxa/kernel.git
git clone -b master https://github.com/radxa/rkbin.git
git clone -b debian https://github.com/radxa/build.git

You can of course clone to a different folder. The examples from Radxa will assume that all the code is in the ~/rk3588-sdk folder.

Update the Kernel Config

The next step is to update the kernel config to include the IR modules.

cd ~/rk3588-sdk/kernel
make rockchip_linux_defconfig
make menuconfig

This will load the text menu configuration utility for the kernel. On the main menu scroll down to the “Device Drivers” section and hit ENTER to select it (the —> at the end of the line indicates that there is a submenu).

On the Device Drivers page, scroll down until you reach “Remote Controller support”. The left column should show a “[ ]” which signifies that it is not currently included in the kernel. Hit “M” or SPACE until it changes to a “<M>”. Then hit ENTER to enter the “Remote Controller Support” sub-menu.

Here we need to enable the “LIRC user interface” by hitting the SPACEBAR. After this is set to “[*]”, move down to the “Remote Controller Decoders” and hit SPACE again. When the 1st column changes to “[*]” the submenu for the decoders will be activated. Just select them all by using the SPACE or “M” key. Use the right arrow key to select “EXIT” from the list of options at the bottom to go back up a menu.

Select “Remote Controller Devices” and hit SPACE. Once the 1st column changes to “[*]” hit enter to enter the menu. From here select at a minimum the “GPIO IR remote control” and “GPIO IR Bit Banging Transmitter”. I additionally added the “SPI connected IR LED” and “PWM IR transmitter” for future use.

Once the updates have been made, use the right arrow to move over to “Save” on the bottom list, and save the config as “.config” (this is the default config file).

Compile the Kernel and Install It

After you save, exit out of all the menus until you are back at the command line. Next run the following commands to prep the new configuration for the kernel build.

make savedefconfig
cp defconfig arch/arm64/configs/rockchip_linux_defconfig

Next (but not last), we need to build the kernel. This will take some time to complete:

cd ~/rk3588-sdk
./build/mk-kernel.sh rk3588-rock-5b

After you finish the kernel build, verify that the files are present:

$ ls out/kernel/
Image  rk3588-rock-5b.dtb

The last step is to convert your new kernel image into a “deb” package that you can install in Debian, Ubuntu, or any other Debian based system that you are running. You will need to add a release number that will be appended to the kernel. This will append a value after 5.10.110-” in the filename. For differentiation, the lastest build I have from Radxa’s APT repo is 37. I typically start at 1000 to make it easy to identify.

./build/pack-kernel.sh -d rockchip_linux_defconfig -r 1000

Once the pack-kernel script is complete, you will now have a series of packages ready to be installed:

$ ls out/packages/
linux-5.10.110-99-rockchip-g9fd61a9a9912_5.10.110-1000-rockchip_arm64.changes
linux-headers-5.10.110-99-rockchip-g9fd61a9a9912_5.10.110-1000-rockchip_arm64.deb
linux-image-5.10.110-99-rockchip-g9fd61a9a9912-dbg_5.10.110-1000-rockchip_arm64.deb
linux-image-5.10.110-99-rockchip-g9fd61a9a9912_5.10.110-1000-rockchip_arm64.deb
linux-libc-dev_5.10.110-1000-rockchip_arm64.deb

You will need to install the “image” and “headers” package. There are two packages named “linux-image”, you will only need the one that DOES NOT include the “-dbg” text. This copy of the kernel includes debugging components that I’m sure you won’t require if you are reading this post! Just install the images using “dpkg”:

sudo dpkg -i out/packages/linux-image-5.10.110-99-rockchip-g9fd61a9a9912_5.10.110-1000-rockchip_arm64.deb
sudo dpkg -i out/packages/linux-headers-5.10.110-99-rockchip-g9fd61a9a9912_5.10.110-1000-rockchip_arm64.deb

Check Your Kernel

If you check the /boot/extlinux/extlinux.conf file, you should see your new kernel build listed as the first image. Reboot and verify with uname -a! If you see your specific kernel build number then you are done and ready to move on to overlays!

Create the Overlays

First off, what is an overlay? For reference we are in fact refering to a Device Tree Overlay. A device tree overlay can performs two functions for us:

1st – The overlay is read during the boot process and is used to enable parts of the hardware that are not enabled by default. An example here is enabling the UART, SPI or I2C devices that we did previously. These use the same pins as regular GPIO’s and the hardware has to be told to enable the UART functions in the hardware chip.

2nd – The overlay associates a kernel driver with a hardware device. For the case of infrared, we need to tell the kernel what GPIO pin we want, how to configure that pin (i.e. pull up or down) and associate it with a driver.

Overlay Caveats to keep in mind

In order to run our IR tests, we will need to create 2 overlays, one for the transmit LED, and one for the receiver, but first a few notes:

• The overlay is in a DTS file, but all DTS files must be compiled to DTB or DTBO files for use during the boot process. (Think of this like a C file that needs to be compiled to a binary.)
• The compiled DTBO file needs to be accessible VERY early in the boot process, so they must all be located in the /boot dir.
• There are different mechanisms used by different vendors to load DTBO overlay files. The Rock 5B uses uboot and extlinux to apply device tree overlays and start the Linux kernel. With Raspberry Pi OS, the config.txt file is loaded and parsed to get overlay parameters (i.e. which GPIO to use). Uboot does not allow this, so this means we need to create a compiled DTBO file with the exact parameters (including GPIO pin).
• Radxa’s update_extlinush.sh file (remember you have to run this after /boot/config.txt changes) wipes and reloads the DTBO overlay files in the /boot/dtbs directory.

IR Rx Overlay

The IR Rx overlay will need to use the gpio-ir-recv driver we compiled into the kernel previously. We will also need to assign the GPIO pin we want to use. For our example we will be using pin 3A3 (gpio chip 3, pin 11). The TSOP38238 IR sensor is active low (as opposed to high), so we also need to let the kernel know this.

Here is the DTS file contents. We will need to save this file somewhere (doesn’t need to be on the boot partition) so we can compile it into a DTBO. For reference, we will use the name rk3588-ir-rx.dts for consistency with the other rk3588 overlays.

// Definitions for ir-gpio-recv module
/dts-v1/;
/plugin/;

#include "dt-bindings/gpio/gpio.h"

/ {

        fragment@0 {
                target-path = "/";
                __overlay__ {
                        gpio_ir_recv: gpio_ir_recv {
                                compatible = "gpio-ir-receiver";
                                status = "okay";
                                gpios = <&gpio3 11 GPIO_ACTIVE_LOW>;
                                pinctrl-names = "default";
                        };
                };
        };
};

Once we have the DTS file defined, we can compile it to a DTBO:

dtc -i dts -O dtb rk3588-ir-rx.dts rk3588-ir-rx.dtbo

IR Tx Overlay

The IR Tx overlay will need to use the gpio-ir-tx driver we compiled into the kernel previously. We will also need to assign the GPIO pin we want to use. For our example we will be using pin 3A2 (gpio chip 3, pin 10).

Here is the DTS file contents. We will need to save this file somewhere (doesn’t need to be on the boot partition) so we can compile it into a DTBO. For reference, we will use the name rk3588-ir-tx.dts for consistency with the other rk3588 overlays.

// Definitions for ir-gpio-tx module
/dts-v1/;
/plugin/;

/ {

        fragment@0 {
                target-path = "/";
                __overlay__ {
                        gpio_ir_tx {
                                compatible = "gpio-ir-tx";
                                status = "okay";
                                gpios = <&gpio3 10 0>;
                                pinctrl-names = "default";
                        };
                };
        };
};

Once we have the DTS file defined, we can compile it to a DTBO:

dtc -i dts -O dtb rk3588-ir-tx.dts rk3588-ir-tx.dtbo

Applying your Overlay at Boot

Now that we have our DTBO files, we need to configure the system to load them on boot. The update_extlinux.sh script clears all files in the /boot/dtbs folder and reloads from /usr/lib/linux-image-*** so we can’t put the files here. We will create a new folder for our DTBO files.

sudo mkdir /boot/custom_dtbs
sudo cp rk3588-ir-tx.dtbo /boot/custom_dtbs
sudo cp rk3588-ir-rx.dtbo /boot/custom_dtbs

This will put our DTBO files where the kernel can get them during the initialization process. The last step is adding theoverlays into the /boot/extlinux/extlinux.conf file. Here we need to add our overlays to the fdtoverlays line under the kernel. If the line already exists (like shown here with the uart7 overlay), just add a space and the new overlay. If there is no fdtoverlay line, add one after the devicetreedir and before the append lines.

NOTE: There will likely be multiple kernels listed. The system will boot the first so technically you only need to add to the fdtoverlay on the first kernel. For consistency with the update_extlinux.sh script though I add mine to all the kernels.

The path in the extlinux.conf file may appear odd. At this point only the boot partition is loaded, and it is loaded as the root partition. So make sure your path is “/custom_dtbs/…” and not “/boot/custom_dtbs/…”.

label kernel-5.10.110-2002-rockchip-g76d0450ea961
    kernel /vmlinuz-5.10.110-2002-rockchip-g76d0450ea961
    initrd /initrd.img-5.10.110-2002-rockchip-g76d0450ea961
    devicetreedir /dtbs/5.10.110-2002-rockchip-g76d0450ea961
    fdtoverlays  /dtbs/5.10.110-2002-rockchip-g76d0450ea961/rockchip/overlay/rk3588-uart7-m2.dtbo /custom_dtbs/rk3588-ir-tx.dtbo /custom_dtbs/rk3588-ir-rx.dtbo
    append   root=UUID=e29639d9-0c16-4501-8e64-50995cc715e5 earlycon=uart8250,mmio32,0xfeb50000 console=ttyFIQ0 console=tty1 consoleblank=0 loglevel=0 panic=10 rootwait rw init=/sbin/init rootfstype=ext4 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 irqchip.gicv3_pseudo_nmi=0 switolb=1 coherent_pool=2M

That it! Just reboot to load the overlays. You can confirm they are loaded by running dmesg | less and searching for “gpio-ir-” or “lirc”. (LIRC setup will be reflected in the sbc_gpio test since it is common setup for all systems.)

CAUTION!! We manually edited the /boot/extlinux/extlinux.conf file. The next time you run the udpate_extlinux.sh script your changes will be lost! This ALSO includes any kernel update that may be installed as this script is a triggered action.

I am working on some alternative methodsd that can help with this, but it isn’t ready for prime time yet.

Summary

What we saw here is that setting up the Rock 5B is easy as long as you are using one of the predefined overlays. Moving off the defined list of overlays into infrared we had to not only create our own overlay but also recompile the kernel to include the drivers we needed. I fully expect to run into similar issues with drivers based on how the kernel is configured. It appears that the decision was to minimize size rather than include the maximum number of modules.

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

The post Radxa Rock 5B Setup for sbc_gpio appeared first on Learning to Pi.

Why do we need swap?

If you browse the web you’ll find many different answers to this question. For a system running a single process, you probably don’t. Over the years I have deployed several Raspberry Pi Zero’s, 3B’s and 4B’s that have no swap enabled. These are all headless systems running just the python app that I wrote for that particular deployment. All of these systems are able to run for an extended period of time (months+) with no issues.

Once we start running graphical OS’s, desktop applications with web browsers, file browsing, etc the need for swap becomes clear. The kernel uses free memory as a file buffer which allows faster access for files that are commonly used. On my Rock 5B you can see how the memory has currently being used:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.5Gi       2.7Gi       3.2Gi       133Mi       1.8Gi       4.8Gi
Swap:          2.0Gi          0B       2.0Gi

Here we can see of 3.2GB of free RAM, but 4.8GB of available. Most of the difference here is due to the file buffer. We also can see that no data has been swapped at this time, and there is plenty of free memory even with the current buffer.

As we start to run more applications and open more files, the memory utilization will start to shift. Even though the kernel will free up space from the buffer when needed, without a swap I have run into application hangs long before I ran out of memory. In other instances during burn in tests I’ve had the system kill my application since it was considered the memory “hog”.

After running a few web browser windows, downloading some files and launching a couple of VSCode consoles, my memory usage now looks like this:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.5Gi       3.9Gi        55Mi       190Mi       3.9Gi       3.7Gi
Swap:          2.0Gi        84Mi       1.9Gi
 

Here you can see that the file buffer has shot up to 3.8GB, used RAM to 3.9GB, and free dropped to 55MB. You can also see some RAM has been swapped (albiet a small amount).

What is ZRAM?

ZRAM creates a virtual object (in memory) to hold paged data in a compressed format. While ZRAM does use some of your memory, on systems that have slow disk I/O (i.e. those using SD cards), this allows the system to take less frequently used memory pages and compress them.

In old kernel versions (i.e. 3.15 and earlier) it was required to run a ZRAM object per CPU core. This was due to the inability for multiple cores to access the same ZRAM device at the same time. If you search for ZRAM, you’ll probably find lots of examples of systems configured with both one ZRAM device for the system as well as those with a ZRAM device per CPU core.

Given that it is 2023, we will assume you are running a 5.x or 6.x Linux kernel and will configure with a single ZRAM device for simplicity. HOWEVER, a lot of the default scripts and tools still assume one device per core, so there may be some adjustments required to ensure proper operations.

You can read more about ZRAM here: https://www.kernel.org/doc/html/next/admin-guide/blockdev/zram.html

Raspberry Pi OS

The classic Raspberry Pi OS by default creates a swap file in /var sized at 100MB. The presense of SOME swap seems to alleviate most of the issues, however since most Raspberry Pi devices run off SD, there is a VERY LARGE performance hit to having the swap on flash.

The swap file is created by the dphys-swapfile service which configures the swap file on startup. Before we configure ZRAM, we first should disable the swapfile. This can be done by simply disabling the service (it will take effect on next boot).

sudo systemctl disable dphys-swapfile

After we disable the swapfile, the next step is to install the ZRAM tools:

sudo apt install zram-tools

The ZRAM configuration will all be done in /etc/defaults/zramswap file. The default configuration will all be commented. I will only edit the size value (configured in MB) to switch from 256MB to 2GB (my Pi4B is an 8GB model). Set the size appropriate for your device (i.e. a Pi Zero with 512MB of RAM I would set to 128MB).

#ALGO=lz4
#PERCENT=50
SIZE=2048
#PRIORITY=100

NOTE: The compression algorithm can be changed to increase the compression or decrease the CPU usage. I’ll leave the default here. You can identify what algorithms are supported by your kernel by running cat /sys/block/zram0/comp_algorithm after you have booted with your ZRAM.

Reload to apply your changes. At this point you should see 2GB of swap when you run free -h. If you don’t see your swap space, check the status of the zramswap service to see what caused the failure.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       141Mi       7.3Gi       1.0Mi       195Mi       7.4Gi
Swap:          2.0Gi          0B       2.0Gi
$ sudo systemctl status zramswap.service 
* zramswap.service - Linux zramswap setup
     Loaded: loaded (/lib/systemd/system/zramswap.service; enabled; vendor preset: enabled)
     Active: active (exited) since Fri 2023-06-16 14:08:33 MST; 20min ago
       Docs: man:zramswap(8)
    Process: 565 ExecStart=/usr/sbin/zramswap start (code=exited, status=0/SUCCESS)
   Main PID: 565 (code=exited, status=0/SUCCESS)
        CPU: 122ms

Jun 16 14:08:33 ... systemd[1]: Starting Linux zramswap setup...
Jun 16 14:08:33 ... root[575]: Starting Zram
Jun 16 14:08:33 ... zramswap[575]: <13>Jun 16 14:08:33 root: Starting Zram
Jun 16 14:08:33 ... zramswap[630]: Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
Jun 16 14:08:33 ... zramswap[630]: no label, UUID=142f8653-e64b-4985-9c89-c129397cea8a
Jun 16 14:08:33 ... systemd[1]: Finished Linux zramswap setup.
pi@rpi-kvm1:~ $ 

Ubuntu 23.04

I am currently running Ubuntu 23.04 on my Radxa Rock 5B, so I’ll use this as my example. First we need to make sure the ZRAM packages are installed:

sudo apt install zram-config zram-tools

After this is installed, then we can configure the /etc/defaults/zramswap just like we did with the Raspberry Pi. One difference though, my kernel didn’t have LZ4 support, so I needed to swap to LZO-RLE:

ALGO=lzo-rle
#PERCENT=50 
SIZE=2048 
#PRIORITY=100

After a reboot, we can check to see that the swap space was created. Check the status of the zramswap service to see what caused the error.

~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.5Gi       692Mi       6.1Gi        45Mi       846Mi       6.8Gi
Swap:          2.0Gi          0B       2.0Gi
$ sudo systemctl status zramswap.service 
● zramswap.service - Linux zramswap setup
     Loaded: loaded (/lib/systemd/system/zramswap.service; enabled; preset: enabled)
     Active: active (exited) since Fri 2023-06-16 14:21:15 MST; 9min ago
       Docs: man:zramswap(8)
    Process: 916 ExecStart=/usr/sbin/zramswap start (code=exited, status=0/SUCCESS)
   Main PID: 916 (code=exited, status=0/SUCCESS)
        CPU: 32ms

Jun 16 14:21:15 ... systemd[1]: Starting zramswap.service - Linux zramswap setup...
Jun 16 14:21:15 ... zramswap[923]: <13>Jun 16 14:21:15 root: Starting Zram
Jun 16 14:21:15 ... root[923]: Starting Zram
Jun 16 14:21:15 ... zramswap[936]: Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
Jun 16 14:21:15 ... zramswap[936]: no label, UUID=14f66260-16d7-4031-894c-59245d11f6be
Jun 16 14:21:15 ... systemd[1]: Finished zramswap.service - Linux zramswap setup.

Debian 11 (Bullseye)

Debian only has a single package to install. I’m using my Rock 5B for testing again, so no LZ4 compression available (this simply depends on the kernel).

sudo apt install zram-tools

The /etc/defaults/zramswap is configured the same way:

ALGO=lzo-rle 
#PERCENT=50  
SIZE=2048  
#PRIORITY=100

Summary

Don’t forget to add some type of swap space! For SBC’s ZRAM is ideal to prevent writing to the SD card for swap. Raspberry Pi OS defaults to using a swap file, so disabling this and enabling ZRAM is ideal. For Ubuntu or other Linux based distributions, be sure to install the ZRAM tools and configure the service. If you are experiencing slow performance and system hangs (in particular in a GUI), be sure to check your swap configuration before you go any further!

If you are looking for more info on the Radxa Rock 5B, check out related articles.

The post ZRAM for your SBC 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.

While working on my SBC comparison, in addition to building a new library to read DHT11/DHT22 sensors using the SPI bus, I had a hard time finding a working library to read BMP280/BME280 sensors using the SPI bus.  Most of the libraries utilized I2C, which in normal situations would be fine.  For this set of testing, I was specifically looking for a sensor using the SPI bus to verify connectivity on different platforms.  So, I kicked off a mini project to build a new library.

For those unsure on whether to use SPI or I2C for a given sensor, one feature of the SPI bus that makes me tend to prefer it is the lack of bus addressing.  Most I2C devices I’ve seen tend to come with pre-defined I2C bus addresses.  Some devices allow you to switch the address between two different options by setting a jumper (or soldering a pad).  What do you do if you need two or more of the same sensors connected to an SBC or microcontroller?  SPI does require more cabling but using the CS (chip select) to identify the intended sensor allows for more flexibility.  If the number of cables isn’t an issue, I’ll likely use SPI wherever possible.

Setting used by BME280/BMP280 sensors

Sensor Modes:

• Sleep Mode: Initial state after startup.  No sensor readings are running, all registers are accessible and consumes the lowest amount of power
• Forced Mode: Performs one measurement of enabled sensors and returns to sleep mode
• Normal Mode: Cycles between measuring enabled sensors and inactive periods between measurements

When a “forced” read is called, the sensor will simply take a single reading and store the result.  Once the reading has been taken, the raw data can be read from the register.  When in normal mode, reads can be performed at any time.  Any read in normal mode will return whatever current raw data is presently stored in the memory registers.  With IIR filtering that will mean averaged data, or when filtering is disabled, whatever reading was taken last.

IIR Filter (aka Oversampling)

The description of the IIR filter took some time to sort out.  When the IIR Filter is enabled, the “filtered” data holds an average of x number of readings.  In some areas, this is called oversampling.  The documentation refers to IIR filtering to “reduce the noise”.  The concept here is averaging out readings to minimize brief variations in pressure or temperature.  The humidity sensor does not use IIR Filtering.  The IIR filter is only applicable when in normal mode.  The filter also applies to BOTH the temperature and pressure sensor (there isn’t an independent filter setting for each).  The filter is cleared when the sensor is placed in normal mode.  After the filter is cleared, all future readings are averaged in.  The higher the filter number, the lower the impact a single reading will have on the “filtered” value.

IIR filtering supports the following values: 0 (off), 2, 4, 8, and 16. 

Sensor Resolution

The humidity sensor (BME280 only) always runs as a 16 bit ADC.  Pressure and temperature sensors default to 16 bit when the IIR Filter is disabled and can be set to 0 (disables the sensor), 1 (for 16 bit), 2 (for 17 bit) or 3 (for 18 bit).  When IIR Filtering is enabled, the pressure and temperature sensor run at a fixed 20 bit (higher resolution for averaged readings).

Standby Time

When running in normal mode, the BME280/BMP280 sensor will take readings on regular intervals.  In between each reading the sensor will sleep for the “standby” time before waking up and taking another reading.  When running in normal mode with the IIR filter enabled, the sensor will take readings and average the results into the stored result.  The datasheet for the BME280 and BMP280 disagree on the meaning of the standby time settings somewhat.  They agree on the sleep time for values 0-5 but differ on the meaning of 6 and 7.

Standby time supported values: 0 (0.5ms), 1 (62.5ms), 2 (125ms), 3 (250ms), 4 (500ms), 5 (1000ms), 6 (10ms in BME280 or 2000ms in BMP280), 7 (20ms in BME280 or 4000ms in BMP280).  I’m assuming that the values in the BME280 datasheet are in error and used the BMP280 values in my library.  If you want to be safe, stick with the 1 second interval or less.

How it Works

I named the library BMX280 because I wrote it to support both the BME280 and BMP280.  Both read temperature and air pressure, the BME adds a humidity sensor as well (for a premium price!).  Following the datasheets available from the manufacturer, it was clear that both sensors use the same set of registers and the same mechanism for sending and receiving data.

BME280 Datasheet: https://learningtopi.github.io/datasheets/bme280.pdf

BMP280 Datasheet: https://learningtopi.github.io/datasheets/bmp280.pdf

All registers on the BME280/BMP280 sensor support either a read or write operation.  Configuration registers can be read or written, other registers are read only.  With all this information, it was easy to create a Python library to read and write to the registers.  The most difficult part by far was figuring out the trimmer parameters and how to take the raw data and convert it to usable temp, humidity and pressure data.  I won’t go through all the details of the math.  I’ll just say that there are 3 registers for temperature, 9 for pressure and 6 for humidity.  The value in these registers holds calibration data that is burned into the chip from the factory and is REQUIRED to calculate the proper values.

Now that the structure is done, I may go on to add a background polling to keep a list of values polled while in normal mode.  I can also take the SPI setup and port to I2C since the registers are the same, only the medium is changed.

Please check out our module documentation page here: </////>

Also check out our SBC comparison project that this library was written for here: </////>

The post Python bmx280_spi appeared first on Learning to Pi.

NOTE:  The DHT22 operates the same as the DHT11.  There is a slightly different method required to read the binary data, however the data transfer is performed the same way.  Other than the method to convert the binary data to a number, all references to the DHT11 can be interchanged with a DHT22.

What Has Changed?

In later releases of the Linux kernel, how GPIO’s are accessed has moved away from direct “bit-banging” (the term widely used to reference directly accessing the GPIO registers) to API interfacing through the Linux kernel.  On one side this provides accounting of what applications are using which pin and helps prevent improper use.  On the other hand, it adds a layer between Python and the GPIO’s.

Reference: https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html

How does a DHT11 work?

The trusty old DHT11 uses a slightly unusual method of operation.  There is a single data pin that is used to trigger a read from the device (by pulling the data pin low for a minimum of 18 ms).  Most DHT11 devices have 3 pins on a small PCB.  The 3 pin model includes a pull-up resistor.  4 pin models without the PCB need to have an external pull-up resistor added.

After the DHT11 device is triggered by pulling the data pin to ground, the sensor starts transmitting binary data by pulling the data pin to ground and releasing.  Each bit is preceded by a 50us pull to ground followed by a 0 or 1 represented by leaving the data pin high for 26-28us for a 0, or 70us for a 1.

To read the data transmitted by the DHT11 sensor, the application must be able to read the difference between a high voltage held for 27us and 70us!  For reference 27us is 0.000027 seconds! Or .001 milliseconds!  This is an incredibly small slice of time!

The classic DHT11 library (https://pypi.org/project/dht11/) does this by simply reading the value from the data pin in a loop until it has recorded 100 concurrent values the same.  The loop (https://github.com/szazo/DHT11_Python/blob/master/dht11/__init__.py) is run without any delay added, so the data is collected as fast as the Python code can run.  Even at the best of times, this was only successful for me somewhere around 50% of the time.  The rest of the time the code wasn’t able to read the data quickly enough.  On a modern board with a modern kernel this seems to be even worse.  I found it rare to EVER get a successful read.  The issue comes down to the speed of switching from an output pin to an input pin, then reading the input rapidly enough to capture the high and low values.

Are all DHT11 or DHT22 sensors simply useless in modern kernel devices?  Are we stuck with either old out of date devices or upgrading to more expensive I2C or SPI temperature/humidity sensors?  I was determined to look for an alternative.

The Alternative for reading the DHT11 / DHT22!

After pondering the issue, I started to think about what other components on the typical SBC can read data quickly enough to measure the difference between a high voltage held for 27us or 70us.  After some quick conversion on unitjuggler.com (https://www.unitjuggler.com/convert-frequency-from-%C2%B5s(p)-to-Hz.html?val=27), I realized that 27us is just over 37kHz.  It occurred to me that the SPI bus is capable of running in the 100’s of Mhz range (depending on platform of course).  That makes the SPI bus hundreds of times more sensitive than needed to read the DHT11!

As an Amazon Associate I earn from qualifying purchases. Ads and associate programs is how we pay for our content. Using our associate links supports our site!

This solves the problem of how to READ the data coming from the sensor but introduces a new problem.  The SPI bus uses separate pins for CLK (used to sync the bus frequency to all devices), MISO (in from sensor), MOSI (out to sensor) and CS (used to signal to a sensor).  The DHT sensor uses the equivalent of the CS and MISO on the same data pin.

My solution was to split the load between two pins.  Read data on the MISO pin of the SPI bus but initiate the signal to the DHT11 to start transmitting its readings from another pin.  The question was how to do this?  My solution was to add a 470ohm resistor and a 2N5551 NPN transistor.

The “signal” pin is connected to the base of the NPN transistor via the 470ohm resistor (to prevent excessive current from being pulled through the signal pin).  The collector leg of the NPN is connected to ground, and the emitter to the data pin on the DHT11. 

When the NPN transistor is “energized” by setting the signal pin high, current is allowed to flow from the emitter to the collector which will draw the data pin on the DHT11 to ground.  As long as the signal pin is kept high, the DHT11 data pin will be pulled to ground.  Once the signal pin is set low again, the NPN transistor will allow the data pin to return to a high voltage provided by the pull-up resistor.

Step 1: Transistor is activated by output pin set to high causing the data pin on DHT11 to be pulled to ground (also the SPI MISO)

Step 2: Output pin is set back to low, DHT11 starts transmitting and data is received on SPI MISO port.

Now that we have triggered the DHT11 sensor to start sending its data, we can use the SPI bus to read the data.  Python has a library spidev (https://pypi.org/project/spidev/)  that can be used to set the bus frequency and read data from the bus.  Then it is simply a matter of counting how many 0 and 1 bits are received and factoring in the frequency of the SPI bus to determine how many sequential 1’s are needed to represent a 0 or 1 transmitted by the DHT sensor.

Conclusion

Bit-banging is getting more and more difficult.  That doesn’t however mean that there are no other (and better) ways to work with sensors like the DHT11.  Using the SPI bus to read the DHT11 sensor so far has given a 90+% success rate.  This is far better than the bit banging library even on the older kernels where 25-50% I considered successful.  There were projects I built that read the DHT11 3 times in a row in hopes that one of them would work.

Sometimes you need to find creative ways to perform tasks.  Feel free to leave a note in the comments if you make use of the dht11_spi library or create a similar library to work around the kernel GPIO limitations.

The post Python dht11_spi appeared first on Learning to Pi.