I’ve been working with PRU0 on the Beaglebone Black (wireless) for a couple weeks now (only a beginner) and have made some hopeful progress towards developing a real time system that will change gpio logic states based on given location data from a pupil-tracking system.
So far I’ve been using the examples given in the BeagleScope project (found here) to program the PRU using pru_rpmsg, and I’m currently using: Linux beaglebone 4.4.113-ti-r147 #1 SMP Tue Feb 20 20:58:22 UTC 2018 armv7l GNU/Linux
Things are going well!
But I wanted to ask technical support about the simplest way to build a large 1-D array (look up table of ~310,000 indexes of just integers) that can be accessed by PRU0 on the fly to know how to set the gpios when it receives a new set of pupil-location values. Previously I’ve built this array in userspace from an existing .txt file that is read byte by byte from a C script that builds the array in userspace, but I need that array to be accessible from PRU0. What is the simplest way to do this?
I’ve looked into trying to build the array in DDR memory (which could in theory be accessed by the PRU using address pointers), but allocating that kind of space to be available to a user space program looks pretty complicated (especially to ME who has never done any kernel space programming). I’m hoping that someone can give me inspiration for a simpler way to get this array to PRU0.
On Thu, 1 Mar 2018 10:15:24 -0800 (PST), evangrcarter@gmail.com declaimed the
following:
Hello,
It appears your client is glitching -- as the contents of this message
were originally posted two days ago; and has received three follow-ups of
one form or another.
The solution is drop rproc and use libprussdrv instead. You’ll find everything you need, just use it out-of-the-shelf. Everything is explained in the docs. The steps are:
compile your PRU code by pasm assembler
load the uio_pruss driver with suiting parameter `extram_pool_sz=```
adapt your C code
make a code frame to load the pasm binary to PRU (copy/paste from one of the examples)
get ERam pointer by function prussdrv_map_extmem()
write your integer data to that pointer from ARM side
use function prussdrv_get_phys_addr() to get the physical address
pass the physical address to PRU (ie via DRam)
read the integers from there from PRU side
Everything gets easy when you use the matching tools.
Thank you for such a direct and concise solution! As I mentioned in one my earlier replies today, I had some trouble getting libprussdrv to work on 4.9 because prussdrv_open() failed everytime I tried to use it. But It’s been a while and I’m game to try it again with a fresh image and everything, so I’ll try all this tonight and hopefully I get somewhere
This weekend I will get a chance to dig into this more. So a lot of the examples I’ve seen using uio_pruss involve a device tree overlay for gpio pin muxing, I’m comfortable doing that, but I’ve noticed lately that slots isn’t around anymore because I guess a lot of people were messing things up by echoing into it. Should I still be using an overlay to do my pins? Or would something like config-pin work just fine?
For development phase, flexibility is important (after boot pinmuxing). Once your design is finished, a matching overlay is advantageous (pinmuxing at boot time, faster, less memory).
Use either config-pin or libpruio-00A0.dtbo for punmuxing (the later is more save).
The slots file was removed since any 4.x kernel (>4.4 AFAIR). Never kernels are not good documented, and you’ll find different examples. It’s hard to keep track. From my point of view, they’re still experimental.
If you want fast and successful development, I recommend falling back to a 3.8 kernel. You’ll find good documented examples, and you’ll get to a steep learning curve. You can switch to a never kernel later, when you know what you need.
