Wow... You should have contact us before doing a lot of that. I completely re-wrote most of the LEDScape code over the last couple years to completely optimize things in attempts to reduce some of the timing issues. Porting to clpru and rproc was already part of that. All my updates are in FPP ( https://github.com/FalconChristmas/fpp ).
Anyway, to answer your question, the issue is specific to GPIO0. GPIO1-3 is not affected by the massive latency issues. Thus, the best option is to chose GPIO pins on GPIO1-3 and not use the GPIO0 pins. That wasn't an option for me as we needed to output 48 strings. In the FPP code, if nothing is using the second PRU (the second PRU could be used for DMX or pixelnet output), we divide the work and have one pru do the GPIO1-3 and the other do the GPIO0. If something IS using the other PRU, and the strings are short enough, then we split it on the one pru and do GPIO1-3 first, then do the GPIO0's. For the most part, that keeps the GPIO0 problems from affecting all the strings so the random flashes would really just be on the GPIO0 strings. In the case where the second PRU is used for something else AND the strings are longer, then we do have to do all 4 GPIO's at once and all of them can be affected so it's definitely not a perfect solution. To minimize the issues (but not entirely eliminate) I do now build a custom 4.19 kernel that disables most of the devices on the L4_WAKEUP interconnect. Any power management and frequency scaling stuff causes huge issues with GPIO0 latencies so those are the most important things to disable. I think my notes are at: https://github.com/FalconChristmas/fpp-linux-kernel/tree/master/bbb-kernel Not sure if that helps enough for you. Feel free to ask more questions. :) Dan On Tuesday, March 23, 2021 at 1:45:51 PM UTC-4 Remy Porter wrote: > For those that may remember the old LEDScape library, I've been working on > an updated version of that library, which focuses on strips instead of > matrices, uses rproc instead of UIO PRUSS, and updates the PRU assembly to > clpru from pasm. > > Link: https://github.com/iontank/ThrowingBagels > > The key thing you need to know is that we hook up 32 addressable LED > strips and then use the PRU to bitbang out RGB(W) data. We use the PRU > because our timings need to be pretty precise- a few hundred nanoseconds > for each key phase of the operation. > > Here's the important issue: we need to address all 32 GPIO pins from the > PRU, but not all of them are bound to the r30 register. So we need to go > through the OCP port. This is exactly how LEDScape worked, and continues to > work, just fine. We've never been able to get LEDScape working under 4.x > kernels, mostly because of UIO problems (which is what kicked off this > whole "move to rproc" thing). > > My upgrade, ThrowingBagels, uses basically the same core logic on the PRU, > just ported to clpru assembly and running on a 4.19 kernel. And seemingly > randomly, the timings hitch which causes the LEDs to flicker to the wrong > color. Phases of our bitbang operation will sometimes take almost twice as > long as they should- a sleep that should have been 600ns ends up taking > 1100ns. The only operation happening that doesn't have guaranteed timings > is writing to the GPIO pins via OCP, everything else we do happens entirely > in PRU DRAM. Since this appears to happen randomly, the hitch *must* be > coming from that OCP step, I assume. > > In support of that hypothesis, if I upgrade from the kernel that ships > with the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher > <https://debian.beagleboard.org/images/bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz>" > > image to the most recent 4.19 kernel, the problem becomes a lot more > infrequent. We're blasting this data out at 30fps, like video, and when cut > down on the number of services running and update the kernel, I can get the > glitches down from happening every few seconds, to happening every few tens > of seconds. > > My suspicion, and I can't quite prove anything, is that on 4.19 there's > something about the kernel or configuration that sometimes adds latency to > OCP writes, which wasn't there on 3.16. So my key question is: how do I > improve the timing consistency when the PRU uses OCP to write to DDR RAM? I > understand that it will never have *guaranteed* timing, but sometimes > it's hitting me with latencies of up to 500ns. Anything I can do to > minimize that latency would be a huge help. > > TL;DR: how can I make PRU->OCP->GPIO more consistent in its timing under a > 4.19 kernel? > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bd1a7981-8baa-42d4-b418-47087ba05699n%40googlegroups.com.
