Also note that using GPIO0 pins is slower and more unpredictable that the 
other GPIO's, particularly with the TI kernel.   The power management stuff 
is in the interconnect as GPIO0 so anything that triggers any sort of PM 
activity can cause longer delays for any action with GPIO0.   In 
particular, the CPU idle state driver can add an extra 150ns or more delay 
to writing things to GPIO0.  You can limit that by using "cpupower idle-set 
-d 1" to disable the idle states that take a long time to transition in/out 
of, but it's still not perfect. 

Dan


On Tuesday, November 20, 2018 at 7:27:32 PM UTC-5, Charles Steinkuehler 
wrote:
>
> On 11/20/2018 6:08 PM, Gerhard Hoffmann wrote: 
> > 
> > Am 20.11.18 um 23:15 schrieb Mark A. Yoder: 
> >> 
> >>   Using the PRU interface is faster.  I think my students measured 
> >> it as being a couple times faster.  Using the PRU interface you can 
> >> toggle a pin every 5ns. 
> >> 
> >> 
> > Yes, R30/R31 is about 3 times as fast and more predictable. Going 
> > through the OCP interface 
> > 
> > has to wait sometimes if there is already CPU or DMA activity. 
>
> PRU writes to the direct I/O are 8 times faster than writing to a GPIO 
> pin via the OCP (40 ns for the GPIO vs. 5 ns for direct I/O).  Note 
> that while the write competes on the PRU side within 40 ns, it takes 
> about another 100 nS until the actual GPIO pin value is updated (this 
> is the time needed for the write transaction to flow through the 
> interconnect fabric and actually update the GPIO register). 
>
> Reads, however are much worse, since they are not posted by the 
> interconnect fabric and stall the PRU until the read value is 
> returned.  Reading from a GPIO pin via the OCP port takes apx. 165 ns 
> vs. 5 ns for a direct I/O read. 
>
> I did some tests and measurements of this when I was writing the PRU 
> code for Machinekit, and documented the details in some comments: 
>
>
> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165
>  
>
> -- 
> 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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c66e2e2a-1b84-40e5-8189-a6a0270a9c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to