A "blink" program in C
To motivate the discussion, I'll use a simple program that uses the PRU to flash an LED ten times. This example is based on PRU GPIO example but using C instead of assembly code.
The C code, below, flashes the LED ten times. The LED is controlled by setting or clearing a bit in register R30, which controls the GPIO pins. The code demonstrates two ways of performing delays. The first delay uses a for loop, leaving the LED on for 400 ms. The second delay uses the special compiler function __delay_cycles(), which delays for the specified number of cycles. Since the PRUs run at 200 MHz, each cycle is 5 nanoseconds, yielding an off time of 300 ms. At the end, the code sends an interrupt to the host code via register R31 to let it know the PRU has finished.[1]
How to compile C programs with Code Composer Studio
Although you can compile C programs directly on the BeagleBone,[2] it's more convenient to use an IDE. Texas Instruments provides Code Composer Studio (CCS), an integrated development environment on Windows and Linux that you can use to compile C programs for the PRU.[3] To install CCS, use the following steps:- Download CCS here. (You'll need to create a TI account and then fill out an export approval form before downloading, which seems so 1990s but isn't too difficult.)
- Follow the instructions here to make sure you have the necessary dependencies or CCS installation will mysteriously fail.
- In the installer, select Sitara 32-bit ARM Processors: GCC ARM Compiler and TI ARM Compiler.
- In the add-ons dialog, selects PRU Compiler.
- After installation, run CCS, select Help -> CCS App Center, and install the additional add-ons (i.e. the PRU compiler).
To create a C program in CCS, use the following steps. The image highlights the fields to update in the dialog.
- Start CCS.
- Click New Project.
- Change target to AM3358.
- Change tab to PRU.
- Enter a project name, e.g. "test".
- Open "Project templates and examples" and select "Basic PRU Project".
- Click Finish.
- Enter the code.
To set up the BeagleBone for the example:
- Download the device tree file: /lib/firmware/PRU-GPIO-EXAMPLE-00A0.dts.
- Compile and install the device tree file to enable the PRU:
# dtc -O dtb -I dts -o /lib/firmware/PRU-GPIO-EXAMPLE-00A0.dtbo -b 0 -@ PRU-GPIO-EXAMPLE-00A0.dts # echo PRU-GPIO-EXAMPLE > /sys/devices/bone_capemgr.?/slots # cat /sys/devices/bone_capemgr.?/slots
- Download the linker command file bin.cmd.
- Download the host file that loads and runs the PRU code (loader.c) and compile it:
# gcc -o loader loader.c -lprussdrv
- In CCS, select Project -> Build All (control-B) to compile the program.[4]
- Copy the binary (test/Debug/test.out) to BeagleBone (e.g. with scp)
- On the BeagleBone, link and run the program:[5]
# hexpru bin.cmd test.out # ./loader text.bin data.bin
If everything went correctly, the LED should flash. (See my previous article for debugging help.)
In this example, loader simply loads and runs the executable on the PRU.[6] In a more advanced application, it would communicate with the PRU. For example, it could get commands from a web page, send them to the PRU, get results, and display them on the web. The point is that you can use the Linux-side code to do complex network or computational tasks, in combination with the PRU doing low-level, real-time hardware operations. It's kind of like having an Arduino together with a "real computer", in a tiny package.
Documentation
The PRUs are very complex and don't have nice APIs, so you'll probably end up reading a lot of documentation to use them. The most important document that describes the Sitara chip is the 5041-page Technical Reference Manual (TRM for short). This article references the TRM where appropriate, if you want more information. Information on the PRU is inconveniently split between the TRM and the AM335x PRU-ICSS Reference Guide. For specifics on the AM3358 chip used in the BeagleBone, see the 253 page datasheet. Texas Instruments' has the PRU wiki with more information. More information on using CCS is here.If you're looking to use the BeagleBone and/or PRU I highly recommend the detailed and informative book Exploring BeagleBone. Helpful web pages on the PRU include BeagleBone Black PRU: Hello World, Working with the PRU and BeagleBone PRU GPIO example. Some PRU example code is in the TI PRU training course.
Using a timer and interrupts
For a more complex example, I'll show how to use the PRU with a timer and interrupts.[7] The basic idea is the timer will trigger an interrupt at a set frequency. The PRU code in this example will toggle the GPIO pin when an interrupt occurs, generating a sequence of 5 pulses.[8]It is important to understand that PRU interrupts are not "real" interrupts that interrupt execution, but are signaled through polling.[9] A PRU interrupt sets bit 30 or bit 31 in register R31.[10] The PRU code can busy-wait on this bit to determine if an interrupt has happened. This is fast and very low latency, compared to context-switching interrupt, but it puts more demands on the program structure.
The first step is to add the plumbing for the timer's interrupt, so the PRU will receive the interrupt. The PRUs can handle 64 different interrupt types from various subcomponents of the system. The timer interrupt is assigned system event number 15 and has the cryptic name pr1_ecap_intr_req. (See TRM table 4-22.) Interrupts are configured in the host side code (loader.c) using the PRUSSDRV library API call prussdrv_pruintc_init. To support the timer interrupt, The diagram below shows the complex PRU interrupt configuration on the BeagleBone (details). The new interrupt path, highlighted in red, connects the timer interrupt (15) to CHANNEL0 and in turn to register R31, the register for polling.
To add interrupt 15 to the configuration as shown above, the configuration struct in loader.c must be modified. The following structure is passed to prussdrv_pruintc_init to set up the interrupt handling. The changes are highlighted in red. Without this change, timer interrupts will be ignored and the example code will not work.
#define PRUSS_INTC_CUSTOM { \ { PRU0_PRU1_INTERRUPT, PRU1_PRU0_INTERRUPT, PRU0_ARM_INTERRUPT, PRU1_ARM_INTERRUPT, \ ARM_PRU0_INTERRUPT, ARM_PRU1_INTERRUPT, 15, (char)-1 }, \ { {PRU0_PRU1_INTERRUPT,CHANNEL1}, {PRU1_PRU0_INTERRUPT, CHANNEL0}, {PRU0_ARM_INTERRUPT,CHANNEL2}, {PRU1_ARM_INTERRUPT, CHANNEL3}, \ {ARM_PRU0_INTERRUPT, CHANNEL0}, {ARM_PRU1_INTERRUPT, CHANNEL1}, {15, CHANNEL0}, {-1,-1}}, \ { {CHANNEL0,PRU0}, {CHANNEL1, PRU1}, {CHANNEL2, PRU_EVTOUT0}, {CHANNEL3, PRU_EVTOUT1}, {-1,-1} }, \ (PRU0_HOSTEN_MASK | PRU1_HOSTEN_MASK | PRU_EVTOUT0_HOSTEN_MASK | PRU_EVTOUT1_HOSTEN_MASK) \ }
The second step to using the timer is to initialize the timer to create interrupts at the desired frequency, as shown in the following code. Using PRU features is fairly difficult since you are controlling them through low-level registers, not a convenient API, so you'll probably need to study TRM section 15.3 to fully understand this. The basic idea is the timer counts up by 1 every cycle (PWM mode is enabled in ECCTL2). When the counter reaches the value in the APRD (period) register, it resets and triggers a "compare equal" interrupt (as controlled by ECEINT). Thus, interrupts will be generated with the period specified by DELAY_NS.
inline void init_pwm() { *PRU_INTC_GER = 1; // Enable global interrupts *ECAP_APRD = DELAY_NS / 5 - 1; // Set the period in cycles of 5 ns *ECAP_ECCTL2 = (1<<9) /* APWM */ | (1<<4) /* counting */; *ECAP_TSCTR = 0; // Clear counter *ECAP_ECEINT = 0x80; // Enable compare equal interrupt *ECAP_ECCLR = 0xff; // Clear interrupt flags }
The final step is to wait for the interrupt to happen with a busy-wait. The while loop polls register R31 until the timer interrupt fires and sets bit 30. Then the interrupt is cleared in the PRU interrupt subsystem and in the timer subsystem.
inline void wait_for_pwm_timer() { while (!(__R31 & (1 << 30))) {} // Wait for timer compare interrupt *PRU_INTC_SICR = 15; // Clear interrupt *ECAP_ECCLR = 0xff; // Clear interrupt flags }
The oscilloscope trace below shows the result of the timer example program: five precision pulses with a width of 100 nanoseconds on and 100 nanoseconds off. The important advantage of using the PRU microcontroller rather than the regular ARM processor is the output is stable and free of jitter. You don't need to worry about nondeterminism such as context switches or cache misses. If your application won't be affected by milliseconds of random delay, the regular processor is much easier to program, but if you require precision timing, you should use the PRU.
The full source code for the timer example is here.[11] To run the timer example, you'll also need to use the updated loader.c that enables interrupt 15 (or else nothing will happen).
Conclusion
The PRU microcontrollers give the BeagleBone real-time, deterministic processing, but with a substantial learning curve. Programming the PRUs in C using the IDE is much easier than programming in assembler. (And you can embed assembler code in C if necessary.)Combining the BeagleBone's full Linux environment with the PRU microcontrollers yields a very powerful system since the microcontrollers provide low-level real-time control, while the main processor gives you network connectivity, web serving, and all the other power of a "real" computer. (My current project using the PRU is a 3 megabit/second Ethernet emulator/gateway to connect to a Xerox Alto.)
Notes and references
[1] Delivering the interrupt to the host code is more complex than you'd expect. I wrote a longer description here, explaining details such as how event 3 on the PRU turns into event 0 on the host.[2] To compile a C program on the BeagleBone, use the clpru command. See this article for details on clpru.
[3] Code Composer Studio isn't available for Mac, but CCS works well if you run Linux on your Mac using Parallels. I also tried running Linux in VirtualBox, but ran into too many problems.
[4] If you want to see the assembly code generated by the C compiler, use the following steps:
- Go to Project -> Properties
- Select the configuration you're building (Debug or Release)
- Check Advanced Options -> Assembler Options: Keep the generated assembly language file. This adds the --keep_asm flag to the compile.
The resulting assembly file will be in Debug/main.asm. Although the file is hundreds of lines long, the actual generated code is much shorter, starting a few dozen lines into the file. Comments indicate which source lines correspond to the assembly lines.
[5] The hexpru utility converts the ELF-format file generated by the compiler into a raw image file that can be loaded onto the PRU. The bin.cmd file holds the command-line options for hexpru. See the PRU Assembly Language Tools manual for details.
You can configure Code Composer Studio to run hexpru automatically as part of compilation, by doing a bit of configuration. Follow the steps at here to enable and configure PRU Hex Utility.
[6] The loader.c code uses the PRU Linux Application Loader API (PRUSSDRV) to interact with the PRU. I'm told that the cool new framework is remoteproc, but I'll stick with PRUSSDRV for now. (There seems to be a great deal of churn in the BeagleBone world, with huge API changes in every kernel.)
[7] For a timer, I'll use the PRU's ECAP module, which can be configured for PWM and then used as a 32-bit timer. (Yes, this is confusing; see TRM section 15.3 for details.)
[8] This code is intended to demonstrate the timer, not show the best way to generate pulses. If you just want to generate pulses, use the PWM or even a simple delay loop.
[9] You might wonder why you'd use the PRU polling interrupts rather than just polling a device register directly. The reason is you can test the R31 register in one cycle, but reading a device register takes about 3 or 4 cycles (read latency details).
[10] The library uses the convention that PRU0 polls on bit 30 and PRU1 polls on bit 31, but this is arbitrary. You could use both bits to signal one PRU, for instance.
[11] One complexity in the timer source code is the need to define all the register addresses. To figure out a register address, find the address of the register block in the PRU Local Data Memory Map (TRM 4.3.1.2). Then add the offset of the register (TRM 4.5). Note that you can also access these registers from the Linux host side, but the addresses are different. (The PRU is mapped into the host's address space starting at 0x4a300000, TRM table 2.4.)
23 comments:
Hello so I am using PRU's to write bytes of data to the PRU RAM and then access and read the bytes and toggle an LED based on the bits. I am trying to send 1 byte of data at a time to the PRU. I have come across an issue where after sending the first byte the rest of the bytes are missing the initial bit. I have confirmed and checked to see what is being written and stored in the RAM is in fact not missing any parts of the byte. So I do not know how the PRU is missing these bits. Do you think you have an idea as to why or how its doing this? Thanks
The bin.cmd link appears broken. Can you update the link?
Thanks! Great Post!
I've fixed the bin.cmd link. Try it now.
Thanks for the post!
In loader.c with the interrupts, can you explain the "tpruss_intc_initdata pruss_intc_initdata = PRUSS_INTC_CUSTOM;" line?
If one wanted to enable a different system event such as system event 49, would more be needed to be changed besides replacing the 15 instances with 49?
Thanks again.
The PRUSS_INTC_CUSTOM line defines the structure passed to prussdrv_pruintc_init to set up the PRU interrupt controller. Its format is a bit confusing; for an explanation of the fields, see this documentation. Replacing 15 with 49 in the example should work for enabling system event 49, but I haven't tried it.
Thanks Ken,
I'm having an issue getting interrupts on the ARM side (like ARM interrupt 41) trigger system events that the PRU can poll on. Do you know if there is a trick or setting to have an ARM interrupt generate a system event?
Hi Anonymous: I haven't tried interrupts that direction, so unfortunately I don't know what the trick is.
Hello, thanks for the comprehensive tutorial!
Do you know a way to make this compiler for the PRU (Sitara 32-bit ARM Processors: GCC ARM Compiler and TI ARM Compiler) work on the Cloud9 IDE? That would be much more convenient since Linux stuff and PRU stuff would be developed on the same platform. I've watched a presentation by a "Ron" (TI person I believe) at an ELC conference and he kind of mentioned it was possible but he also didn't know how. I couldn't find any post that came close to that (yours is the closest I guess so I wanted to give it a shot)
Hello.
Thank you for this development / guide!
My problem is, in the moment I hit Compile All, I get the error message:
fatal error #1965: cannot open source file "rsc_types.h"
Did I miss something?
Thank you!
Hi Ken,
Great post! I have tried following your steps but I keep getting an error when I type: # gcc -o loader loader.c -lpressdrv
/tmp/cchePzmh.o: In function `main':
loader.c:(.text+0x1ee): undefined reference to `prussdev_load_datafile'
collect2: ld returned1 exit status
I don't know why I keep getting this error.
Thank you.
PRU C code works well for me,
Thanks for the great post, Ken!
Thanks for a great post,
I've written a larger program in asm, using an older version of the TI assembler and lib.
I may try this approach now as I need to do a lot of complex things and assembly takes so longer to write.
Thank you very much for your post.
I am running into a problem though. The following line :
echo PRU-GPIO-EXAMPLE > /sys/devices/bone_capemgr.?/slots
...doesn't work. It hangs and I have to kill the terminal from which I control my board through ssh. Do you have any idea why this might me happening ?
Hello, with my brand new beaglebone I run into a similar Problem. The error message after "echo ...": -bash: /sys/devices/platform/bone_capemgr.?/slots: No such file or Directory.
What means in ".../bone_capemgr.?" the dot and the question mark? My Folder structure is
/sys/devices/platform/bone_capemgr/slots (where slots is a text file). I can't overwrite this text file.
Thanks a lot for the article. I ran into the same issue as Loïc. The steps I followed:
After this line:
# dtc -O dtb -I dts -o /lib/firmware/PRU-GPIO-EXAMPLE-00A0.dtbo -b 0 -@ PRU-GPIO-EXAMPLE-00A0.dts
- Do not do "echo PRU-GPIO-EXAMPLE > /sys/devices/bone_capemgr.?/slots" (the slots file no longer exists, neither in /sys/devices/platform/bone_capemgr/);
- Instead, append the following line to the /boot/uEnv.txt (at the end): uboot_overlay_addr1=/lib/firmware/PRU-GPIO-EXAMPLE-00A0.dtbo
- Reboot
- Follow the tutorial (Download the linker command file bin.cmd, etc.)
Hello Shirriff, Good Morning,
Just wish to know which version of CCS is stable one CCS 6 or 7 or 8. And which one of them is being used by your goodselves.
With regards
Hello Shirriff, Good Morning,
Just wish to know which CCS version you recommend CCS 6 or 7 or 8. And which one you are using.
Thank Q
Hi, very nice article,
I tried to follow your tips and I got stuck in here: ./loader text.bin data.bin, it appears an error message saying the prudrv failed to open. Can you explain me how that code do exactly?
I thought that in order to run a firmware into the pru I should do something like this:
cp mycode.out /lib/firmware/am335x-pru0-fw
echo 'start' > /sys/class/remoteproc/remoteproc1/state
but I already tried both options and none of them seem to work.
Hope you can help me,
Fred Gomes
I tried to follow your tips and I got stuck in here: ./loader text.bin data.bin, it appears an error message saying the prudrv failed to open. Can you explain me how that code do exactly?
I thought that in order to run a firmware into the pru I should do something like this:
cp mycode.out /lib/firmware/am335x-pru0-fw
echo 'start' > /sys/class/remoteproc/remoteproc1/state
but I already tried both options and none of them seem to work.
Hope you can help me,
Fred Gomes
Hi, nice article
I tried to follow your tips and I got stuck in here: ./loader text.bin data.bin, it appears an error message saying the prudrv failed to open. Can you explain me how that code do exactly?
I thought that in order to run a firmware into the pru I should do something like this:
cp mycode.out /lib/firmware/am335x-pru0-fw
echo 'start' > /sys/class/remoteproc/remoteproc1/state
but I already tried both options and none of them seem to work.
Hope you can help me,
Fred Gomes
Hi, nice article
I tried to follow your tips and I got stuck in here: ./loader text.bin data.bin, it appears an error message saying the prudrv failed to open. Can you explain me how that code do exactly?
I thought that in order to run a firmware into the pru I should do something like this:
cp mycode.out /lib/firmware/am335x-pru0-fw
echo 'start' > /sys/class/remoteproc/remoteproc1/state
but I already tried both options and none of them seem to work.
Hope you can help me,
Fred Gomes
debian@beaglebone:~$ sudo echo PRU-GPIO-EXAMPLE > /sys/devices/bone_capemgr.?/slots
-bash: /sys/devices/bone_capemgr.?/slots: No such file or directory
debian@beaglebone:~$
debian@beaglebone:~$
debian@beaglebone:~$ ls -al /sys/devices/
total 0
drwxr-xr-x 10 root root 0 Dec 4 18:04 .
dr-xr-xr-x 12 root root 0 Dec 4 18:03 ..
drwxr-xr-x 5 root root 0 Dec 4 18:03 armv7_cortex_a8
drwxr-xr-x 3 root root 0 Dec 4 18:03 breakpoint
drwxr-xr-x 21 root root 0 Dec 4 18:03 platform
drwxr-xr-x 3 root root 0 Dec 4 18:03 soc0
drwxr-xr-x 3 root root 0 Dec 4 18:03 software
drwxr-xr-x 6 root root 0 Dec 4 18:03 system
drwxr-xr-x 3 root root 0 Dec 4 18:03 tracepoint
drwxr-xr-x 14 root root 0 Dec 4 18:03 virtual
Hello,
I'm trying to follow the tutorial but I am unable to locate the Basic PRU Example in CCS. I have been unsuccessfully trying to import it, but I can't find it anywhere. Is there a way to import it? Otherwise, is there a possible workaround to using that example template?
Thank you.
Post a Comment