Using WS2812 with LoPy

[jmarcelino]

Try this one:

https://github.com/johannesgaa/wipy-WS2812/tree/wipy2.0_support

[binux]

I tried. Nothing happened. I used the test.py from the github project.

[peekay123]

@jmarcelino, that library is not working for me. The LoPy SPI 0 port is on P11 I believe, not P22. Even with the change of pins, I have not been able to get an 8-led unit going.

[jmarcelino]

@peekay123
Yes something changed, I couldn't get that library to work for me yesterday. Seems that now when ports are set as SPI you can't do PULL_DOWN as the code is doing.

I'm away from any WS2812s or test equipment until Wednesday so can't really help with this until then.

[binux]

@jmarcelino I ask myself why the pycom led library does not offer the option to control a WS2812 strip. I mean they have one mounted on the PCB a change to support a led strip seems minor to me. Looking forward to know your results on Wednesday

[Eric24]

@binux I had the same thought a while back. The code that drives the single status LED should be fairly easy to expand to support a string of LEDs. And doing it that way would save the SPI port for "real" SPI stuff. I think it would be a nice feature.

[gadgetoid]

I'm not one to grave-dig old topics, but this one isn't that old and seems to turn up in Google for searches about using WS2812 pixels with WiPy/LoPy etc.

Upon looking into getting our WS2812-based products up and running with WiPy I came across the libraries listed here, but upon further testing I found some pretty severe problems with how they work.

Both of the linked "wipy-WS2812" codebases suffer the same issue; they claim to pack 2bits per byte, when they actually pack 1 bit every 2 bytes and discard half the bits. Running tests that sweep the full range of intensity for any colour channel pretty quickly showed this up.

Another example I found for generic MicroPython boards (uses import pyb and pyb.SPI which I believe is either an old paradigm, or one the Pycom does not follow) managed to get the bit packing correct, but failed to disable interrupts. It would update ~8 pixels before an interrupt fired and caused a delay in the SPI output long enough to count as a WS2812 reset.

I took the best of both of these examples and merged them into this: https://github.com/Gadgetoid/wipy-WS2812/commit/4288b4b782040053fcfec86fa7644dbec3ceab76#diff-62a17d14021710b4dc4370f193749d1f

Much kudos to whoever came up with the 2bits per byte packing optimisation- it's elegant, even if it makes the code ugly.

I have tested my code up to 32 pixels on a WiPy 2.0 board, using the SPI MOSI pin (labelled G22 on the breakout) and verified with an oscilloscope that the signal is consistent and uninterrupted.

Hopefully someone will find this useful.

[peekay123]

@gadgetoid, you library was working very nicely with the previous version of system firmware. I wrote a simple rainbow effects which looked very nice. When I upgraded to 1.9.0.b1, the effect became eratic. I'm not sure where to begin figuring out what the latest update did! Any advice?

[Devang Sharma]

Hello All, I've tried the same library as @binux did. I've used 3 WS2812B LEDs and got no output.

My Firmware is: (sysname='LoPy', nodename='LoPy', release='1.9.2.b2', version='v1.8.6-796-g489fafa0 on 2017-10-15', machine='LoPy with ESP32', lorawan='1.0.0')
Is this issue solved yet?
If not, then is there any way to route the onboard WS2812 LED to the IO?

Thanks.

[binux]

@devang-sharma I fixed the issue. It looks like the firmware no more requires a "special" data pin for the LoPy.
Just use my fork of this library and connect your datapin to P11 (G22) and it should work as expected.

https://github.com/binloan/wipy-WS2812

[MikeXu007]

will it be the same when deal with the ws2813b leds？
http://addressable-led.com/Products/WS2813-LED-Chip.html

[livius]

@mikexu007
You can work with same lib