pinMode changes mode on subsequent Neopixel write() in 2v00 causing Green first Neo in WS2812b strip

[espruino-discuss]

Posted at 2019-01-23 by Robin

Tue 2019.01.22

The following did not occur in 1V99 but is now repeatable in 2v00

From @allObjects and @MaBecker exchange in #65

http://forum.espruino.com/conversations/327299/?offset=50

setting the pinMode to 'output' should resolve the first Green Neo issue. I found that point interesting as I had written tons of Neopixel code in 1V99 and never witnessed the first Green Neo anomaly ever.

https://www.espruino.com/Reference#l__global_pinMode

Note that Not calling pinMode() first responds with the following default:

af_output - Digital output from built-in peripheral

and, consequently turns on the first Neo Green even when triplet 0,0,0 is sent for black

From the Note:

'If you want . . . to set the pin mode automatically . . . or with the 3rd 'automatic' argument set to true'

So setting to false should dis-able automatic then?:

pinMode(B15, "output", false);

Verified:

output - Digital output

but, subsequent calls to require("neopixel").write(B15, ar); toggle the state back to

af_output - Digital output from built-in peripheral

and, the first Neo in the string returns as Green. Not what we want.

Were there changes to the Neopixel module since 1V99 ?

[espruino-discuss]

Posted at 2019-01-23 by @MaBecker

Here you find the source code of jswrap_neopixel.c, there is a section for each board. Button History show the changes that where applied.

---

Posted at 2019-01-23 by @gfwilliams

It depends a little on the board what mode gets used, but the mode has to be af_output or af_opendrain for neopixel to actually work on STM32, because it has to use a hardware peripheral.

So yes, the pin mode will get changed, or neopixel won't work.

There haven't been any major changes to the neopixel code in a while, so I'm not convinced you're seeing a code change since 1v99. It might just be something electrical that's different like the voltage you're powering the board from.

It might be worth checking out http://www.espruino.com/Reference#l_neopixel_write :

Espruino devices tend to have 3.3v IO, while WS2812/etc run off of 5v. Many WS2812 will only register a logic '1' at 70% of their input voltage - so if powering them off 5v you will not be able to send them data reliably. You can work around this by powering the LEDs off a lower voltage (for example 3.7v from a LiPo battery), can put the output into the af_opendrain state and use a pullup resistor to 5v on STM32 based boards (nRF52 are not 5v tolerant so you can't do this), or can use a level shifter to shift the voltage up into the 5v range.

---

Posted at 2019-01-23 by Robin

Wed 2019.01.23

Thank you @gfwilliams for the clarification. I must concede that prior to 1V99 that I most likely never verified what the pin mode actually was after a pinMode(B15, "output", false); and a subsequent Neopixel write. Viewing the results now, indicate that the mode was in fact changing to 'af_output' and I hadn't realized that.

> ' something electrical that's different like the voltage you're powering the board from'

Same setup, powering the Pico from the laptop USB and the Neopixel string from a 2amp 5V wall charger. Since both are 5V devices, attempting the 'af_opendrain' with pull-up won't work as there is no level shift involved. Since I never had an issue previously, never needed to consider that.

Time to acquire a scope?

After another hour of testing, the Green first Neo has an interesting anomaly. When sending a short array size of length 24 (8 Neo*3) the anomaly is non-existent and the color is as expected. When sending a large array of 60 Neo's, the Green anomaly is always present. The cutoff is around an array of 16 Neo's, which is curiously a multiple of 2,4,8 etc nice binary multiples.

Could there be a blip in the SPI data stream when sending larger arrays?
I wonder if it might even be the result pulse that is being rounded and mis-interpreted?

May never get this solved and is most likely time to acquire a scope to now 'see' what is going on, as I noted from links in #50 of post

http://forum.espruino.com/conversations/327299/?offset=25

show that other competitor boards and different software have the same issue. So the Neopixel strip Ws2812 or 5050 daisy chained that are more likely the culprit.

I also now notice there is a bit of annoying flicker occurring when running full brightness. 2V00 Could there be a clearing of data before output or too long a reset pulse?

Maybe time to give up the purest solution and use @allObjects #51 leading and @MaBecker #35 waste Neo the solution.

Haven't attempted this with nRF52 yet.

---

Posted at 2019-01-23 by Robin

Older Espruino version first Green Neopixel anomaly update

Wed 2019.01.23    four hours later

Curiosity got the better of me and I reflashed to an older version.

And as I expected, the first Neo Green anomaly goes away! The first Neo never illuminates Green. This is as expected.

So, confirmed, there is something different for hardware SPI on a Pico (in this case 1V94 which works) in older versions, compared to 2V00 which causes the false first Green Neopixel in a WS2812b string.

I tried to get as close to 1V93 and 1V99 using the running list, but this was as close as I could locate

http://www.espruino.com/binaries/travis/54240e92f74840e9eccfbec431e2c3ae9951ae63/espruino_1v94.22_pico_1r3.bin

  "VERSION": "1v94.22",
  "BUILD_DATE": "Aug 30 2017",
  "BUILD_TIME": "23:02:10",
  "GIT_COMMIT": "54240e92f74840e9eccfbec431e2c3ae9951ae63",
  "BOARD": "PICO_R1_3",

When first powering the board, this is the default mode

getPinMode(B15)
="analog"

And confirmed as suggested in #3 does switch after a code 'send' is performed

getPinMode(B15)
="af_output"

No pull-up used in data line as both devices at 5V

---

Posted at 2019-01-24 by @gfwilliams

Since both are 5V devices, attempting the 'af_opendrain' with pull-up won't work as there is no level shift involved

Pico isn't a 5v device. The outputs are 3.3v - hence the need for the level shift mentioned in that link for STM32 devices like the Pico.

---

Posted at 2019-01-24 by @gfwilliams

Try running the Neopixels off a LiPo battery - that's the easiest way to test. The ~4v voltage still works fine with the pixels but the voltage allows the 3.3v signal from the Pico to get through correctly.

Also worth checking - are the grounds of the two power sources connected? That's another potential culprit of the first green LED.

While 1v94 may work for you, in the ~18 months since that version other people have used Neopixels with Espruino Pico (me included - I just did exactly that with a Pico running 2v01 to make sure yet again) and it works absolutely fine.

---

Posted at 2019-01-24 by @MaBecker

Or use the trick with the diode like mentioned here http://forum.espruino.com/comments/14506218/