New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
led-chain – Flickering with Omega2 and WS2812 #3
Comments
Hi Benjamin, if you are using more than one ledchain device, then the version you are using is definitely outdated - I found and fixed a bug in the interrupt handling that causes massive flickering when more than one chain is used at the same time. How did you connect the chain? Directly or via a level shifter? Without level shifter, flickering or not is a matter of luck and tiny differences in supply voltage (I had a case like: 4.99V works, 5.03V it doesn't). I really recommend a level shifter. Have you checked the driver's statistics ( BTW: Onion has includes p44-ledchain in their Omega2 PRO firmware, and now that OpenWrt v18.06 is also available for the other Omegas, I guess p44-ledchain should be there as well. Lukas |
Hey, thanks for catching up so fast. I always only used one actual "device" (as in Thanks for pointing out the new release – I did upgrade the firmware when starting with this project, but had to google around a bit to find out that I needed to upgrade to I tried that, but still no luck unfortunately: The statistics show a lot of "retries" and some errors, but I don't know how to interpret these numbers:
I tried it both without and with a level shifter and even with running the LED strip directly on 3v3 (don't know if that should work, but at least logic level shouldn't be a problem then ;-) ). Funny enough it's always the same strange behaviour. I'll still order an actual Thanks again, |
Hi Benjamin, I dug in my LED box to find some old WS2812 strips to do some experiments myself. It turns out that the assumption about the max pause time between bits a WS2812 would not yet interpret as a chain reset can be lower than what the driver assumed (10µS). When this happens, the update flickers badly, because the chain resets in the middle of the update. To fix that, I added an optional parameter Have a look at the updated README.md, it explains the new settings and also the meaning of the statistics info. Lukas |
BTW: you can find a built version here |
Hey Lukas, thanks a lot for that huge effort of digging into this! I tried to load the module you provided directly (from the link above).
…while your module build apparently requires I'm not sure how to go on from here… Btw when getting device info right after
Best, |
hmm. strange. I don't think it's the kernel version, I've tested it yesterday on a 4.14.63 build with --force-depends. About where 4.14.95 comes from - I'm not using Onion's firmware, but my own OpenWrt builds, and these are now on OpenWrt v18.06.2 with 4.14.95 kernel (whereas Onion is currently on v18.06.1 AFAIK). |
Hey,
Running It does show the following when doing
I don't know if there are any other logs available on the Omega. Next thing would probably be to try to read the serial/uart console somehow, but I'll only get to try that next weekend or so. Uninstalling your package and re-installing the original one from the onion sources makes the ledchain device basically work again, but with these flashes/false updates. |
Hello again, Today I managed to connect to serial console and read it's output. There is an error happening when doing I uploaded the full output here: https://gist.github.com/bennigraf/3d4207e0178f1b48b9c9152a11b55f6f In the call trace it points to Best and thanks, |
Thanks for the console log. This looks very much like a memory corruption issue. Especially I remembered your earlier observation about the strange data readouts when doing I looked into the code and I see no way how these variables could be anything but zero right after initialisation. The device struct where they reside is allocated with kzalloc(), which zeroes the entire area. So getting anything but zero for these statistics before doing any write to I see no way how p44-ledchain's own code could be doing that. I also have a hard time to believe that this could be a specific kernel dependency on 4.14.81. I rather suspect that the current onion kernel (or libaries with direct physical memory access in the onion fw) contains something that interferes with p44-ledchain. So to narrow down the problem:
|
Hello again, TLDR: I've built an ipk of the updated version of plan44/p44-ledchain (which provides Regarding your questions:
Since you went out of your way to provide an updated version of p44-ledchain that successfully drives my shabby WS2812 and I have a working build of it now, we can close this issue in my opinion. But I'll leave it up to you, in case you have further questions or want to dig deeper into this issue above. Best and thanks a lot, |
Thanks a lot for your work! And thanks for providing the build for current OnionOS! I think we can safely assume now that p44-ledchain code is ok, but running a kmod with another kernel version than the one it was built for is not. Not that we didn't know that already ;-) But still, I was surprised aboout such strange side effects. Probably I was misguided by thinking only about the kernel APIs as such (none of those used by p44-ledchain have changed from 4.4.61 to 4.14.81 to 4.14.95). However, what is very likely to cause memory corruptions is when a kernel data struct changes its size, as kmod code uses Lesson learned! I agree that we can close this issue now - thanks to your verification. |
Hey Lukas,
first off, thanks for open sourcing all this stuff!
I'm trying to run some ws2812 LEDs with a Onion Omega2, but have some trouble controlling them. Especially when writing data to
/dev/ledchain0
at higher framerates (> 2fps), I get a lot of flickering/flashes (apparently wrong data pushed to the LEDs, since they keep the wrong color until the next update). Often they're at the correct color but fully turned on instead of dimmed, sometimes color's completely off.I'm trying to write to that file via python right now, but the same issues happen when using
echo -en …
directly from CLI.Strangely the last LED always lights up correctly – no matter how many LEDs I use in total. I tested with between 1 and 30 LEDs on two different strands.
Is that a known problem with the apparently demanding timing of the 2812 LEDs or could there be a different issue with how I use the driver? Do you have any ideas or maybe encountered a similar situation?
I'm using
kmod-p44-ledchain_4.4.61+0.9-2_mipsel_24kc
that I downloaded from plan44.ch (found a link in some forum thread...)I'd appreciate any ideas on how to debug this.
Best,
Benjamin.
The text was updated successfully, but these errors were encountered: