Support for Raspberry Pi 5 about rpi_ws281x HOT 82 OPEN

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.

from rpi_ws281x.

from rpi_ws281x.

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.

from rpi_ws281x.

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.

from rpi_ws281x.

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 😃

from rpi_ws281x.

from rpi_ws281x.

Hi , I'm following this issue. First of all , big thanks to @jgarff for working on this issue. Secondly , I saw this product from Adafruit - https://learn.adafruit.com/adafruit-neodriver-i2c-to-neopixel-driver?view=all that seemingly should allow NeoPixel to run on devices and microcontrollers which does not support it. Maybe I don't understand all the technical details , but someone can verify it can work on the RPi 5 until the current issue gets resolved? Thanks.

I'm using this on a Raspberry Pi 5 currently, so I can confirm it does work.
https://www.makerforge.tech/posts/pi5-build-log-4/#neopixel-i2c-support

from rpi_ws281x.

@jgarff having a second look at the rp1 datasheet, the PWM block has a serializer mode, like the bcm SoC's

so it should just be a matter of rigging up dma to feed duty-cycles to the pwm controller and putting it in serializer mode
the pwm dreq channel is in include/dt-bindings/mfd/rp1.h along with all of the other dreq's

from rpi_ws281x.

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.

from rpi_ws281x.

from rpi_ws281x.

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

from rpi_ws281x.

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.

from rpi_ws281x.

Hi , I'm following this issue. First of all , big thanks to @jgarff for working on this issue. Secondly , I saw this product from Adafruit - https://learn.adafruit.com/adafruit-neodriver-i2c-to-neopixel-driver?view=all that seemingly should allow NeoPixel to run on devices and microcontrollers which does not support it. Maybe I don't understand all the technical details , but someone can verify it can work on the RPi 5 until the current issue gets resolved? Thanks.

I'm using this on a Raspberry Pi 5 currently, so I can confirm it does work. https://www.makerforge.tech/posts/pi5-build-log-4/#neopixel-i2c-support

Hi! My bad, I installed not as sudo. Could you please provide your script for test?

The sample code in Guy's link works for me - I have a more complex implementation but that isn't needed for the basic functionality.

Would still be great to see this repo working on the Pi 5 as the i2c module is a bit of a workaround for the issue for me.

from rpi_ws281x.

the specs available thus far are lacking in specific functionality of the RP1

It's not much use in the near term, but I am discussing (with Pi) the feasibility of WS281x support, or perhaps some userspace tools and interfaces to make it possible, that leverages the RP1's PIO. It's not a "no", but more a "this will be complicated and requires some thought and a fair bit of work."

I remain optimistic, since there's a desire to show off the RP1's PIO, that the Pi 5 will be able to support WS281x strips on arbitrary pins using a simple PIO program and the same DMA-a-bunch-of-carefully-crafted-bytes trick we use currently. This could potentially even extend to custom PIO code to emit the correct pulses for 1s/0s, but right now I can only really speculate based on a few brief discussions of our requirements.

Sorry I didn't get a Pi 5 out to you quickly- I am absolutely mired in getting everything else to work!

from rpi_ws281x.

the specs available thus far are lacking in specific functionality of the RP1

It's not much use in the near term, but I am discussing (with Pi) the feasibility of WS281x support, or perhaps some userspace tools and interfaces to make it possible, that leverages the RP1's PIO. It's not a "no", but more a "this will be complicated and requires some thought and a fair bit of work."

I remain optimistic, since there's a desire to show off the RP1's PIO, that the Pi 5 will be able to support WS281x strips on arbitrary pins using a simple PIO program and the same DMA-a-bunch-of-carefully-crafted-bytes trick we use currently. This could potentially even extend to custom PIO code to emit the correct pulses for 1s/0s, but right now I can only really speculate based on a few brief discussions of our requirements.

Sorry I didn't get a Pi 5 out to you quickly- I am absolutely mired in getting everything else to work!

Thanks Gadgetoid! I was planning on actually using the new PIO to do this as it will be more flexible, allow for more GPIO ports, and sounds fun anyway. We can also leverage some of the microcode for it from the microcontroller projects.

The questions I have open (without reply unfortunately) are with regard to getting the DMA working with the PIO controller. Would you mind involving me in your discussions with Raspberry Pi? I would greatly appreciate it, and would very much like to be involved. Thanks!

from rpi_ws281x.

@orsemdev this issue is blocked due to lack of documentation on certain features of RP1 chip that handles IO on Raspberry Pi 5. We need to wait til the specs are released.

from rpi_ws281x.

from rpi_ws281x.

Need to get access to the synopsys DMA controller documentation.

https://github.com/cleverca22/rp1-kernel-example/blob/23fcd99ef40d2968d22f29cd808634814cc6d584/rp1-kernel-test.c#L80-L106

this is an example of using all of the proper kernel api's to manage the dma controller

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.

https://github.com/librerpi/rp1-lk/blob/757fbcb8f2554643989aac719e0cdb56a052f247/platform/rp1/pio.c#L48
this is a pio uart example that pairs up with that

https://github.com/MichaelBell/rp1-hacking/blob/main/PIO.md
this documents most of the pio differences

https://github.com/MichaelBell/rp1-hacking/blob/main/launch_core1/core1_test.c
and this temporarily hijacks core0 to get rp1-lk running on core1

the biggest issue, is that the PIO control registers are up at 0xf000_0000 in the private peripherals of the cortex-m3 pair
and there is currently no proper way to gain control of either M3
core1_test.c will overwrite some of the assembly in core0's firmware, so when a main control loop gets to that function, it runs some custom assembly, which can kick-start core1

rp1-lk is then a fairly standard cortex-m style binary, with the initial sp/cp at the start, and core1_test.c will launch that on core1
that then configures the PIO for whatever your desired task is, and enables DREQ

then the rp1-kernel-example can rig up dma and perform copies to/from the fifo's

i'm currently working on a logic analyzer type project, and i can get it to capture up to 581mbit from PIO

you can also find me over at ##raspberrypi-internals on libera if you want some more realtime questions

oh, and also read jdb's statement at https://forums.raspberrypi.com/viewtopic.php?p=2181672#p2181672

from rpi_ws281x.

I hope support for the Pi 5 can be resolved. Over at our RotorHazard Race Timer project we depend on this library for running LED strips and panels.

from rpi_ws281x.

Unfortunately, it's not easy to simply turn on one LED, or any color, without sending the wire protocol. The same basic logic is needed to turn on 1 or 1000.

from rpi_ws281x.

Would be interesting to know if a plain SPI bridge chip would have the throughput required. I’d just use a bunch of RP2040 (Pico) boards since they could update potentially thousands of LEDs continuously from an internal buffer.

Had no problem running ~12,000 LEDs split across 20 USB devices from one Pi using RP2040s- https://youtu.be/cm83RIhDbwo?si=fFB7bMm1-oSSfV8Y&t=10m48s

from rpi_ws281x.

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.

from rpi_ws281x.

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

from rpi_ws281x.

@Jezorko Thank you for your service 🖖

from rpi_ws281x.

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!

from rpi_ws281x.

from rpi_ws281x.

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:

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

from rpi_ws281x.

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

from rpi_ws281x.

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

from rpi_ws281x.

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?

from rpi_ws281x.

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

from rpi_ws281x.

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

from rpi_ws281x.

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

from rpi_ws281x.

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

from rpi_ws281x.

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;
}

from rpi_ws281x.

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

from rpi_ws281x.

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

from rpi_ws281x.

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.

from rpi_ws281x.

from rpi_ws281x.

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

from rpi_ws281x.

https://forums.raspberrypi.com/viewtopic.php?t=361457

from rpi_ws281x.

Hi , I'm following this issue. First of all , big thanks to @jgarff for working on this issue.
Secondly , I saw this product from Adafruit - https://learn.adafruit.com/adafruit-neodriver-i2c-to-neopixel-driver?view=all that seemingly should allow NeoPixel to run on devices and microcontrollers which does not support it. Maybe I don't understand all the technical details , but someone can verify it can work on the RPi 5 until the current issue gets resolved?
Thanks.

from rpi_ws281x.

Hi , I'm following this issue. First of all , big thanks to @jgarff for working on this issue. Secondly , I saw this product from Adafruit - https://learn.adafruit.com/adafruit-neodriver-i2c-to-neopixel-driver?view=all that seemingly should allow NeoPixel to run on devices and microcontrollers which does not support it. Maybe I don't understand all the technical details , but someone can verify it can work on the RPi 5 until the current issue gets resolved? Thanks.

I'm using this on a Raspberry Pi 5 currently, so I can confirm it does work. https://www.makerforge.tech/posts/pi5-build-log-4/#neopixel-i2c-support

Hi! My bad, I installed not as sudo. Could you please provide your script for test?

from rpi_ws281x.

Hi , I'm following this issue. First of all , big thanks to @jgarff for working on this issue. Secondly , I saw this product from Adafruit - https://learn.adafruit.com/adafruit-neodriver-i2c-to-neopixel-driver?view=all that seemingly should allow NeoPixel to run on devices and microcontrollers which does not support it. Maybe I don't understand all the technical details , but someone can verify it can work on the RPi 5 until the current issue gets resolved? Thanks.

I'm using this on a Raspberry Pi 5 currently, so I can confirm it does work. https://www.makerforge.tech/posts/pi5-build-log-4/#neopixel-i2c-support

Hi! My bad, I installed not as sudo. Could you please provide your script for test?

The sample code in Guy's link works for me - I have a more complex implementation but that isn't needed for the basic functionality.

Would still be great to see this repo working on the Pi 5 as the i2c module is a bit of a workaround for the issue for me.

Thanks for reply.

Maybe it doesn't work for me because I connect led through this board to rpi5.

What bus number you used?

from rpi_ws281x.

@Gadgetoid That's great! I am trying to get some support from Raspberry Pi on this as well and I am also optimistic that they will come out with something cool.

BTW, do you know what clock speed these PIOs can toggle at? If RP1 on Pi 5, could support DMA on arbitrary PINs, does that mean you can drive multiple long strips in parallel as well? I wonder what is the bottleneck...

@danic85 @madmongoose: I might be mistaken but I think I2C speed (400KHz) could limit how fast you can drive LED strips but it works for many applications. This won't be noticeable if you are showing static patterns but if you are transitioning fast between colors/patterns or you are piping too much on long strips, DMA can offer must faster transfer speeds. Also, with DMA you don't need the extra hardware (MCU) in between.

Thee's another type of LED that Adafruit calls DotStart that you do not have to do DMA. Adafruit NeoPixel is the terminology used for WS281X LEDs. There's a good comparison here.

I have always used WS281X LEDs because they are much cheaper (<$0.01 at large volumes), you can buy them easily in various types of packagings (right angle, fused lens, etc).

from rpi_ws281x.

@mehrdadfeller hi! I can't use a led without MCU in between, because https://github.com/Freenove/Freenove_Robot_Dog_Kit_for_Raspberry_Pi

I built this constructor instead of the recommended rpi4 on rpi5, corrected the code a bit, replaced GPIO with gpiozero. Servo drives, buzzer, ultrasonic work well. All that's left is to fix the led.
=)

from rpi_ws281x.

the specs available thus far are lacking in specific functionality of the RP1

It's not much use in the near term, but I am discussing (with Pi) the feasibility of WS281x support, or perhaps some userspace tools and interfaces to make it possible, that leverages the RP1's PIO. It's not a "no", but more a "this will be complicated and requires some thought and a fair bit of work."
I remain optimistic, since there's a desire to show off the RP1's PIO, that the Pi 5 will be able to support WS281x strips on arbitrary pins using a simple PIO program and the same DMA-a-bunch-of-carefully-crafted-bytes trick we use currently. This could potentially even extend to custom PIO code to emit the correct pulses for 1s/0s, but right now I can only really speculate based on a few brief discussions of our requirements.
Sorry I didn't get a Pi 5 out to you quickly- I am absolutely mired in getting everything else to work!

Thanks Gadgetoid! I was planning on actually using the new PIO to do this as it will be more flexible, allow for more GPIO ports, and sounds fun anyway. We can also leverage some of the microcode for it from the microcontroller projects.

The questions I have open (without reply unfortunately) are with regard to getting the DMA working with the PIO controller. Would you mind involving me in your discussions with Raspberry Pi? I would greatly appreciate it, and would very much like to be involved. Thanks!

Hi there,

I have just switched from my Raspberry Pi 2 --> Raspberry Pi 5 and my ws2812b scripts are no longer running without an error (Hardware revisions not supported). I assume that the problem is the outdated library, do you have any updates on the update for Raspberry Pi 5?

Thanks.

from rpi_ws281x.

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?

from rpi_ws281x.

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?

without using Adafruit NeoDriver - I2C to NeoPixel Driver

from rpi_ws281x.

from rpi_ws281x.

from rpi_ws281x.

This is great information @cleverca22, thank you. It's unfortunate however that the Cortex-M3's are required to read/write the PIO registers, which necessitates the need to get them involved. I'll dig into the links you've provided.

For what it's worth, I do have a lot of Cortex-M microcontroller experience, so I at least know how that works. If you're curious, I have a OS that I wrote specifically for Cortex-M parts (mostly Atmel) here:
https://github.com/westerndigitalcorporation/FissionOS.

Thanks again.

from rpi_ws281x.

Yeah, I've thought about that as well. Do you think it's possible to use the DMA to write to the PIO registers to setup the PIO without having to go through the Cortex-Ms? I don't like messing with the Cortex-M's if they're used for things like fan speed control, resets, and whatnot. Obviously using the DMA to write registers is inefficient, but would mean not having to use the Cortex-Ms.

from rpi_ws281x.

Unfortunately as far as we can tell the PIO can only be configured directly from the Cortex-Ms.

Given what @cleverca22 and I have done so far it would be fairly easy to make a kernel module that patched the code on the Cortex-M to configure the PIO with a ws2812 pio program, and then exposed a character device that you could use to DMA data to the PIO SM.

But the patching is very fragile and likely break with future firmware updates - it's not really suitable for something that lots of people are likely to use. We really need Raspberry Pi to give us some kind of mechanism to safely perform this configuration - until then it's possible to make a demo, but not really something that would be wise to distribute widely.

In the meantime, PWM ought to be a reasonable stop gap solution, although it obviously only works on some of the available header pins.

from rpi_ws281x.

Yeah, using the PWM is one of the methods that we used to support the previous Raspberry Pis.

from rpi_ws281x.

I don't like messing with the Cortex-M's if they're used for things like fan speed control, resets, and whatnot.

luckily, only core 0 is used for the fan rpm (and some unknown pcie duties)
the fan pwm is entirely linux hitting pwm regs directly

core 1 is entirely unused
but you need to temporarily hijack core0, to get core1 bootstrapped

from rpi_ws281x.

oh, and i forgot about @G33KatWork 's older stuff, before @MichaelBell found the core0 hack

https://github.com/G33KatWork/RP1-Reverse-Engineering

basically, you can just hard-reset the entire RP1, and re-load the core0 and core1 firmware over i2c, and reboot it
that would have better compatibility with the core0 firmware
both because your not patching it, and because you choose which core0 version is in use

but linux currently doesnt handle removal of the rp1 cleanly
so you need a dtoverlay that disables the rp1, reset it, then a runtime dtoverlay to allow rp1 access
and you can only do that once per host boot, so linux has to reboot to do it again

given that hard-reset, it would best be done from the initrd, before linux needs to mount any usb rootfs
and it would be best to have a flexible core1 payload, that can do different jobs

from rpi_ws281x.

from rpi_ws281x.

the pi5 goes thru a few phases during boot
first it loads a bootcode.bin from SPI flash, and executes it, that brings the dram controller online
then it loads bootmain.elf from SPI, and executes it, that deals with booting the whole system, and replaces the old start(4).elf
bootmain then has an rp1 firmware baked within its .rodata, it will push that over i2c to the rp1, and confirm its working, before moving on to starting the arm core

that whole chain, is signed with an unknown mechanism at the root, so any attempt to modify it will just result in the pi5 not booting

but once something is running on the main cortex-a76 core, it can just take over the gpio, hard-reset the RP1, and push anything it wants over i2c

@G33KatWork 's repo includes examples of doing that from linux, and i believe its possible to push the original core0 firmware, plus something custom for core1
in theory, you could modify u-boot into doing that as well, so core1 is doing something before linux has even been read from the card

but it cant really be used as a fallback, because you need an arm kernel on the bootfs, to hijack the RP1

but with the pi0-pi3 family, you can run https://github.com/librerpi/lk-overlay as a firmware replacement
then you can add whatever custom splash screen you want on any interface you can write drivers for

sadly, the pi5 has the VPU locked down even more then ever, and the open firmware may just never be an option for the 5

from rpi_ws281x.

It's interesting that they opted for loading the RP1 over I2c instead of having a small ROM. Makes sense though in that they can always program it from the bootloader of the BCM.

from rpi_ws281x.

having decompiled the RP1 boot rom, it supports booting in either i2c-slave mode, or spi-master mode
so they could have put a second spi chip on the board, and bootstrap the rp1 from that

but that would then drive up the cost of the whole assembly
same reason they ditched the vl805 spi chip

from rpi_ws281x.

It's interesting that they opted for loading the RP1 over I2c instead of having a small ROM. Makes sense though in that they can always program it from the bootloader of the BCM.

Hi jgarff, I appreciate the effort you are making to update the ws281x library. I was wondering if there is a simple way to control the led I have. I only want to turn it on and off at full brightness white. I'm a beginner to microprocessors and would really appreciate some advice. Thanks

from rpi_ws281x.

It's interesting that they opted for loading the RP1 over I2c instead of having a small ROM. Makes sense though in that they can always program it from the bootloader of the BCM.

Hi jgarff, I appreciate the effort you are making to update the ws281x library. I was wondering if there is a simple way to control the led I have. I only want to turn it on and off at full brightness white. I'm a beginner to microprocessors and would really appreciate some advice. Thanks

You can try SPI to turn on/off LEDs

adafruit/Adafruit_CircuitPython_NeoPixel_SPI#37 (comment)

from rpi_ws281x.

I would also be very interested to get ws28xx to work with a Raspberry Pi 5. What is the current situation of fixing this issue and future plans? I don't want to rush you with this post, I am just curious. :)
Have a nice week!

from rpi_ws281x.

Is there some progress with supporting the RPi5 because in one of my projects I need the processing power of the pi and control 10 separate strips with low latency.

from rpi_ws281x.

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.

AFAIK first party support for WS281X is still a distinct possibility but we can only sit on our hands and wait, and have no idea exactly how it might perform.

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

from rpi_ws281x.

Would be interesting to know if a plain SPI bridge chip would have the throughput required. I’d just use a bunch of RP2040 (Pico) boards since they could update potentially thousands of LEDs continuously from an internal buffer.

Had no problem running ~12,000 LEDs split across 20 USB devices from one Pi using RP2040s- https://youtu.be/cm83RIhDbwo?si=fFB7bMm1-oSSfV8Y&t=10m48s

As far as the datasheet is concerned it is fast egnuth and is a bit cheaper than a bunch of Pi Picos (and I hate the idea to make a firmware for them).
I am using these chips: CY7C65214D-32LTXI on a custom board that isn't finished yet but i will report my success and my setup used when I receive the board

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?
Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?

Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

Yes, I mean the driver to get the strip running on Pi 5. The neopixel library I downloaded worked on Pi 4 but not Pi 5. and can I get two strips running with pi 5?

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?
Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

Yes, I mean the driver to get the strip running on Pi 5. The neopixel library I downloaded worked on Pi 4 but not Pi 5. and can I get two strips running with pi 5?

You can drive one strip from SPI on the Pi 5 but not 2 then you need to wait for the PWM driver but you can but them in series in the meanwhile

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?
Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

Yes, I mean the driver to get the strip running on Pi 5. The neopixel library I downloaded worked on Pi 4 but not Pi 5. and can I get two strips running with pi 5?

You can drive one strip from SPI on the Pi 5 but not 2 then you need to wait for the PWM driver but you can but them in series in the meanwhile

We would like to drive one strip of WS2812B using Python on a RPI5. Our current solution is using https://pypi.org/project/rpi-ws281x/ with SPI0-MOSI / GPIO 10 on a RPI4b. You are stating "You can drive one strip from SPI on the Pi 5" and thus our question is how do you do this?

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?
Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

Yes, I mean the driver to get the strip running on Pi 5. The neopixel library I downloaded worked on Pi 4 but not Pi 5. and can I get two strips running with pi 5?

You can drive one strip from SPI on the Pi 5 but not 2 then you need to wait for the PWM driver but you can but them in series in the meanwhile

We would like to drive one strip of WS2812B using Python on a RPI5. Our current solution is using https://pypi.org/project/rpi-ws281x/ with SPI0-MOSI / GPIO 10 on a RPI4b. You are stating "You can drive one strip from SPI on the Pi 5" and thus our question is how do you do this?

Sadly this library won't work because even if it is in SPI mode it checks the Pi model that means you need to modify this library slightly to use it with the Pi 5 over SPI but I found another NeoPixel library that will work for the Pi 5 (I have tested it) py-neopixel-spidev
I hope this helps :)

from rpi_ws281x.

Sadly, the PIO IP in the RP1 doesn't allow for direct access from Linux is that confirmed I can't find anything in DRAFT document for RP1.
If this is true it might be a huge downgrade from RPi 3B which can easily drive 16,000 LED at 30 FPS with SMI and DMA.

If we could use Cortex-M DMA and PIO to push data to port at specific rate it could be possible to implement it by using the shared SRAM it looks like there is 64k, we could create 2 buffers like 16kB each and use one of them to push data via Cortex-M DMA to PIO while the main CPU would use DMA to push data via PCIe to the second buffer.

Since the main CPU is much faster the Cortex-M should never run out of data.
The only thing that might be challenging is the timing when switching between buffers e.g. if cortex DMA can't push data directly from shared SRAM and would have to copy to local SRAM, the WS281X is quite strict and any delay in transmission would reset writing back to first LED, but maybe we could use 2 DMA channels in this case one shared SRAM -> Cortex-M SRAM, the other for PIO.

I can't find any info about Cortex-M but if we could clock it to match WS281x 400ns pulse we could use only 3 bits per pulse which would use about 24kB for 1000 led in 8 channels which would alleviate the problem of delay when switching between buffers as two of these frames will fit in 64kB shared SRAM, while it is only half of what RPi 3 can do it is a good start. We could later look at dual core Cortex-M operation and use some of the 32kB non shared SRAM, with which maybe we could push 16 channels of 1000 LED at 30 FPS.

Sadly without RP1 documentation around Cortex-M all of this is speculation.

from rpi_ws281x.

Just following this thread, and noting that this is not mentioned in any of the rp1 links to prior work:

There's an old forum thread on spi access via registers rather than spidev;
https://forums.raspberrypi.com/viewtopic.php?t=365275

and praktronic's March 2024 reply with his repos, which may help (last message):

https://github.com/praktronics/rpi5-rp1-spi
https://github.com/praktronics/rpi5-rp1-gpio

At a glance by a non-expert here, he doesn't bother with rp1 firmware at all, but just uses some offsets from the rp1 docs+reverse-engineering efforts (bar offset, iobank base) to get userland memory access to the registers. Would it be possible to use say DMA from the Cortex-A cores with this, maybe even some pio-access?

from rpi_ws281x.

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.

Okay I might switch to USB-SPI bridge chips connected via USB through an USB HUB to the RPi5 with your driver (I saw that your driver supports SPI) but when the driver is ready (full PIO support) i will switch to the direct output of the RPi5

How could I download the driver and use it? And what do I need?

What do you mean by that?
Do you mean the driver to drive the NeoPixels over SPI? Because that I got working on a Pi 5 (1 strip with an Adafruit NeoPixel SPI library)

Yes, I mean the driver to get the strip running on Pi 5. The neopixel library I downloaded worked on Pi 4 but not Pi 5. and can I get two strips running with pi 5?

You can drive one strip from SPI on the Pi 5 but not 2 then you need to wait for the PWM driver but you can but them in series in the meanwhile

We would like to drive one strip of WS2812B using Python on a RPI5. Our current solution is using https://pypi.org/project/rpi-ws281x/ with SPI0-MOSI / GPIO 10 on a RPI4b. You are stating "You can drive one strip from SPI on the Pi 5" and thus our question is how do you do this?

Sadly this library won't work because even if it is in SPI mode it checks the Pi model that means you need to modify this library slightly to use it with the Pi 5 over SPI but I found another NeoPixel library that will work for the Pi 5 (I have tested it) py-neopixel-spidev I hope this helps :)

I use now the spidev of the pi with my own library and it works well :)

from rpi_ws281x.

from rpi_ws281x.

from rpi_ws281x.

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)

from rpi_ws281x.

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.

from rpi_ws281x.

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

from rpi_ws281x.