Ok, thank you for the feedback Daniel. However, I think I will stick by the PRU interface, to ensure that no data is loss.
-- Fred Gomes Daniel Kulp <[email protected]> escreveu no dia quinta, 22/11/2018 à(s) 23:19: > Also note that using GPIO0 pins is slower and more unpredictable that the > other GPIO's, particularly with the TI kernel. The power management stuff > is in the interconnect as GPIO0 so anything that triggers any sort of PM > activity can cause longer delays for any action with GPIO0. In > particular, the CPU idle state driver can add an extra 150ns or more delay > to writing things to GPIO0. You can limit that by using "cpupower idle-set > -d 1" to disable the idle states that take a long time to transition in/out > of, but it's still not perfect. > > Dan > > > On Tuesday, November 20, 2018 at 7:27:32 PM UTC-5, Charles Steinkuehler > wrote: >> >> On 11/20/2018 6:08 PM, Gerhard Hoffmann wrote: >> > >> > Am 20.11.18 um 23:15 schrieb Mark A. Yoder: >> >> >> >> Using the PRU interface is faster. I think my students measured >> >> it as being a couple times faster. Using the PRU interface you can >> >> toggle a pin every 5ns. >> >> >> >> >> > Yes, R30/R31 is about 3 times as fast and more predictable. Going >> > through the OCP interface >> > >> > has to wait sometimes if there is already CPU or DMA activity. >> >> PRU writes to the direct I/O are 8 times faster than writing to a GPIO >> pin via the OCP (40 ns for the GPIO vs. 5 ns for direct I/O). Note >> that while the write competes on the PRU side within 40 ns, it takes >> about another 100 nS until the actual GPIO pin value is updated (this >> is the time needed for the write transaction to flow through the >> interconnect fabric and actually update the GPIO register). >> >> Reads, however are much worse, since they are not posted by the >> interconnect fabric and stall the PRU until the read value is >> returned. Reading from a GPIO pin via the OCP port takes apx. 165 ns >> vs. 5 ns for a direct I/O read. >> >> I did some tests and measurements of this when I was writing the PRU >> code for Machinekit, and documented the details in some comments: >> >> >> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165 >> >> -- >> Charles Steinkuehler >> [email protected] >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/2M6ae9KCfiM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/c66e2e2a-1b84-40e5-8189-a6a0270a9c7c%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/c66e2e2a-1b84-40e5-8189-a6a0270a9c7c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAJHs20zrHakdm0v3LBU-uK0_UPUa_-Z5hqRnsvzxEDEV6NWbiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
