Integrating Raspberry Pi Inverted UART TX pin as WS2812 Source

[jliriano2000]

Hi! I followed this guide and was able to solve three problems in one solution: 1) Level shift the UART TX signal to 5v and 2) Invert the signal and 3)Not rely on the PWM or SPI peripheral. I can drive any length of WS2812 LED strips directly from the Rpi UART Tx pin.

I modified a Hyperion NG build to hijack one of the serial implementations and was able to get my hardware working. Sort of...
I was able to set LED patterns but they would periodically glitch (see video).

The glitching is related to the CPU load. Glitching occurs more often when starting a new process on the Rpi. I tried isolating a core for just the Hyperion process and moving interrupt handling to the other cores. This reduced the glitching but did not eliminate it entirely.

From the sounds of it, it looks like HyperHDR is a much lighter weight alternative than Hyperion. Does anyone think I will have a glitch-free result if I used HyperHdr instead of Hyperion?

I am running on a Raspberry Pi 3B+

matrix.mp4

[awawa-dev]

Hi. In both applications the LED driver has its own thread. I suspect this is a similar limitation to emulating the Neopixel signal using SPI: it's just that neither SPI (#521 (comment)) nor the serial port have to send the packet from the high abstraction application all at once as one continuous data stream because it's done by the hardware driver. And the Neopixel emulation here relies on that.

[jliriano2000]

@awawa-dev I understand. For the any digital serial data method to work, all of the bytes have to be shifted out without delay. Some interrupt might trigger the "latch" time for the LEDs and corrupt the stream.

Does this mean that using the Rpi SPI data pins would also cause glitching? The SPI peripheral has a configurable buffer size so it's possible that with DMA, the SPI data pin never loses its timing.

It seems that the best solution is to use a controller with fixed timing (and that does not have a full-blown OS) that you can connect to a host PC (or RPi) running Hyperion or HyperHDR.

[awawa-dev]

Yes, RPi SPI method is also not reliable for Neopixel emulation. PWM (Rpi 1-4) is more reliable, but problems appear with longer LED strips and especially with RGBW protocol. RPi5 has PIO coprocessor should be completely stable and very accurate, but it is not available for users without hacking kernel. PIO also available in Raspberry Pi Pico boards (rp2040) is used in our other projects: HyperSerialPico and HyperSPI.