From what I can tell, there are just a few pins on the expansion headers that can be mapped into R30/R31 of the PRU units.
If you are using the LCD or HDMI (I'm using 4DCape-43T) and eMMC, most of the pins are allocated.
PRU0 has 7 pins for direct mapping
PRU1 has 1 pin for input only.
Header pin : PRU? outreg-bit, inreg-bit - usage
P9-31: PRU0 R30-0, R31-0 - available for use
P9-29: PRU0 R30-1, R31-1 - available for use
P9-30: PRU0 R30-2, R31-2 - used by LCD
P9-28: PRU0 R30-3, R31-3 - available for use
P9-42: PRU0 R30-4, R31-4 - available for use
P9-27: PRU0 R30-5, R31-5 - used by LCD
P9-41: PRU0 R30-6, R31-6 - available for use
P9-25: PRU0 R30-7, R31-7 - available for use
P8-12: PRU0 R30-14 - used by eMMC
P8-16: PRU0 R31-14 - used by eMMC
P8-11: PRU0 R30-15 - used by eMMC
P8-15: PRU0 R31-15 - used by eMMC
P9-24: PRU0 R31-16 - used by LCD
P9-41: PRU0 R31-16 - available for use
P8-45: PRU1 R30-0, R31-0 - used by LCD
P8-46: PRU1 R30-1, R31-1 - used by LCD
P8-43: PRU1 R30-2, R31-2 - used by LCD
P8-44: PRU1 R30-3, R31-3 - used by LCD
P8-41: PRU1 R30-4, R31-4 - used by LCD
P8-42: PRU1 R30-5, R31-5 - used by LCD
P8-39: PRU1 R30-6, R31-6 - used by LCD
P8-40: PRU1 R30-7, R31-7 - used by LCD
P8-27: PRU1 R30-8, R31-8 - used by LCD
P8-29: PRU1 R30-9, R31-9 - used by LCD
P8-28: PRU1 R30-10, R31-10 - used by LCD
P8-30: PRU1 R30-11, R31-11 - used by LCD
P8-21: PRU1 R30-12, R31-12 - used by LCD
P8-20: PRU1 R30-13, R31-13 - used by LCD
P9-26: PRU1 R31-16 - available for use
I was hoping to get 10 pins (8 out, 2 in) mapped to PRU0 registers for fast access.
Will I have to use memory mapped access to get 10 GPIO pins?
Are there tricks to the PRU pin mapping I'm missing?
The CPU ball mapping is hard coded in the AM335x logic, no tricks AFAIK.
Your list seems to be OK (I didn’t check all details). There’re just a few header pins usable for PRUSS low latency GPIO, when LCD isn’t disabled. All other GPIOs can get accessed over the OCP master port with 2 or 3 cycles of latency.
Instead of memory mapped access (from the host) I recommend to consider controlling the GPIO subsystems directly by the PRU. Find some example code in the package libpruio.
I believe the pins on P8 (11/12/15/16) that you’ve listed as used by the eMMC are free to use. I’d double check the schematic, but think the eMMC is connected as per the mode1 pinmux.
I think that’s from an old SRM. Section 8.1.2 of the current (rev C.1) BBB SRM shows different pins and there is note of a correction in the change history…
Charlie Steinkuehler researched this and it turns out that it's
complicated: the hardware is pipelined and the actual latency numbers
depend on the burst length and the general system state when going
through the L4 GPIO:
You can get up to 11 output pins for PRU0 (most of which can also be
used as input pins), and two dedicated input pins while still keeping
the HDMI/LCD and eMMC functional. I have a spreadsheet with the PRU
pins highlighted (along with a bunch of other pinmux information and
details related to various CNC capes) in github:
Yes, the latency for PRU access to the GPIO pins is substantially higher
than 2 or 3 (PRU) cycles. If you're doing writes, they get pipelined,
so as long as you're not saturating the L4 interconnect (or competing
with some other resource that *IS* saturating L4), the PRU write will
complete in 2 clock cycles (on the PRU side), but it will take about
another 100 nS before the write is actually seen at the GPIO output pin.
The PRU can continue executing instructions in the ~100 nS it takes for
the write to actually show up at the GPIO pin.
Reads always take about 165 nS, and the PRU stalls while waiting on the
return data.
Details start at line 135 in the file linked by Przemek:
Not exactly, but that's what you'd get if you just did a read of the
GPIO input register from the PRU. If you want to go faster, you have a
few options:
* Use the direct PRU inputs (reads complete in 5 nS with no wait states)
* DMA data from the GPIO input register to the PRU. I haven't tested
GPIO read latency when using DMA, it might be faster than doing reads
with the PRU, and at the very least you wouldn't be stalling the PRU
while the read is "in flight".
* You might be able to read with both PRUs in lock-step but opposite
phase, so you could get apx. 12 MHz updates (untested).
...but really, if you want speed, use the direct PRU I/O pins, that's
what they're for.
I’m using PRU0 and need to read the state of two switches. I thought from the SRM Rev C.1 that I would be able to use P9_24 and P9_26 for these inputs. I can use them from the ARM Host side just fine but I need to use them with PRU0. I cannot get them to read with PRU0. Just to check my code, I connected one of the switches to P9_25, configured it as pruin and can read it fine with PRU0.
