Re: [beagleboard] Re: GPIO Header Pins that can be muxed to the PRU
Ah -- thank you for the clarification. On Monday, December 1, 2014 6:35:15 PM UTC-6, Charles Steinkuehler wrote: 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. -- 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.
Re: [beagleboard] Re: GPIO Header Pins that can be muxed to the PRU
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: -- 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.
Re: [beagleboard] Re: GPIO Header Pins that can be muxed to the PRU
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.
Re: [beagleboard] Re: GPIO Header Pins that can be muxed to the PRU
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 karlkarpfe...@gmail.com 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+unsubscr...@googlegroups.com. 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: GPIO Header Pins that can be muxed to the PRU
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 karlkarpfe...@gmail.com 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
