Beaglebone PRU - GPIO and ADC

AndyS · January 3, 2015, 8:40pm

Hi Jason,

I am about to embark on some PRU GPIO coding for a small project I have in mind. I have been trying to watch as much of your YouTube seminars of the Christmas Break as I can.

I have been looking at your presentation slides and am puzzled with Slide 25 “PRU low-latency I/Os”. I notice that a couple of the pins are suffixed with ‘PRU1_16 in’ and 'PRU0_15 out 11 ---- 12 PRU0_14 out ’

What is the significance of the in and out?

Can the other GPIO pins be accessed by the PRU?

Also can you point me at any examples which use the Analogue Inputs in the PRU ?

DTJF · January 9, 2015, 9:11am

I’m not Jason. I’ll answer, though.

I have been looking at your presentation slides and am puzzled with Slide 25 “PRU low-latency I/Os”. I notice that a couple of the pins are suffixed with ‘PRU1_16 in’ and 'PRU0_15 out 11 ---- 12 PRU0_14 out ’

What is the significance of the in and out?

Can the other GPIO pins be accessed by the PRU?

A GPIO operates in a direction, either output or input. It’s possible to change the direction at run-time.

All GPIO subsystems can get controlled over the OCP master port (2-3 PRU cycles latency).

Low latency GPIO can get controlled directly by the PRUSS at 100 MHz. Maximum 14 header pins are available on PRUSS-0 (when HDMI is disabled).

Also can you point me at any examples which use the Analogue Inputs in the PRU ?

Find examples in the source code of libpruio.

BR

Charles_Steinkuehler · January 9, 2015, 2:08pm

I'm not Jason. I'll answer, though.

I have been looking at your presentation slides and am puzzled with Slide 25

"PRU low-latency I/Os". I notice that a couple of the pins are suffixed
with 'PRU1_16 in' and 'PRU0_15 out 11 ---- 12 PRU0_14 out '

What is the significance of the in and out?

In and out for the PRU pins indicates the direction of the signal. The
PRU direct I/O have unique buses for the input and output signals, so
(for instance) a pin that can function as a direct PRU output cannot
necessarily also function as a direct PRU input.

The pins are labeled with the PRU core they are connected to (PRU0 or
PRU1) and the register/direction they support (R31 = Inputs, R30 = outputs).

Can the other GPIO pins be accessed by the PRU?

A GPIO operates in a direction, either output or input. It's possible to
change the direction at run-time.

All GPIO subsystems can get controlled over the OCP master port (2-3 PRU
cycles latency).

There's significantly more overhead than 2-3 cycles. You only see 2-3
cycles of latency for the first few posted writes. Sustained writes or
any reads have significantly longer latencies:

github.com

machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L135-L163


      
          .entrypoint START
          
          // PRU GPIO Write Timing Details
          // The actual write instruction to a GPIO pin using SBBO takes two 
          // PRU cycles (10 nS).  However, the GPIO logic can only update every 
          // 40 nS (8 PRU cycles).  This meas back-to-back writes to GPIO pins 
          // will eventually stall the PRU, or you can execute 6 PRU instructions 
          // for 'free' when burst writing to the GPIO.
          //
          // Latency from the PRU write to the actual I/O pin changing state
          // (normalized to PRU direct output pins = zero latency) when the
          // PRU is writing to GPIO1 and L4_PERPort1 is idle measures 
          // 95 nS or 105 nS (apparently depending on clock synchronization)
          //
          // PRU GPIO Posted Writes
          // When L4_PERPort1 is idle, it is possible to burst-write multiple
          // values to the GPIO pins without stalling the PRU, as the writes 
          // are posted.  With an unrolled loop (SBBO to GPIO followed by a 
          // single SET/CLR to R30), the first 20 write cycles (both 
          // instructions) took 15 nS each, at which point the PRU began

This file has been truncated. show original