Driver for WS2812 RGB LEDs (NeoPixels, ...)

Showroom for MicroPython related hardware projects.
Target audience: Users wanting to show off their project!
Posts: 220
Joined: Fri Dec 13, 2013 9:25 am

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by torwag » Tue Feb 07, 2017 8:09 am

Beside of deshipus comment,
many sources on the net state that you should use some resistors and blocking capacitors in front of the first LED since they tend to be quite easily harmed by voltage spikes. Honestly, speaking I never did this and did not kill a single LED yet. Just wanted to mention.
Also take into account that the 3.3 V logic level might seems to be sufficient on the test-bench but the 3 m wire from the controller to the LED-stripe in the final application might create a lot of head-scratching ;)

Hmmm. thinking more about it, I wonder if the logic-level theory fits... since, if the first LED only receives rubbish digital values, it just forwards digital rubbish at now 5V to the other LEDs. However, I remember to read that the level shifters in the LED are more forgiving then other parts of the LED circuitry. Ultimately, I guess deshipu is right to say it would be much better to adapt the logic level.

User avatar
Posts: 1385
Joined: Thu May 28, 2015 5:54 pm

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by deshipu » Tue Feb 07, 2017 11:38 am

My sources: ... originals/ ... data-line/

Re-reading this again, I agree that it doesn't quite add up in my theory -- it's probably some kind of a timing problem.

Posts: 1
Joined: Mon Nov 20, 2017 4:20 pm

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by calyerm » Mon Nov 20, 2017 4:28 pm

After looking with logic analyzer on data line , the timing does not appear to be correct. The baudrate clock is good but the
neopixel bit low and high pulse widths are not right. For this clock (baudrate is actually 262500) Need 1/4 ratio for neopixel bit low and 2/2 ratio for neopixel bit high. Correction: Thats 2/4 ration for high.

Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by cefn » Sat Nov 25, 2017 12:58 pm

@calyerm what was your configuration (software/hardware) when you ran the logic analyser?

Were you using as per the original post viewtopic.php?f=5&t=394#p2199

Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by cefn » Sat Nov 25, 2017 1:01 pm

Posts: 20
Joined: Mon May 22, 2017 11:59 am

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by matto » Mon Mar 05, 2018 9:51 pm

Hi all!

I'd like to ask you about this library. I can see it's a little outdated, but it might still work for my needs:
I have a VERY long strip of WS2813 LEDs (1100 of them) in my ceiling. Right now I'm using an Arduino Mega with the FastLed library to drive them, and while it works, it has a VERY low frame rate. What I'd like to do is to drive them with an STM32 like this running MicroPython: ... 71346.html

Do you think this will improve the FPS of the animations? Are this library and microcontroller suited for this task?

User avatar
Posts: 54
Joined: Fri Nov 10, 2017 9:57 pm

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by mathieu » Wed May 23, 2018 2:28 pm

Damien wrote:
Wed Dec 10, 2014 11:49 pm
fma wrote:Great! But as I understand from your post on the other thread, the call to send() is still blocking during transfert, so CPU is not availabe for other tasks. Am I right?
Right. First step was to get DMA working, and main reason for that was to get uninterrupted transfers with interrupts enabled. Previously send() was disabling interrupts during a transfer, and this can lead to lost interrupts. Now it's much better with DMA, even if you have to wait for it to finish.

Next step will be to have an option to return before transfer is compete. And some function to check completion, as well as a callback.
May I ask what the state of SPI.send() is in 1.9.4? Did someone eventually implement the option to return before transfer is compete?

Posts: 1
Joined: Mon Feb 18, 2019 9:25 pm

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by bennigraf » Mon Feb 18, 2019 9:54 pm

It's been a while on this thread ;-). I'm trying to get my WiPy1.3 to work with some ws2812 LEDs, but just cannot get it to work. Does anyone have recent experience with that hardware and can tell me which library in combination with which firmware actually works? I'm getting various results, but I'm never able to actually just set colors properly on LEDs… (i.e. currently setting a RGB value to a LED actually lights up two LEDs but with still wrong colors).

I would appreciate any hints!


Posts: 3
Joined: Sun Feb 14, 2021 4:03 pm

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by hobyr » Tue Feb 23, 2021 9:12 pm

Hi everyone,

I'm currently writing my own WS2812 driver for training purposes. I dissected several github codes including Jan's driver and I can't understand the existence of the buf_bytes (0x88, 0x8E, 0xE8 and 0xEE) and why we use 1 byte for 2 bits of color.

I assume it's the way SPI buses work, but even after reading tons on SPI communication, I don't understand this "byte manipulation".

According to the WS2812 datasheet, each LED needs 3 bytes to communicate color. As I have a 16-LED ring, logically I thought I'd need 48 bytes to transmit to the ring as a Slave, but when I send a bytearray of 48 bytes, not all LEDs light up, and each time I renew the SPI send command, colors change despite a static byte buffer.

Might it be a clock problem as well? the datasheet mentions a speed transfer of 800kbps and my SPI baudrate is set at 750000 (I believe 750kbps). I feel like something is missing.

Could someone enlighten me?


User avatar
Posts: 3601
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada

Re: Driver for WS2812 RGB LEDs (NeoPixels, ...)

Post by dhylands » Tue Feb 23, 2021 10:23 pm

The reason to use SPI is to get nice consistent pulses.

This web page has some pictures that will probably make things make more sense.
I don't know that the driver is following this exactly, but conceptually, it should help you to understand how things are working.

Multiple bits are being used to generate the pulses which is why the bytes look weird.

So this is very much a hacky use of SPI and not the way you normally use SPI, which is probably why you're not making sense of normal SPI documentation.

Post Reply