PRU C Project - from device tree to program execution

[Peter Gregory]

I finally got my Beaglebone Black PRU C code project up and going.
It took a lot of googling and posting, but I thought it would be nice to post a condensed version of the notes needed to get C code running on the BBB PRU.
This is targeting Debian 3.8 kernel versions.

------------------------------------------------------------------------------
Possible PRU pin mappings + values for device tree building + BBB conflict pins
------------------------------------------------------------------------------
Bit pr1_pru0_pru_r30_? (out)
0 P9_31, gpio3[14], 0x190 , Mode 6
1 P9-29, gpio3[15], 0x194, Mode 6
2 P9-30, gpio3[16], 0x198, Mode 6 (HDMI, LCD)
3 P9-28, gpio3[17], 0x19c, Mode 6
4 P9-42, gpio3[14], 0x1a0, Mode 6
5 P9-27, gpio3[19], 0x1a4, Mode 6 (HDMI, LCD)
6 P9-41, gpio3[20], 0x1a8, Mode 6
7 P9-25, gpio3[21], 0x1ac, Mode 6
8
9
10
11
12
13
14 P8-12, gpio1[12], 0x030, Mode 6
15 P8-11, gpio1[13], 0x034, Mode 6


Bit pr1_pru0_pru_r31_? (in)
0 P9-31, gpio3[14], 0x190, Mode 5
1 P9-29, gpio3[15], 0x194, Mode 5
2 P9-30, gpio3[16], 0x198, Mode 5 (HDMI, LCD)
3 P9-28, gpio3[17], 0x19c, Mode 5
4 P9-42, gpio3[14], 0x1a0, Mode 5
5 P9-27, gpio3[19], 0x1a4, Mode 5
6 P9-41, gpio3[20], 0x1a8, Mode 5
7 P9-25, gpio3[21], 0x1ac, Mode 5
8
9
10
11
12
13
14 P8-16, gpio1[14], 0x038, Mode 6
15 P8-15, gpio1[15], 0x03c, Mode 6
16 P9-24, gpio0[15], 0x0184, Mode 6 (HDMI, LCD)
16 P9-41, gpio3[20], 0x164, Mode 5

Bit pr1_pru1_pru_r30_? (out)
0 P8-45, gpio2[6], 0x0a0, Mode 5 (HDMI, LCD)
1 P8-46, gpio2[7], 0x0a0, Mode 5 (HDMI, LCD)
2 P8-43, gpio2[8], 0x0a8, Mode 5 (HDMI, LCD)
3 P8-44, gpio2[9], 0x0ac, Mode 5 (HDMI, LCD)
4 P8-41, gpio2[10], 0x0b0, Mode 5 (HDMI, LCD)
5 P8-42, gpio2[11], 0x0b4, Mode 5 (HDMI, LCD)
6 P8-39, gpio2[12], 0x0b8, Mode 5 (HDMI, LCD)
7 P8-40, gpio2[13], 0x0bc, Mode 5 (HDMI, LCD)
8 P8-27, gpio2[22], 0x0e0, Mode 5 (HDMI, LCD)
9 P8-29, gpio2[23], 0x0e4, Mode 5 (HDMI, LCD)
10 P8-28, gpio2[24], 0x0e8, Mode 5 (HDMI, LCD)
11
12 P8-21, gpio1[30], 0x080, Mode 5 (HDMI, LCD)
13 P8-20, gpio1[31], 0x084, Mode 5 (HDMI, LCD)
14
15
16

Bit pr1_pru1_pru_r31_? (in)
0 P8-45, gpio2[6], 0x0a0, Mode 6 (HDMI, LCD)
1 P8-46, gpio2[7], 0x0a0, Mode 6 (HDMI, LCD)
2 P8-43, gpio2[8], 0x0a8, Mode 6 (HDMI, LCD)
3 P8-44, gpio2[9], 0x0ac, Mode 6 (HDMI, LCD)
4 P8-41, gpio2[10], 0x0b0, Mode 6 (HDMI, LCD)
5 P8-42, gpio2[11], 0x0b4, Mode 6 (HDMI, LCD)
6 P8-39, gpio2[12], 0x0b8, Mode 6 (HDMI, LCD)
7 P8-40, gpio2[13], 0x0bc, Mode 6 (HDMI, LCD)
8 P8-27, gpio2[22], 0x0e0, Mode 6 (HDMI, LCD)
9 P8-29, gpio2[23], 0x0e4, Mode 6 (HDMI, LCD)
10 P8-28, gpio2[24], 0x0e8, Mode 6 (HDMI, LCD)
11
12 P8-21, gpio1[30], 0x080, Mode 6 (HDMI, LCD)
13 P8-20, gpio1[31], 0x084, Mode 6 (HDMI, LCD)
14
15
16 P9-26, gpio1[29], 0x180, Mode 6
------------------------------------------------------------------------------
Beaglebone Black Kernel 3.8 Device Tree Overlay - map GPIO pins directly to PRU R30 or R31
Create overlay file /lib/kernel/myoverlay-00A0.dts using contents below.
Compile using device tree compiler (dtc):
#sudo apt-get install device-tree-compiler
#sudo dtc -O dtb -o /lib/firmware/myoverlay-00A0.dtbo -b 0 -@ /lib/firmware/myoverlay-00A0.dts
Modify cape manager file in /etc/default/capemgr to load overlay during boot:
#sudo nano /etc/default/capemgr
CAPE=myoverlay
Edit /etc/modules and append text
#sudo nano /etc/modules
uio_pruss
------------------------------------------------------------------------------
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "MYOVERLAY";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
// PRU resources used
"pruss",
"pru0",
// PRU Input pins
"P8.16","pr1_pru0_pru_r31_14", // PIN Name and the PRU port it maps to (see table above)
// PRU Output pins
"P9.31","pr1_pru0_pru_r30_0";

// MUX Bit Maps:
// 0x40 = slow slew (0 = fast slew)
// 0x20 = input (0 = output)
// 0x10 = pullup, 0x08 = disabled (0 = pulldown)
// 0x01 to 0x07 = mode 1 to 7
fragment@8 {
target = <&am33xx_pinmux>;
__overlay__ {

pruss_pins: pruss_pins {
pinctrl-single,pins = <
0x038 0x36 // P8_16, gpio3[14] mode 6, input pull-up
0x190 0x15 // P9_31 gpio1[19] mode 5, output, pull-down
>;
};
};
};

fragment@10 {
target = <&pruss>;
__overlay__ {
status = "okay"; // This enables the PRU
pinctrl-names = "default";
pinctrl-0 = <&pruss_pins>; // This uses our custom mapping (see above definition)

// This is for documentation only. You can see the pin mappings by:
// sudo cat /sys/kernel/debug/gpio
any_name1 { // Grouping of pins under this name
pin-names = "Input pin description"; // one name per pin defined in gpios. Multiple entries are comma seperated;
gpios = <&gpio4 14 1>; // &gpio? (One based: 1-4 instead of 0-3) bit(0-31) input(1)/output(0). Multiple entries seperated by a space
};
any_name2 {
pin-names = "Output pin description";
gpios = <&gpio2 19 0>;
};
};
};
};
------------------------------------------------------------------------------
PRU C Code – compile using clpru & hexpru
------------------------------------------------------------------------------
// C library Installed by: apt-get install am335x-pru-package ti-pru-cgt-installer
#include <stdint.h>
// PRU support libraries Installed from home directory with: git clone git://git.ti.com/pru-software-support-package/pru-software-support-package.git pru_support
#include <pru_cfg.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 CFG register pointer loaded from constants table (see lnk.cmd)

int main(void) {
// Enable OCP master ports - this enables pinmux pins to R30 & R31 & host ram access (all the BBB GPIO ports & such)
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

// Do work - write your code here

// Signal the process has completed (this will wake up the loader to tell it work is done)
__R31 = (__R31 & ~0xff) | (PRU0_ARM_INTERRUPT+16);
return 0;
}
------------------------------------------------------------------------------
lnk.cmd – linker command file defines physical address mappings
------------------------------------------------------------------------------
-cr
-stack 0x100
-heap 0x100

MEMORY
{
PAGE 0:
PRUIMEM : org = 0x00000000 len = 0x00002000 /* 8kB PRU0 Instruction RAM */

PAGE 1:
PRUDMEM : org = 0x00000000 len = 0x00002000 /* 8kB PRU Data RAM 0 */
SHAREDMEM : org = 0x00010000 len = 0x00003000 /* 12kB Shared RAM */
PRU0_CTRL : org = 0x00022000 len = 0x00000030
PRU1_CTRL : org = 0x00024000 len = 0x00000030

/* Constant Table Memory directives. */

INTC : org = 0x00020000 len = 0x00001504 CREGISTER=0
DMTIMER2 : org = 0x48040000 len = 0x00000100 CREGISTER=1
I2C1 : org = 0x4802A000 len = 0x00000100 CREGISTER=2
ECAP : org = 0x00030000 len = 0x00000100 CREGISTER=3
CFG : org = 0x00026000 len = 0x00000100 CREGISTER=4
MMCHS0 : org = 0x48060000 len = 0x00000100 CREGISTER=5
MCSPI0 : org = 0x48030000 len = 0x00000100 CREGISTER=6
UART0 : org = 0x00028000 len = 0x00000100 CREGISTER=7
MCASP0_DMA : org = 0x46000000 len = 0x00000100 CREGISTER=8
GEMAC : org = 0x4A100000 len = 0x00000100 CREGISTER=9
RSVD10 : org = 0x48318000 len = 0x00000100 CREGISTER=10
UART1 : org = 0x48022000 len = 0x00000100 CREGISTER=11
UART2 : org = 0x48024000 len = 0x00000100 CREGISTER=12
RSVD13 : org = 0x48310000 len = 0x00000100 CREGISTER=13
DCAN0 : org = 0x481CC000 len = 0x00000100 CREGISTER=14
DCAN1 : org = 0x481D0000 len = 0x00000100 CREGISTER=15
MCSPI1 : org = 0x481A0000 len = 0x00000100 CREGISTER=16
I2C2 : org = 0x4819C000 len = 0x00000100 CREGISTER=17
EHRPWM1 : org = 0x48300000 len = 0x00000100 CREGISTER=18
EHRPWM2 : org = 0x48302000 len = 0x00000100 CREGISTER=19
EHRPWM3 : org = 0x48304000 len = 0x00000100 CREGISTER=20
MDIO : org = 0x00032400 len = 0x00000100 CREGISTER=21
MBX0 : org = 0x480C8000 len = 0x00000100 CREGISTER=22
SPINLOCK : org = 0x480CA000 len = 0x00000100 CREGISTER=23
/* PRU0_1 : org = 0x00000000 len = 0x00000100 CREGISTER=24
PRU1_0 : org = 0x00000000 len = 0x00000100 CREGISTER=25 */
IEP : org = 0x0002E000 len = 0x0000031C CREGISTER=26
/* MII_RT : org = 0x00032000 len = 0x00000100 CREGISTER=27
SHARED_RAM : org = 0x00000000 len = 0x00000100 CREGISTER=28 */
TPCC : org = 0x49000000 len = 0x000010A0 CREGISTER=29
L3OCMC : org = 0x40000000 len = 0x00010000 CREGISTER=30
DDR : org = 0x80000000 len = 0x00000100 CREGISTER=31
}

SECTIONS {
/* Forces _c_int00 to the start of PRU IRAM. Not necessary when loading
an ELF file, but useful when loading a binary */
.text:_c_int00* > 0x0, PAGE 0

.text > PRUIMEM, PAGE 0
.stack > PRUDMEM, PAGE 1
.bss > PRUDMEM, PAGE 1
.cio > PRUDMEM, PAGE 1
.data > PRUDMEM, PAGE 1
.switch > PRUDMEM, PAGE 1
.sysmem > PRUDMEM, PAGE 1
.cinit > PRUDMEM, PAGE 1
.rodata > PRUDMEM, PAGE 1
.rofardata > PRUDMEM, PAGE 1
.farbss > PRUDMEM, PAGE 1
.fardata > PRUDMEM, PAGE 1
.PRU0_CTRL > PRU0_CTRL, PAGE 1
.resource_table > PRUDMEM, PAGE 1
}
------------------------------------------------------------------------------
bin.cmd – used by hexpru to generate text.bin and data.bin
------------------------------------------------------------------------------
-b
-image
ROMS {
PAGE 0:
text: o = 0x0, l = 0x1000, files={text.bin}
PAGE 1:
data: o = 0x0, l = 0x1000, files={data.bin}
}
------------------------------------------------------------------------------
Compile command:
------------------------------------------------------------------------------
clpru -i /usr/share/ti/cgt-pru/lib -i ~/pru_support/include -i . --endian=little --define am3359 --define pru0 --silicon_version=3 -o1 source.c -z lnk.cmd -o source.out -m source.map
hexpru bin.cmd pru_cblink.out
------------------------------------------------------------------------------
pru_loader.c – host side code to load the text.bin image to pru 0. Compile with: gcc -o pru_loader pru_loader.c -lprussdrv
Run from linux command prompt to deploy text.bin to PRU 0 and run it (text.bin must be in the current directory)
------------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

#include <prussdrv.h>
#include <pruss_intc_mapping.h>

#define PRU_NUM 0
#define AM33XX

int main (int argc, char **argv)
{
unsigned int ret;
tpruss_intc_initdata pruss_intc_initdata = PRUSS_INTC_INITDATA;

/* Initialize the PRU */
prussdrv_init ();

/* Open PRU Interrupt */
ret = prussdrv_open(PRU_EVTOUT_0);
if (ret) {
printf("prussdrv_open open failed\n");
return (ret);
}

/* Get the interrupt initialized */
prussdrv_pruintc_init(&pruss_intc_initdata);

/* Execute example on PRU */
prussdrv_exec_program (PRU_NUM, "./text.bin");

/* Wait until PRU0 has finished execution */
prussdrv_pru_wait_event (PRU_EVTOUT_0);
prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);

/* Disable PRU and close memory mapping*/
prussdrv_pru_disable (PRU_NUM);
prussdrv_exit ();

return(0);
}

[Karteek YV]

I couldn't install am335x-pru-package and ti-pru-cgt-installer from terminal, it gave the following errors when I tried,
root@arm:/home/ubuntu# apt-get install am335x-pru-package ti-pru-cgt-installer
Reading package lists... Done
Building dependency tree      
Reading state information... Done
E: Unable to locate package am335x-pru-package
E: Unable to locate package ti-pru-cgt-installer

I am using ubuntu 14.04 on BBB with following kernel
Linux arm 3.8.13-bone64 #1 SMP Fri Aug 22 00:19:37 UTC 2014 armv7l armv7l armv7l GNU/Linux

I have installed am335x-pru-package manually with following steps

cd pru_sw/app_loader/interface/
gcc -I. -Wall -I../include   -c -fPIC -O3 -mtune=cortex-a8 -march=armv7-a -shared -o prussdrv.o prussdrv.c
gcc -shared -o libprussdrv.so prussdrv.o

Copy the driver and headers to system folders

sudo cp libprussdrv.so /usr/lib/
sudo cp ../include/*.h /usr/include/

Now build the assember

cd ../../utils/pasm_source
./linuxbuild

Copy the assembler to system

sudo cp ../pasm /usr/bin/

Installed ti-cgt-pru-installer with following steps

root@arm:/home/ubuntu# wget --no-check-certificate http://software-dl.ti.com/codegen/esd/cgt_public_sw/PRU/2.1.0/ti_cgt_pru_2.1.0_armlinuxa8hf_busybox_installer.sh

root@arm:/home/ubuntu# chmod 766 ti_cgt_pru_2.1.0_armlinuxa8hf_busybox_installer.sh

root@arm:/home/ubuntu# ./ti_cgt_pru_2.1.0_armlinuxa8hf_busybox_installer.sh

[Robert Nelson]

On Mon, Dec 1, 2014 at 8:53 AM, Karteek YV <venka...@gmail.com> wrote:
> I couldn't install am335x-pru-package and ti-pru-cgt-installer from
> terminal, it gave the following errors when I tried,
> root@arm:/home/ubuntu# apt-get install am335x-pru-package
> ti-pru-cgt-installer
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package am335x-pru-package
> E: Unable to locate package ti-pru-cgt-installer

Sorry, i haven't yet started pushing these to ubuntu. The ppa on
repos.rcn-ee.net is now live for ubuntu (trusty/14.04) so you'll start
seeing these packages showing up.. (for ubuntu, i'm not planning on
doing non-lts's)

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Karteek YV]

Sorry, I didn't get your point, are the packages available for ubuntu 14.04? The version on my bbb is ubuntu trusty 14.04, I guess it is lts version. Still I get the same error 'Unable to locate package' for both the packages am335x-pru-package and ti-pru-cgt-installer.

[Robert Nelson]

On Mon, Dec 1, 2014 at 10:42 AM, Karteek YV <venka...@gmail.com> wrote:
> Sorry, I didn't get your point, are the packages available for ubuntu 14.04?
> The version on my bbb is ubuntu trusty 14.04, I guess it is lts version.
> Still I get the same error 'Unable to locate package' for both the packages
> am335x-pru-package and ti-pru-cgt-installer.

Well:

sudo apt-get update ; sudo apt-get install am335x-pru-package

Should work right "now", give me another 10minutes for the other package..

[Robert Nelson]

and:

sudo apt-get update ; sudo apt-get install ti-pru-cgt-installer

should work now too..

[Karteek YV]

yeah, its working now :)

[Phil W.]

Hey Peter,

thank you for your guide.

Im a bit stuk with my own projekt. I wrote and succesfully debugged some code for reading from an ADC with CCS and a JTAG probe. I also checked the shared ram mecanism for the host/PRU communication by manipulating it via Memory Browser. It works well from the PRU side. I also wired some LED' s for debugging for when I'm trying out with the Linux (Ubuntu).
So as I can see i have done all the steps you mentioned below. But when I load the PRU-Programm with "prussdrv_exec_program (PRU_NUM, "./text.bin"); " nothing is happening with the PRU. First line in the the program should switch the Debug LED's from previus state.
The right pinmuxxing can be seen when applying the devicetree overlay - one LED lights up as experienced with CCS and JTAG manipulating the control module.

So I wonder wy my PRU doesnt seem to run the program. Do you know any way to look inside the PRU from linux?

with kind regards
Philipp

[Phil W.]

Um, and what about the data.bin file?
I see you only use the text.bin file.

[Peter Gregory]

I don't know of a way to debug the PRU.
I'd start with a very simple C program.
You can start with setting the interrupt telling the loader the program is halting.
Next, enable the OCP, then go into a tight loop toggling a pin.

// Enable OCP master ports - this enables pinmux pins to R30 & R31 & host ram access (all the BBB GPIO ports & such)
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

That should let you know the PRU is loaded and running and it is able to access pins.

[Peter Gregory]

If all your variables are in the .bss segment (uninitialized variables) then you only need to load the text.bin file.

[Phil W.]

Okay, now i followed your Instructions with a clean new flashed Ubuntu 14.04 kernel 3.8.13 - aaand it works. :)
I also can toggle some LED' s.

But I stumbelt over some difrences toward your guide with Debian regarding the device tree stuff.

Create overlay file /lib/kernel/myoverlay-00A0.dts using contents below.

No /lib/kernel here, but cp the .dtbo to /lib/firmware did the job.

#sudo nano /etc/default/capemgr
CAPE=myoverlay
Edit /etc/modules and append text
#sudo nano /etc/modules
uio_pruss

Has no effekt in my setup and seems not te be needet.
I had to

echo myoverlay > SLOTS=/sys/devices/bone_capemgr.*/slots

to get the PRU drv and the Pinmux working. But first there is to kill the HDMI cape by adding "optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" on

sudo nano /boot/uEnv.txt

Any idear where this diffrence comes from? Is the capemanagement that diffrent from Debian? I thought they were close relatives?!

In this context is also to mention that it seems important to use kernel 3.8 and not 3.14. With the newest Ubuntu immage I missed "/sys/devices/bone_capemgr.*/"

I will use this as a starting point and port my "problem" program step by step. I will soon maybe find out what my mistake was.

As a contribution for your work and for the help of others I atached my source from the LED Example.

with kind regards
Philipp

[Charles Steinkuehler]

On 12/6/2014 8:50 PM, Peter Gregory wrote:
> I don't know of a way to debug the PRU.

There hardware support for debugging the CPU in the AM335x, and a few
programs that have support for debugging. Nothing as fancy as gdb, but
it can be helpful. I mostly use the pru_debug setup from Machinekit,
which basically allows viewing register contents while single-stepping
and pausing (but no breakpoints).

The programs I know about are listed here:

http://blog.machinekit.io/2013/06/beagle-bone-pru-links.html

...the list is a bit dated, if anyone knows of other tools (or a better
list), let me know.

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

Okay, now i followed your Instructions with a clean new flashed Ubuntu 14.04 kernel 3.8.13 - aaand it works. :)
I also can toggle some LED' s.

Well, if you were using a 3.14.x kernel, that would explain it. There is no capemgr in 3.14.x

Any idear where this diffrence comes from? Is the capemanagement that diffrent from Debian? I thought they were close relatives?!

Ubuntu is *based* on Debian. Debian uses SYSV init daemon where Ubuntu uses upstart. Starting with Jessie, it looks like Debian will be moving to systemd, and I've heard "talk" that Canonical is considering moving to systemd as well. Also, packages are somewhat different. Where Debian sticks with the "tried and true" approach, Ubuntu has a much more "bleeding-edge" package list. So, with Ubuntu you get newer packages, but sometimes at the cost of reliability. This is not to say that packages in Ubuntu are unstable / unreliable, they're just not tested as rigorously as is done in Debian.

As to where your problem is coming from ? No idea, not enough information given. I'm guessing you were not using a 3.8.x kernel with Debian.

--
For more options, visit http://beagleboard.org/discuss
--- You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pete Douma]

everything went fine, except I get "prussdrv_open open failed"  when I run the pru_loader 

[Peter Gregory]

Hi Pete,

What kernel are you on?
uname -a

The loader will fail if the kernel module is not loaded or the device tree does not enable the PRU device.

[Peter Gregory]

I also have a typo in my notes that the overlay should go in /lib/kernel
It should go in /lib/firmware

[Peter Gregory]

Sorry for the confusion.

[Pete Douma]

Linux beaglebone 3.8.13-bone68 #1 SMP Sat Nov 22 02:12:03 UTC 2014 armv7l GNU/Linux

No problem, I really appreciate your posting this. I would love to see more examples using it. I need to program a specific timing sequence for a TI led

[Peter Gregory]

If your need a timer, each PRU has a ECAP module that can work as a PWM.
You can use the ECAP module's timer to set a flag each time period for timing loops.
I set a timer period of 1/100th second and the PRU runs a tight loop running a stepper motor.
After each step, it waits for the timer to reset, clears the overflow flag and does the next step.
That way the main loop has a fixed delay of 1/100th second per step.

[Peter Gregory]

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
}
}

[Pete Douma]

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?

[Robert Nelson]

On Tue, Dec 9, 2014 at 6:28 PM, Pete Douma <pdo...@adops.com> wrote:
> 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! ;)

[Pete Douma]

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

[Robert Nelson]

On Tue, Dec 9, 2014 at 6:50 PM, Pete Douma <pdo...@adops.com> wrote:
> 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..

[Peter Gregory]

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

[Pete Douma]

I changed the output to P8_11. Now I just need to drive it in C. How do that?

[Peter Gregory]

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

[William Hermans]

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.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

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 ;)

[Peter Gregory]

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.

[William Hermans]

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.

[Valeria M.]

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:


Il giorno lunedì 1 dicembre 2014 16:52:17 UTC+1, RobertCNelson ha scritto:

On Mon, Dec 1, 2014 at 8:53 AM, Karteek YV <venka...@gmail.com> wrote:
> I couldn't install am335x-pru-package and ti-pru-cgt-installer from
> terminal, it gave the following errors when I tried,
> root@arm:/home/ubuntu# apt-get install am335x-pru-package
> ti-pru-cgt-installer
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package am335x-pru-package
> E: Unable to locate package ti-pru-cgt-installer


Sorry, i haven't yet started pushing these to ubuntu.  The ppa on
repos.rcn-ee.net is now live for ubuntu (trusty/14.04) so you'll start
seeing these packages showing up.. (for ubuntu, i'm not planning on
doing non-lts's)

[Robert Nelson]

On Tue, Aug 25, 2015 at 7:32 AM, Valeria M. <valeria....@gmail.com> wrote:
> 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:

enable the repo:

https://github.com/rcn-ee/repos/blob/master/README.md

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Valeria M.]

All done.
Thanks for the quick reply!

V.

[Super Twang]

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

<Linking>

 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

>> Compilation failure

[ken.sh...@gmail.com]

"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

On Monday, December 1, 2014 at 8:57:52 AM UTC-8, RobertCNelson wrote:

On Mon, Dec 1, 2014 at 10:42 AM, Karteek YV <venka...@gmail.com> wrote:
> Sorry, I didn't get your point, are the packages available for ubuntu 14.04?
> The version on my bbb is ubuntu trusty 14.04, I guess it is lts version.
> Still I get the same error 'Unable to locate package' for both the packages
> am335x-pru-package and ti-pru-cgt-installer.

Well:

sudo apt-get update ; sudo apt-get install am335x-pru-package

Should work right "now", give me another 10minutes for the other package..

[William Hermans]

Use git . . .

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9c3533e5-be27-4b2b-adf4-952747b3f35a%40googlegroups.com.