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

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-pin­s

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