Here is some sample code to use the ECAP module as a timer:
#include <stdint.h>
#include <string.h>
#include <pru_cfg.h>
#include <pru_ecap.h>
#define PRU0_ARM_INTERRUPT 19 // Interrupt used to signal to host we have halted
volatile register uint32_t __R30; // Output pins
volatile register uint32_t __R31; // Input pins
/* Mapping Constant table register to variable */
volatile pruCfg CT_CFG __attribute__((cregister("CFG", near), peripheral)); // PRU configuration from constants table
volatile pruEcap ECAP __attribute__((cregister("ECAP", near), peripheral)); // ECAP module from constants table
#define ROUT __R30
#define RIN __R31
int main(void) {
// Enable OCP master ports - this enables pinmux pins to R30 & R31 & host ram access
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
// Enable ECAP port for simple PWM (We need a timer tick)
ECAP.ECCTL2 = 0x0200; // PWM mode,continuous mode
ECAP.CAP1 = 0x060000; // Period = 1/1000th second
ECAP.CAP2 = 0x000000; // Duty cycle
ECAP.TSCTR = 0; // Reset the counter (it may be past the period)
ECAP.CTRPHS = 0;
ECAP.ECEINT = 0x0040; // Counter reset interrupt enable
ECAP.ECCTL1 = 0x0000; // do not reset on capture
ECAP.ECCTL2 |= 0x10; // Start the timer
while (1) {
// Do work in the loop
while ((ECAP.ECFLG & 0x40) == 0); // Wait for timer to reset
ECAP.ECCLR = 0xff; // Clear the condition
}
}
I am learning the whole overlay thing so please bear with me. In order to enable the pru with your overlay, I assume you have to do
echo myoverlay > /sys/devices/bone_capemgr.9slots
is this correct? When I do it I get write error File exists. What should I be doing?
For this interface, when you "error file exists" run "dmesg | tail"
and it'll actually tell you something! 
Regards,
Thanks Robert,
I got:
[ 4117.989952] bone-capemgr bone_capemgr.9: slot #12: Requesting firmware ‘myoverlay-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 4117.990270] bone-capemgr bone_capemgr.9: slot #12: dtbo ‘myoverlay-00A0.dtbo’ loaded; converting to live tree
[ 4117.991239] bone-capemgr bone_capemgr.9: slot #12: myoverlay conflict P9.31 (#5:BB-BONELT-HDMI)
[ 4118.000630] bone-capemgr bone_capemgr.9: slot #12: Failed verification
so I guess I need to take out the HDMI or use different pins
Yeap.. Either disable hdmi or use a different pin..
Regards,
Once you get the overlay working, it will be automatically loaded each time you boot if you modify the /etc/capemgr file and add your overlay name.
#sudo nano /etc/default/capemgr
CAPE=myoverlay
I changed the output to P8_11. Now I just need to drive it in C. How do that?
Toggle bit 15 of R30
__R30 = __R30 ^ 0x8000; // toggle bit 15
__R30 = __R30 | 0x8000; // turn on bit 15
__R30 = __R30 & ~0x8000; // turn off bit 15
Peter, seems like you’ve picked up quite a bit in the last couple months . . . glad you’re sharing too as ive pretty much been watching your progress since you started posting on the groups. Thanks for sharing.
Oh, and in case its not clear, this is something I only know something about from watching you all talk about it, and I have a completely different feeling of the PRU as opposed to when I first starting toying with the BBB. Seemed quite like black magic back then, and now, well it just seems like any other embedded bit of hardware. Which is pretty much what it is
Thanks for the kind words, William.
I'm still a newbie when if comes to Linux and BBB.
I have lots of experience with embedded software on PIC systems, C and Assembly, C++, C#, Java.
The PRU is right up my alley as a microcontroller device.
I was happy as a clam to see two high speed controllers come with the am335x.
I had concerns about controlling stepper motors in real time using Linux.
Now, I can task a microcontroller to dedicate all its time to it.
I had concerns about controlling stepper motors in real time using Linux.
Now, I can task a microcontroller to dedicate all its time to it.
Yeah, it is pretty nice. Technically you could do the same with any ( capable )external MCU,. But there are several caveats of course. Communication speed, additional costs, etc.
Im kind of interested in the PRUs from a power electronics perspective. I am not an electronics engineer at all, but I do read up a good bit on switch mode power supplies / DC/DC conversion. And while something like the C2000 processors from TI might be better suited for the task, I can not help but wonder how close you could come to achieving the same with the PRUs. Linux would definitely be a hindrance performance wise, in this context ( any OS would ) but could potentially serve as an interface between the PRUs, and the “user”.
Anyway, mostly just a “dream” of mine, or rather more of a “dream project” to toy around with one day.
Good morning!
I’m sorry that I have to dig up this thread, but I have the same problem.
My bbb is running debian wheezy 7.5 with larm linux 3.8.13-bone49 as a kernel and I’m not able to install the am335x-pru package (E: Unable to locate package am335x-pru-package) with the sudo apt-get install command.
What should I do? D:
All done.
Thanks for the quick reply!
V.
Hi Robert,
I’m trying to follow your recipe but am getting the following error: (NOTE: I called the PRU code file template.c instead of source.c):
Any idea what I’m doing wrong? I’m on kernel 3.8.13 (Debian Wheezy). Fwiw, I do see the symbol __PRU_CREG_CFG defined in the template.map file, but not __PRU_CREG_PRU_CFG that it is complaining about.
Thanks for any guidance you can provide.
Dave
undefined first referenced
symbol in file
__PRU_CREG_PRU_CFG template.obj
error: unresolved symbols remain
error: errors encountered during linking; “template.out” not built
“apt-get am335x-pru-package” gives me “Unable to locate package” on Ubuntu 14.04. Has this package disappeared between 2014 and 2016 or do I need to do something else to get it?
Thanks,
Ken