No announcement yet.

NeoPixel possible?

  • Filter
  • Time
  • Show
Clear All
new posts

  • NeoPixel possible?

    There are a bunch of relatively low cost one wire controllable RGB LEDs on the market now ( for instance: ). These devices have a high speed one wire interface requiring sub-microsecond (+/- 150nsec) accuracy. Specifically:

    0.4usec High + 0.8usec Low -> 0 bit
    0.8usec High + 0.4usec Low -> 1 bit

    do this 24 times in a row to transfer 24 bits of RGB data per light.

    50usec low voltage condition activates new light states.

    It's an elegant system so I'm just wondering if there's any subsystem on the Picaso based systems that would allow controlling these lights? SPI maybe? There are some FTDI chips with a bit-banging mode which can use a UART to drive the line (at about 8MHz to get the correct timings). It looks like there's no way to run your UARTs that fast (plus I don't think I could make the fixed 10 bit time 8N1 setup work anyway). Could I possibly bit-bang the GPIO fast enough to manage this? Are any of the other Intelligent display module controllers capable to managing these lights?

    (In case it's important the relevant spec sheet can be found here: )

  • #2
    No, sorry, I can't imagine any way you could drive these directly.

    I see some people are using dedicated Pics, maybe that's the way to go (using a serial interface to the PIC to send it 'configurations')


    • #3
      Hmm, maybe have a read of this.

      Unfortunately you still wont be able to bitbang it through GPIO, or use serial.


      • #4
        We'll be looking at adding a function to Diablo to handle these in the near future


        • #5
          I'm currently using the uLCD-32PTU to emulate various older monochrome LCD interfaces, but would definitely consider upgrading to the uLCD-35DT so I could attach and control these lights. Please let me know if/when you get this working.


          • #6
            What sort of array are you using, or considering using?

            There's a strip of 8 sitting on my desk doing all sorts of useless patterns as we speak.

            Got a sample of prettier ones


            • #7
              I'm currently evaluating long strips of the 60 lamps/meter for error and item tracking in our production lines (specifically these: ), so that's what I'd probably target. It looks like the 35DT sinks a maximum of 200mA, so on a 500mA USB supply I could run at least 5 of the lights without extra power provisions (each light draws a max of 60mA @ 5V). I'd probably create a custom bezel of translucent white plastic and use it as a diffuser for a small strip inside the top edge of the bezel. At 17mm spacing the outside two lights would be 68mm apart, placing them just inside the 35DT's 77mm viewing area. They could be used for softkey prompting or blinked in various colors/patterns for status indications and drawing operator attention.


              • #8
                So I now have five of the uLCD-35DT units on my desk which I'll be setting up sometime next week for life cycle testing. Any information on how to wire/control these lights?


                • #9
                  The new release should be getting released soon. I think I'll email you some stuff just to make sure you get it soonest.


                  • #10
                    I finally got back to this today and the API works like a charm. Very nice. I'll let you know if I notice any oddities with that.

                    I am getting some odd behaviors with your color picker 4dg. I can see it draw the initial "Mounting..." text, then the first draw of the rainbow image, but then it immediately sets the whole screen to grey. The color selection area works, but the intensity picker (right side) gives very odd behavior (like the color bits get scrambled when I use it). The NeoPixel565 app that you suggested works exactly as expected, so the API is clearly working.

                    Thanks for the preview.


                    • #11
                      Is this the 'NeoPixelColourPicker' or the somewhat different 'colorpicker' program?


                      • #12
                        NeoPixelColorPicker.4Dg from the files you provided. The NeoPixelColorPicker.4DViSi does the same. I seem to get this same behavior after the first call to NP_Write: The whole screen is washed with white (maybe a bright gray) tone. The panel is still operating (I can press the touch screen and get expected behaviors) but no art is visible. As a test I put this code in place of my typical screen saver timeout in one of my projects:

                        var pixel[5];
                        var i;
                        for(i := 0; i< 5; i++)
                        pixel[i] := GREEN;
                        NP_Write(PA12, pixel, 5, NP_565, 0, 1, 0); // NeoPixel on PA0

                        When the screen saver times out (30 seconds of non-touch and no serial keep-alive messages) this runs and the moment I hear the sound the screen wipes to white. After the 5 second delay I can interact with the touch screen and hear expected button click sounds and get serial traffic, but no further screen updates occur. If I comment out the NP_Write call the screen behaves normally.

                        This doesn't, by chance, have to do with me using PA12 rather than PA0 does it? Yes, I did change your applications to use PA12 (because the first one worked there).
                        Last edited by Speed8ump; 7 November 2014, 02:19 PM.


                        • #13
                          With a little further investigation, PA0-PA3 don't have the screen effect, but the others (PA4-PA13) do (your documentation lists PA14 & 15 as not available for this. I'm working on fixing my wiring harness to give me the (missing) inch of wire to reach PA0 so I can ensure it is fully operational.


                          • #14
                            Hmm, weird, we'll investigate


                            • #15
                              PA0-PA3 work correctly.