I believe that once your PRU code is compiled and moved into the correct directory it is persistent there. Then, it is a matter of starting the PRU which I think can probably be done at boot from the ARM side of the BeagleBone. I don’t have a system available right now but I believe the directory /dev/remoteproc/pruss-core# where # is the number of the PRU you want to start or stop is where you enable or disable the PRU. Enabling runs the code you’ve already loaded.
I spent a lot of time learning, crashing, screaming and crying with the PRUs on the BeagleBone Black but at the end of the day, we were pleased with how well it ran our prototype system. Here are some notes I made at the time and may have already shared. But for convenience, here they are again. This information is for Linux Buster distribution with kernel 4.19.x. An oldie but a usually goodie.
I have recently starting using the PRUs with C and began to learn this from scratch. I want to thank everyone on this group who has helped me along the way.
For the next person coming along trying to learn this, I want to share some things that may be helpful. I was an old dog relearning tricks and learning new tricks when I started this journey. It was tough and frustrating at times so hopefully this might help someone learn faster.
1. Working with the PRUs is not easy. Although it isn't easy, once you get the hang of it you'll be impressed with the expanded functionality and flexibility of this system on a chip (SOC) that you gain.
2. If you are rusty on using 'C' or just sloppy with memory allocation, pointers and addresses, spend some time getting back up to speed on these concepts. This will save you hours in the long run.
3. If your mental conversion from decimal to hex to binary gets foggy sometimes, use Excel and create a simple tool to help you convert one to the other. It has built in DEC2HEX, HEX2BIN, BIN2HEX, etc. functions.
4. I did not use CCS or a debug probe. They probably make some things easier but I can't say.
5. Get used to not being able to output anything from the PRU code directly to a terminal unless you hook up a separate terminal or other output device. The PRUs don't really run an OS like Linux so they don't have stdout type functions to use.
6. Get the PRU software development package from TI and download it to your Beagle using git.
7. If you don't need them, disable audio and video support in /boot/uEnv.txt
8. Spend some time studying TI's Sitarra Technical Reference Manual (TRM) for the am335x series. I mean really study it. Get familiar with the architecture of the chip and all the on-chip peripherals. In the interest of time, deep dive only on the ones you'll be using.
9. Note that floating point operations are not supported in PRU hardware and are discouraged by TI. If you must use them, know that they will use a lot of code and cycles and you may not have enough space to load your program. So use them sparingly.
10. Get familiar with the utilities available with the TI Assembly Language tools. In particular, ofdpru will breakdown your object file and help you know how much memory you'll be using and where.
11. Spend time going through Mark Yoder's PRU Cookbook. Do the examples.
12. Spend time going through TI's Hands On Labs. Although currently they are aimed at running on a Linux-based development platform, it's not required. You can still learn from the hands on labs even if you are running a Windows machine as your platform. Also, although TI assumes you are using Code Compiler Studio (CCS), it is not required. I used a combination of the Cloud9 IDE that ships with the BB for development of my code for both the host and PRU side. It lets me run code on the host side in the IDE. I then use a PUTTY session to make and load my PRU code. I suppose I could use a terminal session in Cloud9 to do this but using the PuTTY session is a nice way to keep the two types of code differentiated in my mind.
13. Understand the toolchain you are using and what it is doing but you don't have to initially understand every intricacy of the Makefile.
14. Get really comfortable with the registers that you'll use. Be aware that sometimes TI splits the configuration value across a nibble. An example is the Touch Screen Controller's four bits to set the analog channel input for a step. It uses bits 19-22. 19 is the MSB of the fifth nibble. Bits 20,21 and 22 are in the next nibble. So to configure to use analog input 5, the hex value for those two nibbles must be 28.
15. Specifically, study pin muxing. It helps to understand why it is necessary.
16. Recognize just how small 8k of RAM is really. Each PRU has only 8k of RAM for the firmware you download and your data. This means you'll really need to pay attention to writing tight, efficient code. If you run out of memory to load your program, first eliminate all floating point operations that you can and then begin to refine your code.
17. Study remoteproc thoroughly and get to know how it works like the back of your hand. Basically, it is bi-directional i/o between the main processor running under Linux and the PRUs based on a concept of virtual i/o (aka virtio). Once this sunk in for me, it became easier to use.
18. Make sure when you compile the firmware that you're using the right make file. Out of the box, Cloud9 will try to use gcc to compile and it won't recognize some of the C extensions TI has built into the PRU's compiler. For this reason, I compile my PRU code from a terminal session with PUTTY. There's probably a way to write a make file so this would work in Cloud9 but I didn't take the time to figure this out (yet).
19. When you are compiling your firmware with the make file, make sure to use TARGET=yourfilename or else you'll get errors because the make file is looking for the target. If you don't you'll get errors around problems with header files, etc. that don't make sense and it could waste a lot of time. Believe me, it is easy to forget this sometimes.
20. When learning remoteproc and RPMSG, I recommend starting with a very simple "round trip" message. Send something like "Hi" to the PRU and have it send "Hi Back" and display it from the host program.
21. Whatever you have your PRU doing, when it is done, make sure to stop sending messages through RPMSG and stop all peripherals, otherwise you may just crash the whole SOC.
Firmware goes in /lib/firmware
Programs that compile new firmware must have access to copy the new file into this directory so if a Makefile is trying to update this, it must be run with privileges that allow writing to /lib/firmware
PRU0 sysfs files are in /sys/class/remoteproc/remoteproc0
PRU1 sysfs files are in /sys/class/remoteproc/remoteproc1
File firmware holds the name of the firmware file that will be loaded
It is loaded when the PRU is started. It has to be stopped then started again to load new firmware.
The registers _R30 and _R31 are used in a lot of the example code on-line and are confusing intially. Section 5.7.2 of the
PRU Optimizing C/C++ Compiler, v2.2, User’s Guide explains them.
My setup:
Windows 10 as my development station, using Chrome as my browser
Cloud9 as the IDE just as it ships with the Beaglebone Black
PUTTY as my terminal
Things to watch for when things aren’t going right.
Did you compile your PRU code with TARGET=yourfilename on the command line?
Have you used up all your memory?
Is the PRU starting when your firmware starts? Use dmesg -HW to watch what the Linux side is doing.
