The PRUSS can control the ADC subsystem. And the PRUSS can control all GPIO subsystems, so there’s no reason to control them from LINUX (host CPU). Instead control also the slow GPIOs from the PRU code.
Find example code for both, GPIO (over OCP master port = slow) and ADC in the source code of libpruio.
Yes. The PRU writes to GPIO pins are not particularly slow unless you
saturate the interconnect, but the writes are posted and happen a while
after the PRU executes them (apx. 100 nS later). Unless you need
critical timings between the direct PRU outputs and the GPIO pins, this
shouldn't be a problem.
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).
I have timing details in the comments of my PRU code for Machinekit:
Andy, there are two kinds of PRU GPIO writes, the direct ones, in which you write to the R30 register, and ones where you have to access the gpio subsystem, you only need to mux it to the PRU if you’re doing the direct method.
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.