Controlling WS2812 device (RGB LED strip)

Kit Bishop

@Pavils-Jurjans While I can't go in to long detail here (largely because I am not an expert in this) I would suggest you look at the Posix Threads library. This is available on the Omega and with this it is possible to created threaded code with timers.

If you are not familiar with Posix Threads, a couple of pointers that may help get you started:

Also a couple of references using Posix Thread based timers:

I am currently using Posix Threads with usleep calls to provide some timing capabilities.
However, my general preference is to use Java which has easy to use built in Classes for running timers and threads. You can run java on the Omega using Jamvm- I am writing Java wrappers to access the Omega GPIO so that I can stick with just using Java (see https://community.onion.io/topic/36/java-on-omega-with-wrappers)

Lazar Demin

@Pavils-Jurjans I've only done some light research into the Timers, don't have any code as yet. We are planning to create a NeoPixel library but that's sometime down the road.

I would say, try to experiment with the Posix Threads that @Kit-Bishop mentioned. I'll try to do some more research into the timers and get back to you in a few days.

Pavils Jurjans

Ok, I think I will move on with first driving the strip from Arduino Micro, connected to Omega via serial. That will get me started sooner, as I see the "hard way" requires some extra tinkering without guaranteed results too soon. But the lights must go up or it will be too late.

Once that fallback setup will be working, I will have the safety for tinkering with lower level Linux code where I don't feel so much at home.

Thanks for suggestions, and I will report back my results!

Chris Ward

@Pavils-Jurjans Have you looked into how it has been attempted on a RaspPi? There is this tutorial on Adafruit that uses a library that is using PWM and DMA. Might give you some ideas. https://learn.adafruit.com/neopixels-on-raspberry-pi/overview

Sawyer McBride

Was going to have a look at neopixels, have used the library mentioned to power a few neopixels from a RasPi for a project. In my project I had a powered hub so just took a 5v USB feed for the power.

Boken Lin

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

Sawyer McBride

@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

Pavils Jurjans

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.

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.

Boken Lin

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

Pavils Jurjans

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.

Boken Lin

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

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.

Boken Lin

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

Joseph Sammarco

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

Boken Lin

@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

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.

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?

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

Brice Parent

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

Brice Parent

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