Question about WS2812B (Neopixels)

[alvaroevc5]

Hello mikroE people.

I recently managed to emulate the WS2812B protocol on a 18F2550 and it kind of works.

The problem is that, when toggling some LEDs in a row using a WS2812B ring, it sometimes happens that other LEDs flicker with different unintended colors and brightness, and it happens very randomly, so finding a culprit has been quite difficult.

I have searched all over the internet, and people mention many different things, such as, having an unstable power supply, decoupling capacitors, and so on...

Yes, I've made sure my circuit is at least acceptable, and the timings on my code for the protocol are as good as can be with a low end microcontroller, all within the protocol's expected range, and even so, I toyed with the timings without seeing any difference on the random flickering. It is so random and I have tried so many things already that it is driving me nuts...

Has anyone used these WS2812B LEDs?

And if so, any ideas on why this happens or any recommendation that I could follow?

[Thomas.Pahl@t-online.de]

I do not know if your PIC18 is fast enough to bitbang the data. i use arm processor with 168 Mhz that is able to do the job.
For µC with less power have a look at this:
https://www.elektormagazine.de/news/spi ... -leistung/

(in german )

[alvaroevc5]

Well, I am using my 18F2550 at 48MHZ clock, which turns into 12MHZ instruction cycle.

I saw the video, it is in english actually . The problem with that method is that I am using INT0-INT2 interrupts on this microcontroller, which are inconveniently located exactly over the same pins for SPI protocol transmission, that's why I got into emulating this protocol in software, since I could throw the signal over any pin I wanted.

It seems weird that they issue would be timing, since the protocol itself is very forgiving with the timings, about +-50% off.

I really wanted to get the most out if this micro, I have the feeling it has the potential to do many things at once, I'm just not being clever enough to make it work all together.

So... brute force is the only thing viable? A faster micro then?

[alvaroevc5]

Wait... I had an idea and I hope people may follow along

Shouldn't I be able to do the same thing proposed in that tutorial, but instead of using the SPI bus, I could use the UART pins?

If my FOSC after applying the PLL is 48MHZ, and my instruction frequency is therefore 12MHZ, I should be able to work with UART at 800KHZ, which is what is required by the WS2812B protocol.

Right?

[Toley]

So... brute force is the only thing viable? A faster micro then?

Not a faster micro but a slower one!
Did you ever came across this very interesting application note from Microchip? https://ww1.microchip.com/downloads/en/ ... 01606A.pdf
It explain how to interface WS2812 Leds using the CLC module available on some newer PIC Micro.
I was able (some years ago) to interface a WS2812 Led strip (144 leds max for this micro) all by interrupt while decoding a NEC IR remote also by interrupt.
This can not be done with the popular arduino NeoPixel library.
All that was done on a small PIC16F1705 @32MHz with only 8k ROM and 1k RAM.
Later, I ported the code to a more powerful PIC16F18326, still 32MHZ but 16k ROM and 2k RAM so more Leds can be addressed.

The problem is that this is probably the most powerful PIC micro available right now that can interface those Led strip using this method.
The requirements are: 2 CLC modules with 4 cells each, and most important (this can be read in the application note) an SPI clock that use 1/4 of a timer.
Many more powerful PIC 18F, 24F or even 32F do have CLC modules but they use a separate SPI clock and it cannot be in sync with a timer.

Maybe when I have more free spare time I will publish my work on this in Libstock to help other peoples start from something.

Have fun.

[Thomas.Pahl@t-online.de]

If I read right, you use interrupts? That is not a good idea with WS2812. Perhaps your problem is there. When I use the software solution all interrupts are off.

[Toley]

I don't have problem with my library, I can send data to 144 Leds in 6,81 ms. And most important, I can send data continuously (chasing Leds) while doing other things like decoding NEC IR remote control. Those kind of things cannot be done with bit banging solution.

What I call a "problem" is that no other PIC can do it more easily even a PIC32 cannot be as efficient as my solution. I was looking for a PIC with USB and CLC and SPI with 1/4 timer clock but it don't exist. You need to read and understand the Application Note if you want to build a solid and efficient solution.

[alvaroevc5]

Interesting posts right there.

From what I see, when people use these Neopixels on PIC, they either don't use any other peripherals on the chip and make it a single purpose application or they use specialized internal components as the CLC.

I have come across those PDFs and tutorials with CLC, there is even a video tutorial about it: https://www.youtube.com/watch?v=hHLMnJs87VE .

Unfortunately, as mentioned by Toley, I am using quite a few things that are hard to be found all together into one chip. I use internal and external interrupts (which unfortunately occupy the same pins for SPI communication), I use USB, and other few things that, when you go into the debugger and test them, they actually don't take too much time to process.

That's why I was trying to find a more "clever" way to go about that Neopixel problem. That's why I brought up the idea of maybe using the UART port, since you can send many bytes in a row without needing to convert every single byte into 1s and 0s beforehand. I also saw some people emulating Neopixel protocol using PWM (https://github.com/japaric/ws2812b/blob ... /README.md), but I don't know yet how reliable would that be.

[alvaroevc5]

If I read right, you use interrupts? That is not a good idea with WS2812. Perhaps your problem is there. When I use the software solution all interrupts are off.

This interrupt thing was bugging me after I read it, and guess what, it worked, my WS2812B bit-banging works flawless with 24 LEDs, maybe more LEDs will add some more timing issues, but no glitching at all after turning off TMR0 overflow interrupt.

That is what was causing the flickering LEDs, apparently the time it took to go into the interrupt and get out of it was enough to mess with the protocol timings.

Now I will have to see if it is feasible in my application to turn off TMR0 interrupt right before the Neopixel sequences.

This is still quite problematic, because there might be an application that needs a certain interrupt to be ON all the time.

Bit-banging this protocol in an 18F2550 is possible, now confirmed!

[Thomas.Pahl@t-online.de]

My question was adressed to you @alvaroevc5, sorry for not clearly comunicating. Glad to read your success. Because of these interrupt problems i have considered to additionally use a small (8-pin) chip only for the neopixel feature.

[alvaroevc5]

@Thomas.Pahl@t-online.de, thanks for the advice.

I also thought about using a separate and very small microcontroller just as a WS2812B driver, and to be frank it's not such a bad idea, considering prices for low end PICs now days. The thing here is that, when it comes to lowering prices as much as possible, that little piece of gear adds up. Also, my inner stubborn and perfectionist engineer just wanted to keep going finding a way to cram everything together as efficiently as possible into one chip, I was eager to get to most out of it just because I thought the chip could, and it can.

Glad to read your success.

Thanks to you and everyone else for their ideas and opinions.

Happy coding!