iontank / ThrowingBagels

ThrowingBagels is a modernization of the LEDScape software package to drive high quantities of RGB/W LEDs.
Other
15 stars 3 forks source link

Strange behavior with SK6812 (RGBW) LED strip #4

Open pixorama opened 2 years ago

pixorama commented 2 years ago

Thanks for sharing a great project! Everything works fine, but there is one problem that I cannot fix. I am using 14 channels of 512 pixels each. Approximately every 5-10 seconds, one random pixel flashes on each channel. This happens with both the multidemo and the led-udp.

Here is a video of this problem https://youtu.be/17IZaLhJxy8

My setup: 5 x Beaglebone Black (rev C) Debian GNU / Linux 10 (buster) Led strip SK6812 (RGBW)

Help me, Obi-Wan Kenobi. You're my only hope

RemyPorter commented 2 years ago

This is, unfortunately, a known issue. The root cause is that under newer linux kernels, using OCP to communicate between the PRU and the GPIO pins doesn't get prioritized the same way as it did under older kernels. The end result is that we can't meet our timing guarantees as consistently as we need to.

We're still experimenting with fixing that.

neversphere commented 2 years ago

What kernel version do you recommend with this project? Do you have any idea where this bug likely exists?

RemyPorter commented 2 years ago

We were testing with various in the 4.x series. It's specifically in the OCP connection with the memory bus- on 3.x kernels (using a different assembler) the kernel was out of the way enough that the PRU and the CPU could share memory efficiently. On 4.x kernels, there's a glitch every time the PRU needs to grab the next block of memory. I haven't been able to get the PRU/CPU thing sorted.

neversphere commented 2 years ago

Is there an ideal led length to minimize this or other tricks we can use?

On Wed, Jun 15, 2022, 1:02 PM Remy Porter @.***> wrote:

We were testing with various in the 4.x series. It's specifically in the OCP connection with the memory bus- on 3.x kernels (using a different assembler) the kernel was out of the way enough that the PRU and the CPU could share memory efficiently. On 4.x kernels, there's a glitch every time the PRU needs to grab the next block of memory. I haven't been able to get the PRU/CPU thing sorted.

— Reply to this email directly, view it on GitHub https://github.com/iontank/ThrowingBagels/issues/4#issuecomment-1156719741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBO4EQG6R63WHU3LRRJ3UTVPIED3ANCNFSM5HRFF2UQ . You are receiving this because you commented.Message ID: @.***>