PRU - Low Latency I/O

[Bill Gray]

Hello All!

I've recently begun digging into the PRU for a realtime project that I am working on.

I have found tons of helpful information out there, and I am now up and running with PRU programming!  Yay!

One of the great resources I've found was this video of Jason Kridner talking about BBB in general and PRU programming in general.  It really helped me to understand what is going on and where things are headed (like why omap_mux is gone among other things)

http://www.adafruit.com/blog/2014/07/01/real-time-programming-with-beaglebone-prus-by-jason-kridner-at-chicago-hackerspace-ps1-beagleboneblack-txinstruments-beagleboardorg/

Presentation slides at this link...
http://beagleboard.org/static/PumpingStationOne20140628_Real-timeProgrammingWithBeagleBonePRUs.pptx.pdf

In this video, and in the accompanying slides Jason mentions that there are some I/O pins that are specially configured to provide low latency I/O to the PRU.  Since I only need 12 pins for my project, I would like to use these pins exclusively.

I'm wondering if there is some special way that one needs to access them in order to get this low latency, or if they should be accessed through the same registers as "normal" gpio pins?  By the normal registers I mean...

GPIO_DATAIN
GPIO_DATAOUT
GPIO_CLEARDATAOUT
GPIO_SETDATAOUT

Thanks so much.

Bill

[Philip Polstra]

Just wanted to add my book http://store.elsevier.com/Hacking-and-Penetration-Testing-with-Low-Power-Devices/Philip-Polstra/isbn-9780128007518/ to the list from Jason's presentation (it came out after his presentation).  In addition to the hacking stuff, there are chapters on using XBee/ZigBee to remotely control the BBB, power requirements, and developing your own Linux distro.  Those developing real time and/or robotics projects on the BBB might find the information useful.

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

[Jason Kridner]

Phil's book is pretty awesome. I'm really enjoying it.

I tried to boil down a bit what I did in Chicago with the presentation at http://beagleboard.org/pru, but I still have a long way to go to make things easy. I did get a room full of fairly new people blinking LEDs with the PRUs though.

[TJF]

Hello Bill!

I'm dealing with PRU stuff since month, creating the libpruio library.

Am Freitag, 31. Oktober 2014 18:00:03 UTC+1 schrieb Bill Gray:

I'm wondering if there is some special way that one needs to access them in order to get this low latency, or if they should be accessed through the same registers as "normal" gpio pins?  By the normal registers I mean...

GPIO_DATAIN
GPIO_DATAOUT
GPIO_CLEARDATAOUT
GPIO_SETDATAOUT

For low latency GPIOs you need not access the GPIO subsystems over the OCP master port. Instead, write output to dedicated bits in register r30 and receive input in register r31 (after setting the pin mode accordingly). Find the related header pins by searching for pr1_pru0* and pr1_pru1*. Some of them are reserved for EMC2 and HDMI on the BBB. If your 12 pins are mixed (inputs and outputs), you should have a good chance to find free header pins for either of the PRUSS.

[Bill Gray]

Great!

Thanks for the info... and thanks for your great work on libpruio!

I'm not using HDMI, so I was planning to use the PRU pins on the P8 header that HDMI frees up.

Am I correct in assuming that the low latency pins are specific to one or the other PRU?  For example, should I assume that something like "pr1_pru1_pru_r31_6" is a low latency input that is exclusively available to PRU1?  Well, I suppose PRU0 might be able to read that pin as a regular old GPIO, but I'm after low latency here.

Thanks again for the info!!!

B

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lzJge-08T9s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Bill Gray
Velkess
415 407 7356

[TJF]

Am Sonntag, 2. November 2014 01:40:22 UTC+1 schrieb Bill Gray:

Am I correct in assuming that the low latency pins are specific to one or the other PRU?  For example, should I assume that something like "pr1_pru1_pru_r31_6" is a low latency input that is exclusively available to PRU1?  Well, I suppose PRU0 might be able to read that pin as a regular old GPIO, but I'm after low latency here.

Sounds good!

I suppose by 'regular old GPIO' you mean accessing registers in the GPIO subsystem through the OCP master port. Both PRUSS can control all header pins that way (2 - 3 cycles latency).

'pr1_pru1_pru_r31_6' is on header P9 at pin 39 (CPU connector T3, ball# 46). Depending on the pinmuxing (the mode in the Control Module pad register at offset 0x8B8) it either can get controled as bit 12 in subsystem GPIO-2 by both PRUSS (mode 7 = gpio2-12). Or for low latency it's exclusive for PRU-1 and can be an input (mode 6 = pr1_pru1_pru_r31_6) or an output (mode 5 = pr1_pru1_pru_r30_6).

[Bill Gray]

Great!

Thanks so much for the help.

Bill

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lzJge-08T9s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.