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

Tue 2019.01.22

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

From @allObjects and @MaBe 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__gl­obal_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 ?

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.

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_neop­ixel_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.

Wed 2019.01.23

Thank you @Gordon 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 @MaBe #35 waste Neo the solution.

Haven't attempted this with nRF52 yet.

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": "54240e92f74840e9eccfbec431e2c3ae9951ae6­3",
  "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

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.

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.

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