pinMode changes mode on subsequent Neopixel write() in 2v00 causing Green first Neo in WS2812b strip
You are reading a single comment by @Robin and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Robin
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.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
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.