Controlling WS2812 device (RGB LED strip)



  • @Sawyer-McBride We are working on a neopixel library. We've been wanting to release it earlier so people can decorate christmas trees with it, lol. It'll be finished soon! Stay tuned!



  • @Boken-Lin Now this im interested in! My wife has been looking at LED door weaths but I said I wanted to make one, possibly with an Arduino....but why not the omega! Get it in a "production" environment :smirk:



  • Ok, here's an update. To get the feels, here's a photo of my kids messing with LED strip color config, using their smartphones. Competing with their programming, how cool is that.
    12391246_933920329977828_6085505424817901751_n.jpg

    The device-tech stack:

    • 150 pixel RGB LED strip (similar to this one)
    • Arduino Micro talks WS2812 to the strip
    • Onion Omega talks to Arduino over TTY serial (custom protocol)
    • Custom Python module for talking the custom protocol over serial connection
    • Python script using BaseHTTPServer to allow the strip control over webservice
    • HTML+JavaScript interface with various controls that talks to the webservice
    • A web client (ie smartphone) where the interface is opened

    The LED strip, Arduino and Omega are all powered from one 5V 10A 50W power converter.

    Ideally, I'd like to top the stack with a Blockly -enabled coding tool that allows writing scripts for controlling the strip.



  • @Pavils-Jurjans Nice! We are working on getting Scratch to work with the Omega as a Console App. Blockly is very nice as well. It shouldn't be too different to add to the Console.



  • Scratch is a great way to introduce kids to programming, indeed. But unfortunately it is Adobe Flash based, and the trend is that Flash is bad (mainly due to security issues, but also because there are new better open standards like HTML5 to replace it), and it is being phased out. From what I can find, there appears to be no serious plan to migrate the Scratch platform to HTML5 right now. So, please consider twice before investing too much effort in this.



  • @Pavils-Jurjans That's a good suggestion. To keep the console future-friendly, it would make sense to put a higher priority on Blockly. We will get started on getting Blockly to work on the Console shortly.



  • There's another problem what I encountered with Blockly - it's the storage space. Even fairly minimal package is above 1MB. In my case, when I have Python installed, it was too much for the 16MB storage space.



  • @Pavils-Jurjans It might be necessary to extend the storage of the Omega with rootfs. For more information please check out this wiki: https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs.



  • @administrators Theres still no way to control ws2812 leds without needing an arduino too?



  • @Joseph-Sammarco We are still working on that. It's a bit harder than we thought, but we want it just as badly as you do, so we won't stop until it's done :)



  • @Pavils-Jurjans Did you see the post on hackaday, where some guy figured out a way to send precisely timed VGA signals to the led strip? It was pretty dope, and, if there is a way to send analog frequencies in the same manner over any combo of pins, it'd be interesting to simplify what you are doing to get it under the time constraints needed.

    Alternatively: precise digital timing could work.



  • Hi @Boken-Lin, have you seen the AR9331 kernel driver for WS2812 on github?

    I found this driver just now, in a second round of googling the topic in the evening - as my hardware is in the office, I could not try it yet.

    But before, I already spent the afternoon experimenting with bitbanging the WS2812 timing on the Onion and measuring the results on a scope.

    With interrupts disabled, the timing (350nS pulse for a 0 bit, 700nS for a 1 bit) can be met quite easily, especially when you know that the specified pause time between bit pulses (600/800nS) is a minimum, not an exact requirement, contrary to what the worldsemi datasheet says. The pause length must only be kept well below the reset time of 50µS.

    However, I found keeping the pauses reliably below 50µS is not possible without blocking the interrupts during the entire WS2812 chain update, which amounts to multiple milliseconds for an average 200 LED chain. Doing so will certainly ruin the accuracy of hrtimers etc. But apparently, one can usually get away with that - the ws2812_draiveris driver from github implements it that way.

    I'll try that driver tomorrow, however I'm a bit reluctant to actually using it, because I have other drivers relying on hrtimer accuracy in the 500µS range. Keeping IRQs blocked for so long is certainly not good kernel programming practice.

    On the other hand, are there any better options? To meet the timing without blocking IRQs, we'd need a DMA based solution. Maybe i2s or SLIC can be misused to produce the WS2812 timing somehow?



  • Update: In the meantime, I tried the ws2812-draiveris driver from github and it works fine on the Omega!

    For those who want to try - you can download a installable driver package from my server and install it via console on your omega (--force-depends may be needed -> experimental!):

    cd /tmp
    wget http://plan44.ch/downloads/experimental/kmod-ws2812-draiveris_3.18.29%2B0.1-9_ar71xx.ipk
    opkg install /tmp/kmod-ws2812-draiveris_3.18.29+0.1-9_ar71xx.ipk --force-depends
    

    To activate the device for 256 LEDs with data pin connected to GPIO7:

    insmod /lib/modules/3.18.29/ws2812-draiveris.ko gpios=7 leds_per_gpio=256
    

    If you had two separate chains of 120 LEDs each connected to GPIO7 and 8, it would be:

    insmod /lib/modules/3.18.29/ws2812-draiveris.ko gpios=7,8 leds_per_gpio=128
    

    Now there's a new device /dev/ws2812 available. To set the colors of the connected LEDs, just write a string with 3 bytes (R,G,B) for each LED to /dev/ws2812. Within the limits of ASCII-Values (32..126 = space..}) this can be tested with echo. The following sets the first three leds to slightly pale red, green and blue:

    echo "}!!!}!!!}" > /dev/ws2812
    

    To test the driver with more load, I ported (q&d) my messagetorch project, originally written for the spark core, to the Omega.
    This is a fire-like animation, intended to be shown on a WS2812 chain of ~200 LEDs, wound onto a tube:

    cd /tmp
    wget http://plan44.ch/downloads/experimental/messagetorch_0.1-1_ar71xx.ipk
    opkg install /tmp/messagetorch_0.1-1_ar71xx.ipk
    

    Assuming a "torch" with 18 windings of 13 LEDs each, start the torch with

    messagetorch -W 13 -H 18 "Hello Omega"
    

    See the github project for more information. In particular, you can post messages by sending UDP packets.

    messagetorch updates all LEDs approx every 25mS, and the driver locks IRQs for about 6mS for every update. Although blocking IRQs for so long is certainly bad, it does not seem to affect working with the Omega noticeably.

    Happy experimenting with WS2812 LEDs :-)



  • @administrators : Is the solution proposed by @Lukas-Zeller the one to follow to work with WS2812 and the first Omega, or have you been able to finish your neopixel library ?



  • @Lukas-Zeller : There is a dependency error now, when we try to install the opkg.
    It gives this :

    root@Omega-XXXX:/tmp# opkg install /tmp/kmod-ws2812-draiveris_3.18.29+0.1-9_ar71
    xx.ipk
    Installing kmod-ws2812-draiveris (3.18.29+0.1-9) to root...
    Collected errors:
     * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-ws2812-draiveris:
     * 	kernel (= 3.18.29-1-ec3c73d5690ecfdba6d7368603798b4e) * 
     * opkg_install_cmd: Cannot install package kmod-ws2812-draiveris.
    

    There probably has been some updates to the linux kernel since you posted, but I don't know how to lake it work.
    Thanks !



  • @Brice-Parent This is an issue that has been around for quite some time. Generally it means that the kernel version the package was compiled for does not match the kernel version on the Omega.
    This issue occurs for some other packages as well and has been drawn to the attention of the Omega guys though a resolution is still awaited.

    It may be worth trying the command opkg --force-depends install <package> to do the install ignoring dependency issues.
    This may work OK so long as the kernel differences are not significant for the package.



  • @Brice-Parent just use --force-depends as @Kit-Bishop suggests - indeed my build is for a slightly different kernel than the one in the official Omega image.

    AFAIK there's no way yet (due to a few missing files) to setup an OpenWrt build environment that exactly matches the official builds, so that's a problem we have to live with for now.

    The WS2812 driver is very simple regarding kernel infrastructure it uses, so the kernel version mismatch is not a problem here.

    The real problem one should be aware of when using this driver is that it blocks interrupts for several milliseconds when updating the LED chain (see my post above). This might break timing in other parts of the system - probably streaming audio would not work in parallel, and maybe it will also affect network performance.

    In my experiments with an Omega not doing much except nice LED animations, I didn't notice any side effects, though :-)



  • Hi...as per my knowledge the Omega has General Purpose and Watchdog timers that you should be able to use to get the timing down.However, an easier option might be to use the Arduino Dock since the ATmega can very precisely control its output timing with probably less hassle than the above. Then you can use the Omega to send the Arduino chip instructions on what colors to set and the Arduino chip will do all of the low-level stuff.

    pcba assembly



  • awesome work @Lukas-Zeller. should start saving for a big roll of ws2812 asap :)



  • [Updated because of confusion between WS2813 and APA102]
    @youlian-troyanov Before investing into WS2812 LEDs, you might want to check out WS2813 APA102!

    Only very recently a colleague told me about the WS2813 APA102, I wasn't aware of these before.

    The big advantage of the WS2813 APA102 is that it uses standard SPI protocol, which almost any SOC can generate without dirty tricks, including Omega1 and 2. In addition, the WS2813 APA102 seem to have a much higher PWM rate, which means that they are now suitable for POV (persistence of vision, fast moving LEDs e.g. mounted along fan blades creating the illusion of an image).

    That's what I've read and have been told so far - I just ordered a WS2813 based LED strip to try it out, hopefully it will arrive soon ;-)

    [Update: I meant to get the APA102, but I ordered WS2813 and so I got exactly these. Only then I found out about the confusion with the APA102, aka DotStar. The WS2813 also has two data lines, but the second is a backup line that keeps a chain working even when some LEDs fail. Otherwise, WS2813 uses the same data format as WS2812, with a few improvements: 2kHz PWM rate vs 400Hz, longer reset time of 250µS vs 50µS.]


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.