1. Home
  2. Omega Talk
  3. Controlling WS2812 device (RGB LED strip)

Controlling WS2812 device (RGB LED strip)

  • B

    @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.

    0
  • Pavils Jurjans

    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.

    0 B Theodore Borromeo 2 Replies
  • B

    @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.

    1 J 1 Reply
  • J

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

    0 B 1 Reply
  • B

    @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 🙂

    0 luz 1 Reply
  • Theodore Borromeo

    @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.

    0
  • luz

    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?

    0 luz 1 Reply
  • luz

    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 🙂

    1
  • B

    @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 ?

    0
  • B

    @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 !

    0 K 1 Reply
  • K

    @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.

    0
  • luz

    @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 🙂

    0
  • I

    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

    0 luz 1 Reply
  • youlian troyanov

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

    0
  • luz

    [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.]

    1 Eric B 2 Replies
  • luz

    @Ira-Burns yes, the AR9331 in the Omega1 has some timers, but unfortunately (being designed for WLAN routers, not IoT) it does not have PWM outputs that can be controlled by these timers.

    Using the timers for generating interrupts does not work either because that's way too slow to meet the tight WS2812 timing. So for the Onion1, the only way to do it is blocking interrupts and then bit-banging output lines as the ws2812-draiveris driver does, or using the Arduino dock as you suggested.

    But I don't like spending room and power for operating a second, much inferior CPU, just to move the ugly stuff (block IRQs, bitbang data, there's no other way to do it on the Arduino either) outside.

    The Omega2's MT7688 chip however was designed for IoT and does have PWM outputs - I guess it will be possible to create a WS2812 driver using timers, PWM and DMA that works without blocking interrupts. We'll see when the Omega2 arrives…

    For the Omega1, using WS2813APA102 instead might be a elegant solution.

    0
  • youlian troyanov

    thank you @Lukas-Zeller. excellent advice, especially about pov, that's something i wanted to experiment with, you just read my mind 🙂

    0
  • Eric

    @Lukas-Zeller Great, looking forward to hear from your test. I'm planning to install lots of LED STRIP (Addressable) in my house but didn't find a low cost controller expendable to connect all my sensors until I saw Omega1. Now with Omega2 power and even cheaper with Led Strip WS2813 sound like a perfect match for my project. Did you also look at the SK6812 who support RGBW (True white not RGB composite which take way less power)?

    0 luz Alvin chan 2 Replies
  • luz

    @Eric I recently bought a SK6812 based strip but haven't found the time yet to try it out. Having RGBW should make these much more suitable for actual lighting, not only decoration. I will post a followup here once I have tried these, probably I'll do it along with the WS2813 tests.

    0 Alvin chan 1 Reply
  • B

    @luz : I'm really interested about your feedback about those WS2813 and the ability to use them directly from our Omegas. I've just order a few of them, but they'll be sent from China to Europe and won't arrive until a few weeks, so in the meantime, if you can make it work, I'd be glad to know how you did.

    And if not, or if you needed extra components, I'm all hears too!

    Thanks!

    0 luz 2 Replies
led 44 ws2812 6
Log in to reply
 

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