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.

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.

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.