5 years, 12 months ago.

support for neopixel (ws2812 addressable LEDs) on microbit

Hi,

I've bought a bit of kit thats a retro gaming console for microbit. It has an 8x8 grid of ws2812 compatible LEDs as a screen is there any native support for neopixel when programming on C++ on microbit have you any examples of using neopixel with microbit

Question relating to:

The BBC micro:bit is a pocket-sized, codable computer that allows anyone to get creative with technology. Made possible through a major partnership with 31 organisations, a micro:bit has been given …

1 Answer

5 years, 12 months ago.

I've not seen it on the microbit specifically but often your best bet is to use an SPI interface to generate the correct timings, it is a lot more reliable and interrupt friendly that trying to toggle GPIO lines at the correct rate. I've done a library that will do this sending 3 bits per LED data bit, it then sets the SPI bus to 12 bit transfers which works on NXP devices but not on all of the others. There are other similar libraries around. From memory (it's been a while) the LEDs time off the low time on the signal, the highs can be any length you want as long as they aren't over the reset time (150us from memory) so doing 16 bit transfers with any unused buts set to 1 should work fine.

There is also a potential hardware issue to be aware of. By the datasheet the WS2812 parts have an input threshold of 0.8*Vcc and are designed for a 5V supply meaning you need 4V for a high. Most mbeds output around 3.1V.

In practice it may sometimes work, it's right on the edge. If you drop the LED supply voltage it will work but you can start to lose the blue LED. Ideally you need to add a buffer with a 5V output to drive the LEDs.

Yeah the thing is that won't be possible. the LEDs are on pin 0 and the pins 13, 14 & 15 (the spi interface) are used for buttons.

posted by phil hall 30 Nov 2018

@phil: that needn't be a problem, as the SPI hardware can be configured to use any pins. But the lack of DMA for the SPI master on the NRF51 means that the processor must still be involved byte-by-byte in the transfer, with strict timing constraints.

posted by Mike Spivey 14 Jun 2019