WS2812b Neopixel and nRF52 chips using hardware and software SPI clarification needed for Pixl and MDBT42Q

Sat 2019.01.12

Related Forum information is three years old and the new nRF52 chips are six months new. I'm keeping my fingers crossed that there is a simple solution (other than no it doesn't work) to driving a Neopixel using software SPI.

The WS2812 data sheet indicates a bit rate of 800Kbps

https://www.parallax.com/sites/default/files/downloads/28085-WS2812B-RGB-LED-Datasheet.pdf

Do the nRF52 boards support Hardware SPI?

A note on the MDBT42Q page: "Note: The nRF52 port has one available I2C, SPI and USART (and infinite software SPI and I2C)"

https://www.espruino.com/MDBT42Q

Q: Does this mean there is one hardware SPI port? If so, which pin?

If yes,
Q: Does the Pixl have the same functionality? (not so hopeful here either as I'm not seeing which pin)

https://www.espruino.com/Pixl.js

Software SPI

From:

https://www.espruino.com/SPI

"Pretty much all SPI devices are guaranteed to support 100kBits/sec transfer speed"

but

"Note: baud rate is ignored for software SPI - it will always send as fast as possible"

What is 'as fast as possible' and is that rate fast enough for the WS2812 ?

Related forum posts:

Post three years old so for Orig/Pico STM32 chips?

"I'm afraid not - software SPI isn't fast enough"

http://forum.espruino.com/conversations/275672/

Uses a speed of 4000000 which is five times faster than the required bit rate of the WS2812

http://forum.espruino.com/comments/14258509/

but, from the previous link, isn't the baud rate ignored?

Checked out Tips and Tricks and found allObjects Hw/Sw SPI article

http://www.espruino.com/Tips+and+Tricks
http://forum.espruino.com/conversations/327459/#comment14488718

Didn't apply in the WS2812 case.

"Just to add to this - to use send4bit for neopixels, you need hardware SPI. Software won't cut it even though it is available."

http://forum.espruino.com/comments/14493345/

Is this the Coup de Gras that indicates software SPI is a no go for the WS2812 ?

If so is there a simple explanation such as software SPI is ten times slower than the hardware equivalent?

I'm pouring over the nRF52 datasheet, but quite frankly having some difficulty in translating to Espruino boards

https://www.espruino.com/datasheets/nRF52832_PS_v1.0.pdf

Thank you in advance @Gordon for the clarification,
Robin

Hi Robin,

have you tried something like this from the neopixel API section?

// replace <YourPin> with the gpio wired to data 
// set output
<YourPin>.mode("output");
// set first three neopixel 
require("neopixel").write(<YourPin>, [20,0,0,0,20,0,0,0,20]);

Builds for MDBT42Q boards include neopixel.

Sat 2019.01.12

Thank you @MaBe for responding. That code snippet would be what I would use with hardware SPI, if I could locate a suitable pin.

Should I accept the build link (from #2) Line38 and Line60 as fact, then using the corresponding Pixl .py file Line35 and Line67 mirrors the same, so both devices %should% have one hardware SPI, . . . Correct?

https://github.com/espruino/Espruino/blob/master/boards/PIXLJS.py#L35  and #L67

However, when I check the reference pages, and roll-over the pin icons, I'm not seeing that hardware SPI at any pin.

http://www.espruino.com/Pixl.js
http://www.espruino.com/MDBT42Q

Software SPI

From @allObjects article link in #1 above and

https://www.espruino.com/SPI

the format is more like this, isn't it?

var spi = new SPI();
spi.setup({mosi:B5, miso:B4, sck:B3});
spi.write([1,2,3,4])

The other perplexing issue is whether software SPI is fast enough for Neopixels on these two devices.

Sun 2019.01.13

Taking an overnight break and starting fresh, with a cup of coffee of course, Success!!

Well at least for the Hardware SPI on Pixl. Still would like Software SPI clarification, though.

So what did I learn from this experience?

Younger than fifty heed this as you'll get to this age eventually, a fact, older than that, you'll get a kick out of this.

I attribute the success to the ID-10-T error. Enunciate alpha chars to get it. Okay, got it? (not, eye dee ten tee)

Embarrassment Factor: 6

Having two hundred hours Neopixel coding on the Pico, I was comfortable using any of the three SPI ports on that device. Wanted to build a BLE controlled Neopixel project, with the Pixl.

Reading this note:

Note: Pixl.js has one available I2C, SPI and USART (and infinite software SPI and I2C). Unlike other Espruino boards, these peripherals can be used on any pin.

http://www.espruino.com/Pixl.js

the fact that the words 'infinite software SPI' caught my eye. Following, 'can be used on any pin' made me curious. And here is where the flawed thinking crept in. As the other Pico documentation had roll-over icons that showed the hardware SPI ports, I made the Ass-U-Me(ption) that as the Pixl page indicated one hardware SPI, but the embedded image did not contain the roll-over icons, that the image needed updating, as the Pico page had been around for a few years and most likely had all flaws corrected. Not seeing the comparable hardware info blocked the reasoning that 'any pin' could be used. Again, after re-reading @MaBe response and rationalizing that why would the seemingly obvious be a type of response that a seasoned forum contributor would post. . . . hmmm . . .    I went back to the Pixl page and noticed that there wasn't the USART and I2C roll-over detail either.

Then it hit me, ID-10-T !! Maybe, just maybe, the build as MaBe explained did a little magic under the hood, unlike how the Pico has fixed pins for it's SPI ports. Moving the data input wire to a selected pin and coding as MaBe suggested, and viola!

Steps to solving or debugging the seemingly impossible:

1. Take a break and start fresh
   
2. Re-Read the specs and supporting docs several times
   
3. Double check your voltages and wiring
   
4. Review other similar projects
   
5. Re-Read what was (you) previously posted in the forum
   
6. Ponder. Sit back and put the pieces together
   
   

Heeding the note, I limited my test to two Neopixels (any more and you'll blow the onboard regulator)

the 5v pin will be connected to regulated 3.3v power (note: max power draw is 150mA)
http://www.espruino.com/Pixl.js#-vin-pins

require("neopixel").write(A5, [0,0,0,120,120,120,0,0,0,255,0,0]);

turns on the second Neo amber and the forth Neo green - GRB x 4 tripplets

Success!!

EDIT:   Thr 2020.03.19
WARNING! Driving more than two individual Neopixels full on will exceed the maximum 150mA the onboard regulator is able to supply. The reason this works, is that I understood the limitation and only drive the amber segments at half brightness and only the green segment for the other. (one half of three RGB 20mA is 30mA plus the 20mA green is 50mA plus external LED 20mA equals 70mA total - well below 150mA max)

Also note, that Neopixels require 5V and as I wrote this warning now don't have a reasonable explanation as to why I wired (did that a year ago) the Neopixel strip to the 3V3 pin, as the regulator is required for the nRF52 3V3 input. This was a proof of concept project and as you can see it did work, but my recommendation is to use an external 5V supply going forward.

Image appears darker as the extreme brightness of the LEDs saturated the camera input, even as the shot is at an angle to the source. No image was possible directly facing the LEDs.

2 Attachments

👍🏻

Just to confirm:

• nRF52 chips with Espruino do have hardware SPI (on any pin)
  
• They also have software SPI (on any pin)
  
• SPI isn't used at all for neopixel support on nRF52 - it's something called I2S (but that is also available on any pin)
  
  

If the neopixel docs (eg http://www.espruino.com/Reference#neopixel) or the WS2812 page could be improved to make it more obvious then I'm definitely open to pull requests :)

But at the end of the day, it's worth just trying and seeing - even if nothing is connected, require("neopixel").write should give you an error if it thinks it can't use the supplied pin.

Wed 2019.01.16

Thank you for the confirmation, @Gordon

The third bullet needs just one final tweak. My take on the documentation is that there is one and only one UART SPI and I2C that can be configured.

Clarification is needed on the 'and infinite software SPI and I2C' part.

Does 'infinite I2C' then mean more than one Neopixel string may be configured? (no? as infinite other I2C devices %could% be configured, e.g. 'available', but only one Neopixel reference allowed? as limited by internal hardware/software design)

As a suggestion, what about a table for Neopixels that shows functionality?

On leftmost Y-Axis, the devices and adjacent to that the processors. Along the X-Axis, (numb) Hdwr SPI, Software SPI, Software I2C

ex: For Neopixel - 'inf' means infinite available but not for Neopixel - use I2C

Pico STM32 |   3   -   -
Pixl  nRF52  |   - inf  1

I2C? I2C can't be used for neopixels - and software SPI can't be used either.

How about:

Thr 2019.01.17

'I2C? I2C can't be used for neopixels'

Bullet #3 in post #6 indicates I2S But, searching the Pixl.js page only brought up the references to I2C, so I made the (false) assumption that 'S' was a typo as I had gotten the Neopixels to illuminate while realizing software SPI isn't what is controlling the output as the testing in #4 above shows. Bullet #3 led me to understand it was I2C.

So, is an explanation for I2S (for Neopixels) needed for nRF52 chips in those pages as this (I2S) is a new mystery feature?

Note that I couldn't test the following as I didn't have an MDBT42Q at the time and as the Pixl has a 150ms limit on it's regulator and level shifting is required should I use Neopixels at 5V with an external supply, was stuck with what I could garner from the docs

from #7 'Does infinite I2C then mean more than one Neopixel string may be configured?'

This still doesn't answer the question as to the number of Neopixel channels(? strings?) for a single device when using Neopixels via software (nRF52).

ex: A Pico has 3 hardware SPI MOSI pins that could control three Neopixel strings and no ability via software SPI. But nRF52 via software?

The note at the Python build files show 1

'Reduce available hardware SPI/I2C instances to 1 on nRF52 (since this…'

and there isn't a reference to I2S there either.

So, would it be correct to say only one Neopixel string may be configured (using internal software I2S) on any pin for nRF52 chips?

IMO the table in #8 could have device by name descriptors to the far left as I indicated in #7 as I, and maybe others don't relate to the devices the same as designers do. Maybe that gets ironed out using them for five years? When using a device, I don't think I'm using my STM32 but think Pico, then look at the Pico.js page to see what processor it is to then determine whether hardware SPI is available, the same way I'm trying to learn what Pixl.js possesses.

You keep saying 'via software'. You can't control any neopixels via software on any normal Espruino device - because it needs hardware - either SPI/I2S/etc.

So, is an explanation for I2S (for Neopixels) needed for nRF52 chips in those pages

I don't think so. You can Google it if you want but most people won't care - they just care that it works, and works on any pin.

This still doesn't answer the question as to the number of Neopixel channels(? strings?) for a single device when using Neopixels via software (nRF52).

You can use any pin - so the number of strings is just the number of pins you have.

The note at the Python build files show 1

Yes. There's one hardware SPI, and as many software SPI as you want. But we're not using SPI so it's irrelevant.

the table in #8 could have device by name descriptors

Yeah, it was only left out to make it less of a burden to keep it up to date, but that could be added.