Controlling WS2812 device (RGB LED strip)
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!
@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
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.
@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.
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
- 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.
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.
@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.
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 :-)