On 8/24/2015 5:06 PM, Andrew P. Lentvorski wrote: > On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote: >> >> Regardless, note that the maximum toggle rate of a GPIO pin using the >> PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a >> write by the on-chip communication fabric (which means 80 nS period >> for a high/low toggle of the pin). This assumes the CPU and the PRU >> have similar bandwidth to the L4 fabric, which may or may not be the >> case (but I suspect is true). > > Do you have a pointer to the reference manual for this (if not, don't waste > a lot of time, I'll dig it out)? Given that this seems to be *very* > fundamental about understanding the architecture, I really probably need to > chase this down exactly.
Refer to Chapter 10 in the TRM, which is all about the interconnects (on-chip buses). The GPIO live on L4_PER (except GPIO0, which is on L4_WKUP) and are accessed via the L3S (L3 Slow clock domain). You can also see how the PRU and CPU tie into the interconnect (both tie to the L3F or Fast clock domain), and what peripherals they can access (both PRU and CPU can access the GPIO, no surprise there!). I haven't done real-world timing tests with the CPU, but the results of my real-world tests with the PRU are documented in the code I wrote for the Machinekit project: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165 Assuming the performance bottleneck is the actual GPIO (which seems likely), you should see similar performance metrics to the PRU when accessing the GPIO banks from the CPU. -- 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.
