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