Controlling WS2812 device on Omega2 board
I have ported the above mentioned ws2812 driver in to latest SDK running kernel 4.14.
Driver source: https://github.com/jnweiger/ws2812_sprites/tree/master/carambola2/package/ws2812_draiveris/src
I haven't modified anything in the driver except #include <asm/uaccess.h> to #inlclude <linux/uaccess.h> as the asm/uaccess.h was throwing error of incompatibility.
After compiling it successfully for omega2, i am able to insert it successfully via insmod, the dmesg shows appropriate logs as well.
But when I try to write to glow LEDs(echo "}!!!}!!!}" > /dev/ws2812) it does not show any effect on the specified GPIO pin.
I am using GPIO 18 and my LED has 5 leds in it; I am following below sequence,
insmod ws2812_driveris.ko gpios=18 leds_per_gpio=5
echo "}!!!}!!!}" > /dev/ws2812
This does not have any effect on LEDs, LEDs are in Off state.
I am suspecting that the low level GPIO registers which are being written/read in the driver are not for Omega2.
Help me to understand this better!
Thanks in advance.
However I am able to access the GPIO 18 with sysfs interface, to make it hgh-low.
luz last edited by
ws2812_draiverisdriver is for the AR9331 SoC. This was used in the first Omega(1), that's what we've had at the time, and that's what I ported
ws2812_draiverisfor back in 2016.
Today's Omega2 family however are all based on MediaTek's MT7688 SoC, which is quite different hardware. So you ws2812_draiveris will never work on a Omega2.
But no worries - a much better solution than
ws2812_draiverisexists since 2017 for the Omega2, and has in fact become part of the official firmware -
p44-ledchain. It uses MT7688 PWM to generate the WS281x data without blocking IRQs. See this thread for the history how it came into existence.
The p44-ledchain README explains how to use it, and there are also a few other threads in this forum with some Q&A about WS281x and
happy LED hacking
@luz I got it from there only, Thanks.
p44-lechain is amaaaaazing! Makes using LEDs really easy. Thank you @luz
I have successfully ported ws2812_draiveris (https://github.com/plan44/ws2812-draiveris-openwrt-package) on our Omega2+.
The LED is working fine by echo'ing 3 bytes per LED. The below cause all 5 LED to turn on in Blue color.
insmod ws2812.ko gpios=18 leds_per_gpio=5 echo -e "\x00\x00\xFF\x00\x00\xFF\x00\x00\xFF\x00\x00\xFF\x00\x00\xFF" > /dev/ws2812
But at time, with the same echo command only 2 LEDs gets affected and after that event those LED behaves like that only. Even after giving command to turn off all the LED, 2 LEDs stays on. The command to turn On 5 LEDs in Green, only takes effect for these 2 LEDs, remaining LEDs stays off. Even re-inserting the driver doesn't help.
Does anyone know, if there is any glitch in the driver? or somehing to be related to hardware. I dont' have any doubts on hardware as its working fine at times.
luz last edited by luz
Hearing that you had similiar problems with the
ws2812-draiverisdriver as with my
p44-ledchain, I can conclude that the problem is most likely not the timing, but the hardware (missing level shifter?).
ws2812-draiverisalways meets the timing for the WS28xx - as you might have seen when porting it, it simply locks all interrupts and then bit-bangs the data.
While this is good for meeting the LED chip timing (and simple to code), locking interrupts for dozens of milliseconds is a cardinal sin in a Linux driver. On the original AR9331 CPU (Omega1), where
ws2812-draiverisoriginates from, this was the only way to get such SmartLEDs working at all, so
ws2812-draiverisis as good as it can get on that chip.
However, on the MT7688/Omega2 with its PWM units, the
p44-ledchainway to do it, without locking interrupts, is the way to go. And that works easily, at least with WS2813 or WS2815, with all 4 PWMs running in parallel with 1000 LEDs each.