Support for Raspberry Pi 5

[Puetz]

Hi,

I just got a Raspberry Pi 5 and am getting an error that my hardware revision is not supported.

Here is some hardware information from cat /proc/cpuinfo:

Hardware	: BCM2835
Revision	: c04170
Model		: Raspberry Pi 5 Model B Rev 1.0

I also ran this coding to get paddr=10, baddr=C0000000.

I hope someone can use this information to add a new hardware type and support for the Raspberry Pie 5 🙂
I unfortunately don't know C and have no clue about hardware, so I can't create a PR myself.

Best regards,
Thomas

[Gadgetoid]

The Pi 5 has significant hardware changes that might make some of this library difficult or impossible to migrate. I’m not qualified to know exactly how bad it is, but the changes are significant enough that a straight hardware ID addition isn’t going to cut it. We need one of the wizards involved in writing or extending the core functionality of rp_ws281x to step in and give us the lowdown.

I’ve talked to folks at Pi about creating a PIO-backed WS281X library for RP1, but there’s no telling when it if that - or the tools to make it happen - will materialise.

[jgarff]

I've definitely been wanting to add support for that, if possible. Unfortunately, I don't yet have a RPi 5 to actually work on. Jeremy

…

On Sat, Nov 4, 2023 at 5:14 AM Thomas Pötz ***@***.***> wrote: Hi, I just got a Raspberry Pi 5 and am getting an error that my hardware revision is not supported. Can someone please add support for the Raspberry Pi 5 or give me a guideline on how to do it myself? I'd greatly appreciate it. Best regards, Thomas — Reply to this email directly, view it on GitHub <#528>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB55G3XJNYO3S4VOUTRPTTYCYPQ3AVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TOMRYGY2TANQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Gadgetoid]

I've definitely been wanting to add support for that, if possible.

Wow, of all the things I expected- it wasn't the big guns! I hope you're well.

Unfortunately, I don't yet have a RPi 5 to actually work on.

That's something I can probably fix if you want to give support a shot!

[jgarff]

Hi Phillip! I'm good, thanks! I'm on a waiting list to get a RPi 5, but I have no idea when it'll ship. I'm definitely willing to give support a shot. Sounds kinda fun. Any help you can offer is greatly appreciated!

…

On Mon, Nov 6, 2023 at 6:16 AM Philip Howard ***@***.***> wrote: I've definitely been wanting to add support for that, if possible. Wow, of all the things I expected- it wasn't the big guns! I hope you're well. Unfortunately, I don't yet have a RPi 5 to actually work on. That's something I can probably fix if you want to give support a shot! — Reply to this email directly, view it on GitHub <#528 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB55GY2FJAJXYR2DBDML4DYDDPJFAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJUHAYDIOJSHA> . You are receiving this because you commented.Message ID: ***@***.***>

[zytegalaxy]

@jgarff If you are in Us/Canada, I can send you a RPi5 to support the port and any other way I can support this. I am getting a similar issue:

raise RuntimeError(
RuntimeError: ws2811_init failed with code -3 (Hardware revision is not supported)

[ebraraktas]

Hi @jgarff , I tried to add HW spec and debug the library (with main.c after some modification for my led strip). I added the spec below:

    //
    // Raspberry Pi 5
    //
    {
        .hwver = 0xc04170,
        .type = RPI_HWVER_TYPE_PI5,
        .periph_base = PERIPH_BASE_RPI4,
        .videocore_base = VIDEOCORE_BASE_RPI2,
        .desc = "Pi 5 Model B - 4GB 1.0"
    },

where RPI_HWVER_TYPE_PI5 is defined as 4. And it failed to allocate memory in the lines below:

rpi_ws281x/ws2811.c

Lines 939 to 940 in 1f47b59

	device->mbox.mem_ref = mem_alloc(device->mbox.handle, device->mbox.size, PAGE_SIZE,
	rpi_hw->videocore_base == 0x40000000 ? 0xC : 0x4);

here is the dmesg output for that request:

[ 1884.471030] raspberrypi-firmware soc:firmware: Request 0x0003000c returned status 0x80000001

And ioctl errno corresponds to Invalid argument.

I know nothing about RPi (this is my first device) and mailboxes etc. but I tried to run a simpler code (info.c) in this library to identify the issue, and here is the output (I added Cannot get ... logs after failure):

root@raspberrypi:/home/ebraraktas/Projects/mailbox# ./build/test/info 
Firmware revision: Oct 18 2023 17:30:17
/home/ebraraktas/Projects/mailbox/src/fd.c:52:mailbox_property: error: ioctl: IOCTL_MBOX_PROPERTY: Invalid argument
Cannot get board model
/home/ebraraktas/Projects/mailbox/src/fd.c:52:mailbox_property: error: ioctl: IOCTL_MBOX_PROPERTY: Invalid argument
Cannot get board revision
/home/ebraraktas/Projects/mailbox/src/fd.c:52:mailbox_property: error: ioctl: IOCTL_MBOX_PROPERTY: Invalid argument
Cannot get mac address
Board serial: 0xc77d11596528bd61
ARM memory: 0x3f800000 bytes at 0x00000000
VC memory:  0x02100000 bytes at 0xfdb00000

And memflag.c(link) failed to allocate memory with the same errno, too.

I don't know if any of these helps to diagnose the issue, but I wanted to post my findings. If this issue seems to be resolved quickly, I would like to help it (but it seems way beyond my knowledge).

[jgarff]

That would be fantastic! I'm hoping to get a little time over the holidays to work on this a bit.

…

On Wed, Nov 8, 2023 at 11:22 AM Ubo Project ***@***.***> wrote: @jgarff <https://github.com/jgarff> If you are in Us/Canada, I can send you a RPi5 to support the port and any other way I can support this. I am getting a similar issue: raise RuntimeError( RuntimeError: ws2811_init failed with code -3 (Hardware revision is not supported) — Reply to this email directly, view it on GitHub <#528 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB55G6US4J3ASQFP2KZOY3YDPEX5AVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBSGQZDENRWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zytegalaxy]

Do you mind sending me an email to [email protected] so that I can arrange to have one shipped to you?

[jgarff]

I've now got hardware to play with. Many many thanks to @ubopod for the very generous donation! I've started looking into it, and have found the following so far:

• Changing the hardware device ID is unfortunately insufficient to add support.
• Using mailbox messages to allocate DMA coherent memory that we can access from userspace doesn't work apparently. I'm investigating, but this is likely due to API changes when communicating with the Videocore VII firmware (new in the RPi5). I could write a small kernel driver to map this type of memory to userspace, but I'm hoping to not have to do that.
• The GPIOs now run through the new RPi5 RP1 chipset. Because of this they are not compatible with the previous PWM IP in the Broadcom SoC. Although, the RP1 has a neat IP that we can use instead. I'm looking into using the PIO controller in the RP1 along with DMA. I just need to get a cache free userspace buffer to work from.

I'll keep you guys posted with updates. Please be patient though, as I'm fairly busy, but hoping to work more on this over the holidays.

[jgarff]

Just a quick update.

• I figured out how to get uncached memory from userspace without using the videocore mechanism. This should actually work for all versions of the raspberry pi with newer kernels, and it's much cleaner, so I'm going to rip out the mailbox interface and replace it globally. Once this is done I'll start on the RP1 DMA/PIO.

[mbevand]

I was playing for a few hours with attempting (unsuccessfully) a port to work on the Pi 5.

I can confirm that most of the videocore firmware mailbox interfaces have been ripped out (https://forums.raspberrypi.com/viewtopic.php?t=359477) so definitely you need to drop that whole mechanism.

Another thing is the peripheral base address is now 0x107c000000 (instead of 0xfe000000 as on the Pi 4). I believe the new RP1 DMA/PIO will have to be configured through registers in that space, and because it's a base address over the 32-bit limit, you may need to #define _FILE_OFFSET_BITS 64 so that you can access it through /dev/mem

[jgarff]

Thanks @mbevand for the info. Since the RP1 is connected via PCIe, doesn't the base of the registers land in a PCIe BAR?

Region 0: Memory at 1f00410000 (32-bit, non-prefetchable) [size=16K]
Region 1: Memory at 1f00000000 (32-bit, non-prefetchable) [virtual] [size=4M]
Region 2: Memory at 1f00400000 (32-bit, non-prefetchable) [size=64K]

Are they remapping that somewhere else (0x107c000000?) in the rp1 driver?

[mbevand]

It doesn't conflict. Because the mapping goes from 0x107c000000 to 0x1080000000 while the BARs are much higher after 0x1f00000000

Per my understanding the mapping at 0x107c000000 is defined on line 90 here (the 64-bit value is represented as two 32-bit values "0x10 0x7c000000"): https://github.com/raspberrypi/linux/blob/29cc35f986a4e1e8671e68d0e363af636be243a2/arch/arm/boot/dts/bcm2712.dtsi#L90

[jgarff]

I'm not worried about a conflict. What I'm suggesting is that the peripherals that are built into the bcm2712 (dma/pcm/pwm/etc.) are no longer being used on the Pi5.

Instead the GPIOs are now wired to the RP1, not the SoC. The RP1 in turn is available to the SoC over PCIe, with all the registers mapped inside a RP1 BAR. Basically we can't use the peripherals in the 2712 anymore as they aren't wired to the actual pins anymore.

Seeing a schematic would be nice though. :)

[mbevand]

Doh! I wasn't thinking straight. You are right, of course. The register region at 0x107c000000 is useless to us. As you say, the RP1 PWM registers should be mapped inside a BAR region...

[jgarff]

No worries. I wish you were right. This would be much easier if the pins were still connected to the SoC IP.

[mbevand]

I don't know if that's useful or if you already know it, but the BAR can be accessed through sysfs. I wrote this sample code that shows how to read the FIFO_CTRL register of PWM0 on RP1. On my Pi 5 it prints FIFO_CTRL: 20000 since that's the default value of this register, as per page 39 of https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf . The RP1 is always at PCI address 0000:01:00.0, and the BAR region with the register is always resource1 so to access it:

#include <sys/ioctl.h>
#include <sys/mman.h>
#include <assert.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

#define OFFSET_PWM0 0x98000
#define OFFSET_PWM1 0x9c000

#define PWM_GLOBAL_CTRL 0x00
#define PWM_FIFO_CTRL   0x04

uint32_t my_read(void *base, ssize_t count, uint32_t offset)
{   
   assert(count == 4);
   return *(uint32_t *)((uint8_t *)base + offset);
}

int main() {
   const char *fname = "/sys/bus/pci/devices/0000:01:00.0/resource1";
   void *base;
   int fd;
   uint32_t reg;

   if (-1 == (fd = open(fname, O_RDWR | O_SYNC)))
       perror("open"), exit(1);
   // 0x400000 is the size in bytes of the "resource1" sysfs file
   base = mmap(NULL, 0x400000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
   if (base == MAP_FAILED)
       perror("mmap"), exit(1);
   if (-1 == close(fd))
       perror("close"), exit(1);
   reg = my_read(base, 4, OFFSET_PWM0 + PWM_FIFO_CTRL);
   printf("FIFO_CTRL: %x\n", reg);
   return 0;
}

[jgarff]

Thanks. I'm well aware of these mechanisms. The tricky part isn't register access. It's the dma.

…

On Tue, Dec 5, 2023, 5:48 PM mbevand ***@***.***> wrote: I don't know if that's useful or if you already know it, but the BAR can be accessed through sysfs. I wrote this sample code that shows how to read the FIFO_CTRL register of PWM0 on RP1. On my Pi 5 it prints FIFO_CTRL: 20000 since that's the default value of this register, as per page 39 of https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf : #include <sys/ioctl.h> #include <sys/mman.h> #include <assert.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <stdint.h> #define OFFSET_PWM0 0x98000 #define OFFSET_PWM1 0x9c000 #define PWM_GLOBAL_CTRL 0x00 #define PWM_FIFO_CTRL 0x04 uint32_t my_read(void *base, ssize_t count, uint32_t offset) { assert(count == 4); return *(uint32_t *)((uint8_t *)base + offset); } int main() { const char *fname = "/sys/bus/pci/devices/0000:01:00.0/resource1"; void *base; int fd; uint32_t reg; if (-1 == (fd = open(fname, O_RDWR))) perror("open"), exit(1); base = mmap(NULL, 0x400000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (base == MAP_FAILED) perror("mmap"), exit(1); if (-1 == close(fd)) perror("close"), exit(1); reg = my_read(base, 4, OFFSET_PWM0 + PWM_FIFO_CTRL); printf("FIFO_CTRL: %x\n", reg); return 0; } — Reply to this email directly, view it on GitHub <#528 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB55G3QZE22TIHHP7R34DTYH66GVAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRHA4TEMRYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[O-O-O-84]

Hey guys, i've got the same issue. is there already a solution? Maybe an update for the RPI_WS281x?

[ikke01]

I've now got hardware to play with. Many many thanks to @ubopod for the very generous donation! I've started looking into it, and have found the following so far:

• Changing the hardware device ID is unfortunately insufficient to add support.
• Using mailbox messages to allocate DMA coherent memory that we can access from userspace doesn't work apparently. I'm investigating, but this is likely due to API changes when communicating with the Videocore VII firmware (new in the RPi5). I could write a small kernel driver to map this type of memory to userspace, but I'm hoping to not have to do that.
• The GPIOs now run through the new RPi5 RP1 chipset. Because of this they are not compatible with the previous PWM IP in the Broadcom SoC. Although, the RP1 has a neat IP that we can use instead. I'm looking into using the PIO controller in the RP1 along with DMA. I just need to get a cache free userspace buffer to work from.

I'll keep you guys posted with updates. Please be patient though, as I'm fairly busy, but hoping to work more on this over the holidays.

Hallo Jeremy, did you make any progress on this for the PI5, we are looking forward to it if you can fix it to get it working again. Thanks Raymond

[jgarff]

Hi Raymond, I was able to work on this some over the holidays. I have some open questions in a developer forum regarding the DMA that I'm hoping can be answered. Unfortunately, the specs available thus far are lacking in specific functionality of the RP1. Some of which are tied up behind non-public specifications for intellectual property from third parties used in the RP1.

[ikke01]

Thank you for your fast response, let hope they respond, this makes the use of the pins not very usefull anymore if the cannot be addressed as in the PI4 and older versions. Raymond From: Jeremy Garff ***@***.***> Sent: Tuesday, 2 January 2024 17:18 To: jgarff/rpi_ws281x ***@***.***> Cc: Raymond Garnier ***@***.***>; Manual ***@***.***> Subject: Re: [jgarff/rpi_ws281x] Support for Raspberry Pi 5 (Issue #528) Hi Raymond, I was able to work on this some over the holidays. I have some open questions in a developer forum regarding the DMA that I'm hoping can be answered. Unfortunately, the specs available thus far are lacking in specific functionality of the RP1. Some of which are tied up behind non-public specifications for intellectual property from third parties used in the RP1. — Reply to this email directly, view it on GitHub<#528 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEFBLSKPAHWAAME4OIUC74TYMQXLDAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGIZTQMBVHE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[mehrdadfeller]

@jgarff Thanks again for the efforts! I hope the necessary information come out soon. If you link to relevant developer forum questions here, we can collectively try to get that information for Raspberry Pi. I have a few contacts in the commercial side and can also ask around to get more attention to it.

[jgarff]

That would be great @mehrdadfeller. The specific questions I have are as follows:

• Need to get access to the synopsys DMA controller documentation.
• Need to get the channel mappings for each peripheral (PWM/PIO/etc.) as it relates to the DMA. These are typically used for things like flow control/backpressure/etc. This is how the DMA controller knows that the given channel FIFO is full and whatnot. It's hard to know the specifics without the DMA docs though.
• There is a linux synopsys DMA driver in the kernel. I've gone through some of the code. I may end up having to write a kernel driver for this though if I want to use the same driver, but still need the mapping info.
• I'm also curious as to how they are using platform drivers inside a PCIe device, which typically uses a pcie driver. Auto detection and loading kernel modules, or how platform drivers can live in pcie devices from a device tree point of view. I've hacked this before myself on other projects I've done with PCIe connected FPGAs, but curious as to how they are handling the kernel module dependencies and such.

[ikke01]

Hallo jeremy Would this be a possible workaround , would this be working with you solution. https://www.hackster.io/nickbild/add-python-programmable-gpio-pins-to-any-computer-3b0259 Thanks Raymond Sent from Outlook for Android<https://aka.ms/AAb9ysg>

________________________________ From: Jeremy Garff ***@***.***> Sent: Thursday, January 18, 2024 12:33:43 AM To: jgarff/rpi_ws281x ***@***.***> Cc: Raymond Garnier ***@***.***>; Manual ***@***.***> Subject: Re: [jgarff/rpi_ws281x] Support for Raspberry Pi 5 (Issue #528) Unfortunately no. Setting any color at all requires transferring a complicated sequence of signals over the wire. The timing required for these signals isn't possible from a software only implementation on Linux due to context switches, driver interrupts, etc..

On Wed, Jan 17, 2024 at 4:25 PM felixfeliciz ***@***.***> wrote: Until then, is there any way to use the WS2812B with a limited range of functions, such as simple switching on and off or simple color changes without fancy gradients or animations? — Reply to this email directly, view it on GitHub <#528 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB55G4J56P375UBL3ZOGW3YPBMXZAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGQZDGOBXGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub<#528 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEFBLSLYJAXHTZBCHMIOPF3YPBNVPAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGQ3DCMJTGA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hannescam]

Hallo jeremy Would this be a possible workaround , would this be working with you solution. https://www.hackster.io/nickbild/add-python-programmable-gpio-pins-to-any-computer-3b0259 Thanks Raymond Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
________________________________ From: Jeremy Garff @.> Sent: Thursday, January 18, 2024 12:33:43 AM To: jgarff/rpi_ws281x @.> Cc: Raymond Garnier @.>; Manual @.> Subject: Re: [jgarff/rpi_ws281x] Support for Raspberry Pi 5 (Issue #528) Unfortunately no. Setting any color at all requires transferring a complicated sequence of signals over the wire. The timing required for these signals isn't possible from a software only implementation on Linux due to context switches, driver interrupts, etc..
On Wed, Jan 17, 2024 at 4:25 PM felixfeliciz @.> wrote: Until then, is there any way to use the WS2812B with a limited range of functions, such as simple switching on and off or simple color changes without fancy gradients or animations? — Reply to this email directly, view it on GitHub <#528 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB55G4J56P375UBL3ZOGW3YPBMXZAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGQZDGOBXGE . You are receiving this because you were mentioned.Message ID: @.>
— Reply to this email directly, view it on GitHub<#528 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEFBLSLYJAXHTZBCHMIOPF3YPBNVPAVCNFSM6AAAAAA65QFT3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGQ3DCMJTGA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Yes and no:
You will need to rewrite the SPI or PWM function for the library to work with the USB GPIO expander (try to find one with a fast SPI interface)

[Gadgetoid]

I am begging people just to use a microcontroller 😭

The RP2040 has enough RAM to double buffer 34,000 pixels and you can make up any USB, UART, SPI or I2C protocol you want to talk to it.

[MoffKalast]

I am begging people just to use a microcontroller

Okay sure, then we can also use something else like a N100 with UART. Why keep using the Pi if the GPIO header is just there as decoration amirite? I paid for the whole Pi and I'm gonna use the whole Pi 😃

[androdev88]

The RP2040 has enough RAM to double buffer 34,000 pixels and you can make up any USB, UART, SPI or I2C protocol you want to talk to it.

you are unlikely to be anywhere near driving this many pixels from RP2040, the data rate needed at 30 FPS is 3MB/s, SPI slave is max 10MHz, USB speed is in 800-900 kB/s range.

[Jezorko]

Since this library is still not updated, and I couldn't find a single working solution, I used praktronic's code mentioned in this comment to try and drive my WS281b strip with SPI.

https://github.com/Jezorko/rpi5-ws2812x-fu/releases/tag/testing_10MHz - here is a working example. If you build and run as root, while your strip is plugged to GPIO 10 (MOSI), it should work. The repository is a mess but then again, it's only a temporary hack until any one of the libraries gets updated. glhf

[hannescam]

Since this library is still not updated, and I couldn't find a single working solution, I used praktronic's code mentioned in this comment to try and drive my WS281b strip with SPI.

https://github.com/Jezorko/rpi5-ws2812x-fu/releases/tag/testing_10MHz - here is a working example. If you build and run as root, while your strip is plugged to GPIO 10 (MOSI), it should work. The repository is a mess but then again, it's only a temporary hack until any one of the libraries gets updated. glhf

I have also made a generic SPI neopixel library that is tested against the Pi 5 and it is also pretty generic so it would work on any computer with an spidev: https://github.com/hannescam/NeoSPI

[ddeliopoulos]

@Jezorko Thank you for your service 🖖

[vasylenkoserhii]

Since this library is still not updated, and I couldn't find a single working solution, I used praktronic's code mentioned in this comment to try and drive my WS281b strip with SPI.

https://github.com/Jezorko/rpi5-ws2812x-fu/releases/tag/testing_10MHz - here is a working example. If you build and run as root, while your strip is plugged to GPIO 10 (MOSI), it should work. The repository is a mess but then again, it's only a temporary hack until any one of the libraries gets updated. glhf

Thanks for your work - this code work to some extent.
I've found that bits order in lookup_table is opposite to correct one, so when one tried to increase one value say RED from 0 to 255 it will not produce smooth color increase. Changing data sending loop to something like this in rp1-spi.c fixes the issue:

    for (int data_byte = 0; data_byte < data_length; ++data_byte) {
      for(int bit_num = 7; bit_num >= 0; bit_num--) { 
        for (int bits_byte = 0; bits_byte < 2; ++bits_byte) {
            // put the data into the fifo 
            *(volatile uint8_t *)(spi->regbase + DW_SPI_DR) = lookup_table[data[data_byte]][bit_num*2+bits_byte];
            // we now need to pull exactly one byte out of the fifo which would
            // have been clocked in when we wrote the data
            /*uint8_t discard = */*(volatile uint8_t *)(spi->regbase + DW_SPI_DR);
        }
      }
    } 

Unfortunately I also see periodically it sporadically set some unexpected colors. It looks like flickering when colors changed constantly.

[JustBKen]

Any Updates on PWM support?

[mehrdadfeller]

Sadly, the PIO IP in the RP1 doesn't allow for direct access from Linux, and is instead only controllable through the RP1 Cortex-M's. While that is the best long term goal, it's far more complicated, especially in an easily deployable library. In the short term I've written a kernel driver using PWM instead. It's not quite done, but I'm getting closer. I got some waveforms on my scope last night.

Unfortunately, the PWM won't be able to control 10 separate strips at the same time. The RP1 has 2 PWM instances, but one is dedicated to fan control, leaving us with only one 4 channel PWM. In this case 4 strips would be the max.

@jgarff this sounds quite promising. Would you be able to share the existing code base even though still being work in progress and incomplete? I think it can help others jump into it and contribute.

[Jezorko]

@vasylenkoserhii I think the strip I am using has a different bit ordering from yours... ideally, to accomodate possible strip models, a library would offer a configuration of:

1. LED strip frequency 400Hz and 800Hz
2. endianness
3. color order (RGB / GRB / white component)
4. … probably a ton of other things that I'm not even aware of

[vanshksingh]

I will probably contribute to this repo too , but i just wrote an RPi5 specific lib for now pi5neo

[muningis]

@vanshksingh FYI - the link is broken (it leads to /issues/ of this repo)

[vanshksingh]

@muningis thank you ! I fixed it , it seems you have to affix the link to an word for it work sensibly

[c0bra-dev]

Hi everyone! For a small project I needed a single WS2812B LED running off a standard GPIO on a Raspberry PI 5 with the RP1 chip and I ended up writing some C++ code to do so.

I was able to successfully pull it off by using some timers and the WiringPi library.

I had to edit the timers with an oscilloscope, and discovered there is a sort of wake up time for the RP1 of about 3.5 us, after wich timings are quite accurate. After compensating I was left with a quick and dirty solution to my problem.

I dont expect this to be able to run any kind of large matrix, but if anybody finds it useful, this is the link to my repo with the code:

https://github.com/c0bra-dev/TIMED2812

[zytegalaxy]

@c0bra-dev this is awesome! have you had a chance to try this with more than a single LED? From my understanding, the WS2812B LEDs can tolerate +/-150ns which is quite a wide range compared to the absolute 800ns/400ns pulse width.

I also have a question about your oscilloscope measurement. In your code, you set the T1H value to 680ns. What value does that give you on oscilloscope? 800ns? Is there a linear relationship between timer value and observed value, meaning if you increase T1H by 20ns, does that really increase pulse width by 20ns? Does the load on CPU impact the timings?

#define T1H 680 // Ideal time 800

[c0bra-dev]

@zytegalaxy Thanks!
Yes, 680ns on the timer is around 800 ns measured on my oscilloscope.
I think there is a fixed value difference of around 100ns between the timer and the real IO operation. It seems linear and it's unexpectedly accurate, so much that I am impressed.
For instance on the 400ns i think we have something like +-10ns jitter over 10 different measurment regardless of CPU load (tried running stress --cpu 4)

Wake up times seems random, probably related to both CPU load and RP1 load, and makes the first bit timings unreliable. I edited the code to wake up the RP1 using a very small pulse (20ns) before the start of the sequence and then wait for a reasonable time before starting the sequence, With this edit now also the first bit works like a charme. This init pulse is so fast it gets ignored by the WS2812, and allows to make sure RP1 is responsive to the real sequence. Just tried with 24 LEDS and it's working like a charm.

I update the repo with the revisited code.

[SvOlli]

I just did a short run trying it on the "Waveshare True Color RGB LED pHAT 4x8" (8x4 LED matrix in zero form factor). The transmit looped was just wrapped with another loop that does send 32 times the same data. It's working like 80% of the time. My guess is process scheduling breaks the timing. However, now that it's working to some extend, I can offer to run different tests.

[c0bra-dev]

@SvOlli can you please double check my work on the edited code? I think the problem you are encountering is with the way I used to handle the first bit

[SvOlli]

Already on it. I found a glitch and managed to make it more visible, by changing the line 71 to:
color_matrix[i] = colorWheel((colorPos + (i * 256 / LED_NUMBER)) & 255) & 0x070707;
This way I could see that there's a bright white flash once in a while. This problem can be intensified by running 7z b in another terminal (7z benchmark). So there's still the scheduler interrupting the transfer every once in a while.

[c0bra-dev]

What about moving the code to a LKM?
I might work on it on the next days if you think it's a good idea.

[SvOlli]

@c0bra-dev : if you've got something, I can test it.

[zytegalaxy]

@c0bra-dev Beautiful! I tested it with 27 LEDs on pin GPIO12 and it works well.

no-stress.mp4

However, under stress as @SvOlli also suggested, the timings change a bit and introduce white flickers as you can see in video below:

test@ubo-3w:~ $ stress --cpu 8 --io 4 --vm 4 --vm-bytes 1024M --timeout 10s

stress-test.mp4

I investigated making a LKM, but the issue is that we cannot use WiringPi anymore and we have use linux libraries and directly drive GPIOs with registers etc which I have not done before. Perhaps @jgarff can give us some guidance on that.

[zytegalaxy]

@c0bra-dev I investigated the stress scenarios further and seems like cpu and io stress do not impact the led patterns but memory parameter --vm does. So If I do:

stress --cpu 4 --io 4

no visible effect on LED patterns can be seem. But if I add --vm, then I see the white flicker:

stress --cpu 4 --io 4 --vm 1

[c0bra-dev]

I investigated further by adding priority to the process, and went as far as having an isolated core dedicated to the program but the problem persist. Oscilloscope shows huge jitter.

LKM is probably the only way.