GPIO Header Pins that can be muxed to the PRU

[Peter Gregory]

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?

Thanks

[TJF]

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.

[Jon E]

Hi,

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.

Jon.

[Peter Gregory]

That would be sweet!

That would give me 10 pins exactly on PRU0

I was basing my info on the Beaglebone Black reference manual.

[Jon E]

Hi,

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..

Regards,

Jon

[Karl Karpfen]

Am Dienstag, 25. November 2014 16:11:52 UTC+1 schrieb TJF:

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.

According to http://e2e.ti.com/support/arm/sitara_arm/f/791/p/384515/1356079.aspx the latency is much higer. For PRU-mapped GPOs there are two cycles (of 200 MHz of PRU), for GPOs accessed via global address space it is even more higher.

[Przemek Klosowski]

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:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Charles Steinkuehler]

On 11/24/2014 1:57 PM, Peter Gregory wrote:
>
> 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?

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:

https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods

The PRU0 pins are highlighted purple (output) and cyan (input).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

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:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L135-L163

--
Charles Steinkuehler
cha...@steinkuehler.net

[Curt Carpenter]

Are you saying that the maximum realizable GPIO input rate to the PRU is about 6MHz Charles?

[Charles Steinkuehler]

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.

On 12/1/2014 5:57 PM, Curt Carpenter wrote:
> Are you saying that the maximum realizable GPIO *input* rate to the PRU is

>>>> email to beagleboard...@googlegroups.com <javascript:>.

>>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Charles Steinkuehler

>> cha...@steinkuehler.net <javascript:>
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[Curt Carpenter]

Ah -- thank you for the clarification.