Yes, the latency for PRU access to the GPIO pins is substantially higher than 2 or 3 (PRU) cycles. If you're doing writes, they get pipelined, so as long as you're not saturating the L4 interconnect (or competing with some other resource that *IS* saturating L4), the PRU write will complete in 2 clock cycles (on the PRU side), but it will take about another 100 nS before the write is actually seen at the GPIO output pin. The PRU can continue executing instructions in the ~100 nS it takes for the write to actually show up at the GPIO pin.
Reads always take about 165 nS, and the PRU stalls while waiting on the return data. Details start at line 135 in the file linked by Przemek: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L135-L163 On 11/26/2014 11:35 AM, Przemek Klosowski wrote: > Charlie Steinkuehler researched this and it turns out that it's > complicated: the hardware is pipelined and the actual latency numbers > depend on the burst length and the general system state when going > through the L4 GPIO: > > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p > > On Wed, Nov 26, 2014 at 7:11 AM, Karl Karpfen <[email protected]> wrote: >> >> >> Am Dienstag, 25. November 2014 16:11:52 UTC+1 schrieb TJF: >>> >>> There're just a few header pins usable for PRUSS low latency GPIO, when >>> LCD isn't disabled. All other GPIOs can get accessed over the OCP master >>> port with 2 or 3 cycles of latency. >> >> >> According to >> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/384515/1356079.aspx the >> latency is much higer. For PRU-mapped GPOs there are two cycles (of 200 MHz >> of PRU), for GPOs accessed via global address space it is even more higher. >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. -- Charles Steinkuehler [email protected] -- 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]. For more options, visit https://groups.google.com/d/optout.
