Add support for RPi SMI peripheral

[petiepooo]

Jeremy Bentham has figured out how to use the Raspberry Pi's SMI peripheral to drive up to 16 channels of RGB LEDs at once via DMA. See https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws2812/ or https://github.com/jbentham/rpi

I'm really excited to see what's possible for this technique. If it can easily support 8 or 16 channels of 2-4 DMX universes with minimal CPU use, it could really disrupt the low-cost DIY LED controller market.

Since this is the premier library for driving RGB LEDs via the Pi's PWM or PCM peripherals, it would be fantastic to add support for SMI too. That would be the first step in integrating into Falcon Player, or creating a stand-alone E1.31 receiver, or who knows what else.

[Gadgetoid]

As near as I can tell from a glance, every single pin supported by the myriad methods in rpi_ws281x could also be supported in 16-pin SMI mode. This means the PWM, PCM and SPI modes are obsolete.

In light of this, I suspect it would be worth building and binding a clean implementation of just the SMI functionality. Integrating the SMI feature into this library would be like fitting a petrol engine in a horse-drawn cart.

SMI alone- assuming it plays nicely with other features- would not only give output on all but 8 GPIO pins, but it wouldn't trample PCM or PWM functionality in the process.

As invested as I am into rpi_ws281x- I'm afraid pretty much the entire featureset would just be dead weight and this might be a better opportunity to try and build a ground-up library that doesn't include its flaws.

[Gadgetoid]

Looking into this method and attempting (but not succeeding) to get it working on my Pi 4 reveals there are some drawbacks (though it remains to be seen if those could be mitigated) that don't exactly make it the apocalyptic end of days for rpi_ws281x that I feared it might be.

[petiepooo]

Thanks for your thoughts on it and for testing it out. I am curious what drawbacks you're seeing.

I know Jeremy's proof of concept is limited in scope, specifically the length of the LED string, and I recall reading that the graphics engine may interfere. I was hoping that might just be a conflict in which DMA channel was used or could be fixed by setting the process priority to keep the DMA queue full. I also know it's early in fleshing this method out, so I encourage you not to give up yet.

As ubiquitous as the rpi_ws281x library is, I'm hoping that the SMI implementation sticks with the same API, as that would make upgrades of existing software much easier.

[psy0rz]

I'm also testing Jeremy Bentham's code at results are promising.

Some notes:

• Use a 32 bits OS. (im using ubuntu 21)
• Blacklist the sound drivers and stuff, just like with this lib.

Results on an RPI3b, with 8x256 leds at 60fps is functioning fine and is only using around 10% cpu!

[Xartrick]

I'm also testing Jeremy Bentham's code at results are promising.

Some notes:

* Use a 32 bits OS. (im using ubuntu 21)

* Blacklist the sound drivers and stuff, just like with this lib.

Results on an RPI3b, with 8x256 leds at 60fps is functioning fine and is only using around 10% cpu!

Hi @psy0rz,

Do you have any POC that we can see? Thanks!

[psy0rz]

The POC was just his example, but modfied for 256 leds and 16mS sleep (=60fps)

I just started working on a nodejs module, ill post an update here if i have something.

[psy0rz]

Here's the work in progress of the nodejs module: https://github.com/psy0rz/rpi-ws281x-smi

[0tobsam0]

I can confirm, that this works with a ws281x strip of 600 LEDs at 100 Hz on a Pi 4 without a problem on 8 channels simultanously.

I made a fork of the original and I am trying to turn it into a small library that can be used inside python applications. As my experience in building c libraries is fairly limited @psy0rz's repository might help me a lot with that.

My fork: https://github.com/Dual-Studio/rpi_smi_led