LED Them Fight: new open-source addressable LED controller for Raspberry Pi

M

mrb

New member
Hi all, I hope this is not off-topic. I wanted to announce a new open source tool I just developed:

LED Them Fight: https://github.com/mbevand/ledthemfight

The main reason I created it is that I wanted to make it dead simple to create custom effects rendered live and reliably. No streaming real-time pixel data over unreliable Wi-Fi. No downloading hundreds of megabytes of firmware development packages. No reflashing microcontrollers. No recompiling anything. Just type simple Python code which is instantly rendered on a locally-attached LED string. From a factory-reset Raspberry Pi it takes less than 60 seconds to install & configure LED Them Fight and code your first custom effect.

I'm looking for feedback and ideas. I'm using it right now on the fascia on my house to drive a WS2815 strip of 466 pixels. My family loves it :)
 
I'm glad you find it useful! If you want to share your patterns, I could add them to LED Them Fight :)

Right now I'm really bummed that the underlying library I use, rpi_ws281x, does not support the new Pi 5 (see https://github.com/jgarff/rpi_ws281x/issues/528). Besides, from a technical viewpoint, it's quite limiting that LED Them Fight requires to run on a Raspberry Pi. It would be better if it ran on any SBC computer. So I have done a ton of research across literally dozens of solutions to drive addressable LEDs, be it from SBC computers or microcontrollers. And by far the best solution I found which is cheap, fast, performant, and not very well-known (why?) is this:

https://github.com/wramsdell/TriantaduoWS2811 - this guy found that you can use the FlexIO peripheral on NXP i.MX RT MCUs ($3 and up), which is the MCU found on the Teensy board, to drive 1 million LED updates per second !

So I'm going to develop a small cheap USB device, a bridge if you wish, which fans out to up to 32 strings of addressable LEDs, and it can be plugged in the RPi and drive an unfathomable amount of LEDs. I've done some benchmarking and both the RPi and i.MX MCUs can respectively send and receive 300+ Mbit/s of data on the USB link (thanks to i.MX implementing USB 2 natively), which is means it will truly be possible from the RPi to feed 1 million LED updates per second. At that point the bottleneck will probably become LED Them Fight itself, but that can easily be optimized. I think I can produce a bridge device like this for less than $10. I will make the USB protocol well-documented and open source. So LED Them Fight or any software can use it, and do so on any computer, a Pi, a BeagleBone, etc. If this works quite well, I think I might commercialize the bridge device.
 
Last edited:
I actually know the guy that wrote that library, worked with him about 5 years ago (just need to find his contact info again). I could see if he is interested in updating it?
 
(Weird: it looks like your message which I replied to with my #4 message got deleted from the forum.)

Oh yes, in fact would you be able to introduce me to wramsdell? I could straight up hire him develop the bridge device.
 
Wrong guy....I know Jgarff. I pinged him today, and he responded but I wanted his permission to repost what he told me about the rpi_ws28xx development.
 
Ah, it's jgarff... Well, he's already well aware of the issue. He wants to update the library. As he said in https://github.com/jgarff/rpi_ws281x/issues/528 he's done some preliminary research on how to address it, but right now he is blocked by lack of documentation. The Raspberry Pi foundation did not give enough technical details about the Pi5's RP1 chipset to allow him to program DMA transfers to the PWM peripheral to generate the WS281x signal...
 
Just to follow up....this is what Jer had to say. Probably already what you knew, but just closing the loop with it.

As for the RPi 5, yes I've been working on it. Unfortunately, the Pi5 has a new chipset, called RP1, which means that all of the GPIOs and peripherals are now going through it instead of the Broadcom SoC.
None of the hardware inside the new RP1 chip is compatible with the driver. So, I'm in the process of trying to get specifications, and workarounds if possible to support it.
Turns out that the RPi organization didn't consult with me before changing the entire design. :)
 
You must log in or register to reply here.
Back
Top