Best way to build a large array for access by PRU0 ?


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.

Please get back to me soon! Thank you for reading

Evan Carter

On Thu, 1 Mar 2018 10:15:24 -0800 (PST), declaimed the


  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.

Hi Evan, I’m still with you!

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:

  1. compile your PRU code by pasm assembler
  2. load the uio_pruss driver with suiting parameter `extram_pool_sz=```
  3. 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.

Hello? Is anyone seeing my replies to these suggestions? I’m not seeing my own replies :frowning:



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 :slight_smile:

Thank you!

The main reasons for a failing prussdrv_open() are

  1. the driver uio_pruss didn’t load
  2. check lsmod if uio_pruss is listed
  3. check dmesg for errors1. the user has no write access to the interupts /dev/uio[0-7]
  4. check your write access by ls -l /dev/uio*
  5. Use ether sudo for your operation or adapt the uio* devices by chmod (ie. in a boot script)


Okay awesome, thank you!

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?

Thank you!

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.