BeagleBone PRU Pins

[Gregory Perry]

Hi Gerald,

I happened across this handy spreadsheet today, which maps out the BeagleBone's Expansion Header PRU GPIO:

https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0

Am I correct in assuming that 28 pins on the BeagleBone's expansion headers can be used for GPIO output (controlling servos, toggling LEDs etc)?

Is the PRU able to control 28 pins concurrently, and what would the performance impact be for attempting that with all 28 pins?

[Gerald Coley]

The PRU pins are mostly scattered and as such have no real value. The most that you can use that are controlled in one group is 8. That was the reason I added two additional pins on top of other pins was to get a grouping of 8. The other pins are pretty much useless as PRU pins. Most of the pins on th eexapnsion header, as documented in the System Reference Manual, can be a GPIO for controlling anything such as an input or an output. GPIO pins do not connect to a PRU. 

Gerald

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

[Gregory Perry]

>From: Gerald Coley [ger...@beagleboard.org]
>Sent: Thursday, January 10, 2013 7:14 PM
>To: Gregory Perry
>Cc: beagl...@googlegroups.com
>Subject: Re: BeagleBone PRU Pins
>

>The PRU pins are mostly scattered and as such have no real value. The most that you can use that are >controlled in one group is 8. That was the reason I added two additional pins on top of other pins was to get >a grouping of 8. The other pins are pretty much useless as PRU pins. Most of the pins on th eexapnsion >header, as documented in the System Reference Manual, can be a GPIO for controlling anything such as an >input or an output. GPIO pins do not connect to a PRU. 

>

>

>

>Gerald

So that means 16 total pins that can be controlled concurrently via the two PRUs?  Or is it 8 total across both?

[Gerald Coley]

If you want to collect parallel data in contiguous order, you are limited to 8. If you have no issue collecting data in a non contiguous pattern and then regrouping it, then go for it. If you are only using one or two pins, then you should have many places to choose from.

That is what I meant by my statement.

Gerald

On Thu, Mar 7, 2013 at 4:51 PM, <brando...@gmail.com> wrote:

Chance that I stumbled onto this, but I made that list. I fixed some mistakes last week, so might want to look again.

I can't say I understand Gerald's response:

> The PRU pins are mostly scattered and as such have no real value.
> The most that you can use that are controlled in one group is 8.

There is physical grouping on the header, but there is no grouping in their signal control (except between PRUs). I don't see why physical separation means they have no real value...I'm using all of the PRU pins. :-\

All of the pins in that list can be muxed by the main processor, and then controlled or read by a PRU. So, 13 pins for PRU1, and 10 pins for PRU0 (but 2 as input only, 2 as output only). Pin states are set and read with 32-bit word writes, so all PRU pins for a given PRU can be toggled/read simultaneously.

Note that I said "muxed by the main processor". The pin mux settings require "privileged" access, so, if you want to switch a pin between input and output, you'll have to go through the kernel. This can be in the form of your own kernel driver, devmem2, or the sysfs gpio stuff.

If you're just trying to do output with the PRU, then you're limited to 21 pins for both PRUs, combined. Each PRU has independent control of its pins, so you would have to get tricky to set them simultaneously. If a 20ns or so delay was ok, you could just put the second pru in a tight loop where it read from a shared memory address right into r30 (the register that sets the pin states). Anything beyond that would require some scheme where the first pru would say to the second, "here are the pin states I want you to set. I know you'll take about n ticks to process this, so I'll wait until then to set mine, so we can set them together".

The only benefit of the PRU is that the timing is deterministic. Each instruction in your PRU program has a known time (unless it's system memory access) so you can know the exact timing of the waveform coming out of the pin. If that's not important, and around 3MHz is enough, then use mmap to /dev/mem to standard gpio.

-Brandon

[sri...@gmail.com]

If I am reading all the PRU pin documentation correctly, the only available PRU Output Pins on a BBB (without disabling the eMMC or HDMI) are the following:

PRU0:  P9_42, P9_27, P9_41, P9_25, P8_12, P8_11

PRU1:  P9_26
Correct?

Thanks

[maycon...@gmail.com]

You can read or write in any other pin with pru addressing this via memory position, is slower than direct access, but in most applications not matters, this method off access not interfere in speed off principal processor...

Maycon