|BeagleBone PRU Pins||Molly McLain||1/10/13 3:57 PM|
I happened across this handy spreadsheet today, which maps out the BeagleBone's Expansion Header PRU GPIO:
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?
|Re: BeagleBone PRU Pins||Gerald||1/10/13 4:14 PM|
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.
|RE: BeagleBone PRU Pins||Molly McLain||1/10/13 4:33 PM|
>From: Gerald Coley [ger...@beagleboard.org]
>Sent: Thursday, January 10, 2013 7:14 PM
>To: Gregory Perry
>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.
So that means 16 total pins that can be controlled concurrently via the two PRUs? Or is it 8 total across both?
|Re: BeagleBone PRU Pins||Brandon I||3/7/13 2:51 PM|
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:
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.
|Re: BeagleBone PRU Pins||Gerald||3/7/13 3:25 PM|
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.
|Re: BeagleBone PRU Pins||Chris Micali||3/16/13 5:09 PM|
Also using TI's pinmux util has helped me a lot figuring out which PRU pins I can get out and where they are. http://www.ti.com/tool/pinmuxtool
With it and the beaglebone header diagrams in the bone SRM I was able to get what I needed.
|Re: BeagleBone PRU Pins||sri...@gmail.com||11/12/13 8:23 PM|
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
|Re: BeagleBone PRU Pins||maycon...@gmail.com||11/13/13 9:11 AM|
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...
Em quinta-feira, 10 de janeiro de 2013 21h57min32s UTC-2, Gregory Perry escreveu: