Beaglebone Green and PRU "Programmable Real-Time Unit" Interface to ADC using RemoteProc and RPMsg

Here is a BeagleBone Green project I have been working on:

The primary documentation is in the doc folder and the file is PRUADC1.pdf.

This project does not do anything useful. It is a laboratory experiment to become more familiar with embedded Linux and C code for the PRUs.
I may try expanding the project to perform some sort of useful function.

There is a crude youtube video which describes the project:

I’m working on a much improved video which I will upload soon.


This is great!

Can I encourage you to upload info to and/or as is undergoing some infrastructure issues?

I’d also love to put something on or onto Drew’s blog. Thoughts?

Looks good !

You know I just realized something that no one is doing that might be helpful to others when first attempting a project using remoteproc. An explanation of what the various files are for. For example AM335x_PRU.cmd looks to be some sort of configuration file, perhaps for the PRU’s . . . but passed that, no idea.

Hi Jason, yes I will look into it. My next priority is creating a higher quality youtube video using open-source video capture tools.
I’m going to get that done this weekend, and I will also look into the websites you have suggested.


Hi William, yes those files are kind of mysterious. Some are related to the C compiler/linker, and the others are related to remoteproc. I used the examples from the PRU Support Package as a template. The Makefile (which is really simple) has to be aware of these files.

It was pretty much plug-and-chug, as I followed the example patterns and there were no issues. It would be good to understand them better, especially later if I start tweaking the kernel modules or creating new ones.

I’m probably need to ask the folks at TI for some comments on the functions of these files, and then write it up in an expanded Remoteproc chapter.



Well, my point was that it would be nice to have a list of required files for a PRU / remoteproc project. Something that describes the minimal required files, and what each file purpose is.

New youtube video for the project:


Very cool project! That’s awesome that you were able to use the rpmsg character device to get the audio data up to user space and play it using the ALSA framework.


There are 4 files needed in order to build a C project for the PRU using TI’s C compiler. Each of the examples and labs in the pru-software-support-package include these files:

  • yourProgramFile.c
  • this is your C program that you are writing for the PRU- AM335x_PRU.cmd
  • this is a command linker file. This is the way that we describe the physical memory map, the constant table entries, and the placement of our code and data sections (into the physical memory described at the top of the file) to the PRU linker. There are some neat things that can be done as far as placing code and data in exact memory locations using this file, but for the majority of projects, this file can remain unchanged.- resource_table_*.h
  • this file will create a header in the elf binary (generated .out file) that is needed by the RemoteProc Linux driver while loading the code into the PRUs. For the examples in the pru-software-support-package, there are two types of resources that the PRU can request using the resource_table_*.h file:
  • interrupts - letting RemoteProc configure the PRU INTC interrupts saves code space on the PRUs
  • vrings - requesting vrings in the resource_table file is necessary if rpmsg communication is desired (since the ARM/Linux needs to create the vrings in DDR and then notify the PRU where the vrings were placed)- even if no resources are needed, the RemoteProc Linux driver expects the header to exists. Because of this, many examples in the package contain an empty resource_table header file (resource_table_empty.h)- Makefile
  • Makefile to build your PRU C program either on the target, on your Linux machine, or even on a Windows machine. The comment at the top of the Makefile tries to explain the environment variable needed for a successful build and how to set it on each of the 3 supported build development environments.
    Check out the am335x examples in the pru-software-support-package. You can ignore (or even delete) any of the hidden files/folders in the examples as they are only used by CCS (.settings/, .ccsproject, .cproject, .project), which is not needed if you are using the Makefile to build. Once you ignore the hidden files/folders, you’ll see that the examples provided include the above referenced 4 files and can be built by setting the PRU_CGT environment variable and typing ‘make’.

In the last image that I put on my BBGW (from Robert’s site) the PRU C compiler and the pru-software-support-package were all included in the file system out of the box. So, all that is needed to build the examples on the target is to create a symbolic link to the cgt-pru/bin/ folder, export the PRU_CGT variable, and then navigate to the examples folder (somewhere in /usr/share/ I think) and type ‘make’. The symbolic link and exporting the PRU_CGT variable are described at the top of the provided Makefiles.

Let me know if any of that is unclear or confusing.

Jason Reeder

Hi Jason, I took your explanation of the Remoteproc and C compiler files and added them to the project documentation. This is located in the Chapter “Remoteproc and RPMsg Framework” in the file PRUADC1.pdf in the doc directory:

Next I want to make some sort of illustration of where the various files related to this project are located in the standard Debian distribution for Beaglebone. It’s confusing at first, but really it boils down to pushing a few files/directories into the right places and setting a couple of environment variables. After setting up that and with a hacked Makefile, the compilation process and Remoteproc loading of firmware to PRUs should run like clockwork.

Thank you,

It’s up on First project published, hope I got it done correctly.

I had to make sure all was good using the latest Debian image. Got some help in another PRU discussion, and I’m pretty confident there is enough info to reproduce the result in the documentation on Github.