Am Montag, 12. Januar 2015 17:57:19 UTC+1 schrieb Charles Steinkuehler: > > Reads from GPIO pins are another matter. Since it is not possible to > post the reads, and the PRU (by design) doesn't execute instructions out > of order or perform speculative execution, the PRU core stalls after > issuing a read GPIO request until the data is returned from the > interconnect fabric (apx. 165 nS). >
The same happens for main core applications. When one reads a GPI-register to get the current input state value, the whole system is stalled until the read is finished. This also includes IRQs, none of them is delivered during that time. The only workaround (at least the only one I found to overcome this problem) is to set up interrupts for rising/falling edge of the inputs that have to be watched and read the input only when such an interrupt occurred. This makes the whole system much faster comparing to plain input polling but is not a guarantee: when an input changes very fast the system is slowed down again because many interrupts happen -> many reads of slow input state registers are done. -- 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.
