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 <[email protected] > <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 [email protected] <javascript:>. > >> For more options, visit https://groups.google.com/d/optout. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- 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.
