[driver] Add simple driver for WS2801 RGB LED strip

[xrigau]

Done in #11

[proppy]

Maybe we can generalize the APA102 driver to also accomodate the WS2081 pixel format?

[xrigau]

Good idea! But the issue of doing that would be that the protocols are quite different.

As you can see here https://cdn-shop.adafruit.com/product-files/2343/APA102C.pdf the APA102 sends a 'start' frame, then each LED frame and an 'end' frame, and also each LED frame contains 5 bits for the brightness (global) as well as the RGB values. Whereas the WS2801 https://cdn-shop.adafruit.com/datasheets/WS2801.pdf is a lot simpler as it only needs the RBG values for each LED, so no start and end frames, and no brightness values.

It definitely can be done but I'm worried the code would get unnecessarily complicated, what are your thoughts @proppy ?

[proppy]

I was thinking we could have a a few *Protocol classes that expose getters for:

• StartFrame
• EndFrame
• DataFrame

(and Start/EndFrame could be empty for the WS2801).

The nice thing is that it would be easier to test without mocking out the SPIDevice, but you're right that it might be overkill. Another drawback is that the driver would need to be renamed to something more "generic" which could make it less discoverable (unless we keep the implementation shared but publish the driver as two distinct artefacts).

@mangini @jdkoren any thoughts?

[xrigau]

👍 would be great if we could reuse some code (specially because most different LED strips will work in a very similar way with little differences between them).

I'll have a think in the next days. Meanwhile should I close the PR (#11)?

[xrigau]

also while I have your attention, mind answering this please 🙂 ? http://stackoverflow.com/questions/41580386/whats-the-driver-metadata-file-used-for-in-android-things

thanks!

[Gadgetoid]

I happened upon this thread, and while I don't know the state of APA102/WS281x support in Android Things I think you'd have some issues making generalised code to support both devices.

APA102s are, effectively, just a shift register with a separate Data and Clock line which is completely unaffected by timing. It can be driven by SPI hardware quite trivially.

The WS281x pixels, however, are a single Data line with very precise timing requirements for 1 and 0 pulses. Incidentally they can also, in some cases, be driven by SPI by representing pulses as sequences of high bits, and using only the SPI MOSI line. This usually requires a realtime interface (such as DMA) to feed the SPI hardware, and some transformation to create the pulses, which would look something like: 0b10001000 for two sequential zeros, and 0b11101110 for two sequential ones, 0b10001110 for 0b01 and 0b11101000 for 0b10.

I suspect you could wrap both protocols in a higher level class that deals with setting/getting pixels, setting brightness and managing chains of pixels in general, but the low-level protocol stuff is sufficiently different that I wouldn't even try. You can drive APA102s from pretty much anything with GPIO, including an IO expander, but the timing requirements of WS2812 place some limitations on the hardware that can drive them.

On the Pi, this library will drive WS281x pixels using SPI, PCM and PWM- https://github.com/jgarff/rpi_ws281x -DMA is used to feed pixel data to the front-end hardware without interruption.