Not exactly, but that's what you'd get if you just did a read of the GPIO input register from the PRU. If you want to go faster, you have a few options:
* Use the direct PRU inputs (reads complete in 5 nS with no wait states) * DMA data from the GPIO input register to the PRU. I haven't tested GPIO read latency when using DMA, it might be faster than doing reads with the PRU, and at the very least you wouldn't be stalling the PRU while the read is "in flight". * You might be able to read with both PRUs in lock-step but opposite phase, so you could get apx. 12 MHz updates (untested). ...but really, if you want speed, use the direct PRU I/O pins, that's what they're for. On 12/1/2014 5:57 PM, Curt Carpenter wrote: > Are you saying that the maximum realizable GPIO *input* rate to the PRU is > about 6MHz Charles? > > On Wednesday, November 26, 2014 9:56:21 PM UTC-6, Charles Steinkuehler > wrote: >> >> 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 <karlka...@gmail.com >> <javascript:>> 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 beagleboard...@googlegroups.com <javascript:>. >>>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net <javascript:> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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. For more options, visit https://groups.google.com/d/optout.
