• Tue 2019.01.22

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

    From @allObjects and @MaBe exchange in #65


    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.


    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);


    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


    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


      "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


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


    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/

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

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

Posted by Avatar for Robin @Robin