Setting up the PRU

519 views
Skip to first unread message

Alek Mabry

unread,
Nov 4, 2017, 7:18:59 AM11/4/17
to BeagleBoard
Hello!

I've been able to install CCS and the PRU compiler tools to my ubuntu desktop. I've been following this tutorial: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs", However I am stuck on the "Linux Processor SDK" part. I'm assuming it's supposed to be installed on the BeagleBone, but all the tutorials for it seem to act like it's some kind of OS or it's loading files from your computer when it boots or something. I thought there was some sort of cape-overlay that I am supposed to use.

Where to I go from here?

Thanks,
Alek

Jason Kridner

unread,
Nov 4, 2017, 2:28:12 PM11/4/17
to beagl...@googlegroups.com
I do my PRU developement natively. 



Thanks,
Alek

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d1dba4a7-8b48-47a3-ad6e-c55844b2dec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alek Mabry

unread,
Nov 5, 2017, 1:26:31 AM11/5/17
to BeagleBoard
Everything seems to work up until:

debian@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64$ sudo config-pin p9.30 pruout

P9_30 pinmux file not found!

bash: /sys/devices/platform/ocp/ocp*P9_30_pinmux/state: No such file or directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_30_pinmux/state


I am running bone-debian-9.2-iot-armhf-2017-11-02-4gb.img rather than https://rcn-ee.com/rootfs/bb.org/testing/2017-06-11/stretch-iot/bone-debian-stretch-iot-armhf-2017-06-11-4gb.img.xz because it appears that the download link is not there.

Other than that every other command worked.

Alek Mabry

unread,
Nov 5, 2017, 1:27:56 AM11/5/17
to BeagleBoard

debian@beaglebone:/sys/devices/platform/ocp$ ls

40300000.ocmcram          44e35000.wdt    48044000.timer  48060000.mmc       481ae000.gpio                  49000000.edma      4a300000.pruss  driver_override     ocp:l4_wkup@44c00000

40302000.ocmcram_nocache  44e3e000.rtc    48046000.timer  480c8000.mailbox   481d8000.mmc                   49800000.tptc      4c000000.emif   modalias            of_node

44e07000.gpio             47400000.usb    48048000.timer  480ca000.spinlock  48200000.interrupt-controller  49900000.tptc      53100000.sham   ocp:P9_19_pinmux    power

44e09000.serial           48038000.mcasp  4804a000.timer  4819c000.i2c       4830e000.lcdc                  49a00000.tptc      53500000.aes    ocp:P9_20_pinmux    subsystem

44e0b000.i2c              48042000.timer  4804c000.gpio   481ac000.gpio      48310000.rng                   4a100000.ethernet  56000000.sgx    ocp:cape-universal  uevent

Alek Mabry

unread,
Nov 5, 2017, 1:04:02 AM11/5/17
to BeagleBoard
I noticed that USR0 was blinking at a steady rate that was not 5 blinks per second it is supposed to. (After I ran sudo make run). There was no way to make it stop blinking with the /sys/class/leds/ commands. I restarted the beaglebone and was able to control whether it did a heartbeat/none with trigger, but after I ran "sudo make run" it did the blinking again. 

I changed the hello-pru.c so that the INS_PER_US was 50 instead of 200 and recompiled and it appears to be blinking four times as fast, so the PRU is controlling the LED without having to run "sudo config-pin p9.30 pruout."

Robert Nelson

unread,
Nov 5, 2017, 8:55:20 AM11/5/17
to Beagle Board, Alek Mabry
On Sun, Nov 5, 2017 at 12:26 AM, Alek Mabry <alekm...@gmail.com> wrote:
> Everything seems to work up until:
>
> debian@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64$ sudo
> config-pin p9.30 pruout
>
> P9_30 pinmux file not found!
>
> bash: /sys/devices/platform/ocp/ocp*P9_30_pinmux/state: No such file or
> directory
>
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_30_pinmux/state

P9_30 = hdmi audio

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

So you add:

disable_uboot_overlay_audio=1

to /boot/uEnv.txt

Regards,

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

Alex Bagehot

unread,
Nov 5, 2017, 9:42:02 AM11/5/17
to beagl...@googlegroups.com
I hit this but for a different reason - I got a pocket beagle a few days ago.

I had a look at /usr/bin/config-pin.
Would I be correct that to translate P9_30 to pocket beable,
on a BBB(assuming that's what the steps are targeted at) P9_30 is pru pin 144
so the equivalent on pocket beagle is P2_32 ?
eg.
$ sudo perl /opt/scripts/device/bone/show-pins.pl -v | grep P9.30
P9.30                            102 D12 fast rx down 7 gpio 3.16        ocp/P2_32_pinmux (pinmux_P2_32_default_pin)

Either way, how would I map any of these IDs to the pinout/ expansion headers diagram?

Looks like show-pins (https://github.com/mvduin/bbb-pin-utils) supports BBB. 
It confused me at first that P8 and P9 were being reported.
Is is something that could be enahnced to support the pocket beagle?

Thanks in advance,
Alex
 

Regards,

--
Robert Nelson
https://rcn-ee.com/
--
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/CAOCHtYg3zMOM3xtcd19zv-FMBG-idkaLzcsW84M7XXpT_bzgaw%40mail.gmail.com.

Jason Kridner

unread,
Nov 5, 2017, 9:51:29 AM11/5/17
to beagl...@googlegroups.com, Alek Mabry
Looks like I chose a bad pin for a good default demo. This is a different pin than used for the on-board LED. I tried to show both a PRU GPIO (via p9.30) and an OCP GPIO via the on-board LED.

So, the LED still blinks because it is a different line that is controlled via the OCP GPIO rather than the PRU GPIO.

>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYg3zMOM3xtcd19zv-FMBG-idkaLzcsW84M7XXpT_bzgaw%40mail.gmail.com.

Jason Kridner

unread,
Nov 5, 2017, 10:00:26 AM11/5/17
to beagl...@googlegroups.com
On Sun, Nov 5, 2017 at 1:04 AM Alek Mabry <alekm...@gmail.com> wrote:
I noticed that USR0 was blinking at a steady rate that was not 5 blinks per second it is supposed to.

Looks like I adjusted the rate without updating the README.md. I also tried to add a mode that allows for a "decay" where the cycles between toggles gets shorter and shorter. With that mode, you can see a bit more of the power of the PRU to toggle pins quickly, although you quickly get to a point where you'd need a scope to see how fast the PRU is toggling the GPIO.
 
(After I ran sudo make run). There was no way to make it stop blinking with the /sys/class/leds/ commands.

Right. Because the PRU is controlling the GPIO and not Linux, the /sys/class/leds interface wouldn't stop it from toggling. However, you might note that Linux might still set or clear the LED at times, so both Linux and the PRU can collide with each other. That's why my instructions say to set the trigger to "none".
 
I restarted the beaglebone and was able to control whether it did a heartbeat/none with trigger, but after I ran "sudo make run" it did the blinking again. 

I changed the hello-pru.c so that the INS_PER_US was 50 instead of 200 and recompiled and it appears to be blinking four times as fast, so the PRU is controlling the LED without having to run "sudo config-pin p9.30 pruout."

As mentioned elsewhere on this thread, p9.30 is for the PRU GPIO and the USR0 LED is controlled via an OCP GPIO. PRU GPIOs can be controlled much faster, but the LEDs aren't connected to pins that have pruout modes. My example illustrated toggling both an OCP GPIO and a PRU GPIO. PRU GPIOs can be set with registers directly in the PRU core rather than needing to write to an OCP (on-chip-peripheral) memory address. 

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

For more options, visit https://groups.google.com/d/optout.
--

rogeri...@gmail.com

unread,
Jan 30, 2019, 2:54:06 PM1/30/19
to BeagleBoard
Hello everyone, I'm trying to run an example of PRU to flash a led and I'm using P9_41 and P9_27, but to no working.

Can someone help me?

I created a dts and accredited that is correct, see the output of the show-pins.pl script:
P9.31 / hdmi audio clk           100 A13 fast rx down 7 gpio 3.14
P9
.29 / hdmi audio fs            101 B13 fast rx down 7 gpio 3.15

P9
.30                            102 D12 fast rx down 7 gpio 3.16

P9
.28 / hdmi audio data          103 C12 fast rx down 7 gpio 3.17
P9
.42b                           104 B12 fast rx down 7 gpio 3.18
P9.27                            105 C13 fast         7 gpio 3.19        pruss@4a300000 (pinmux_pru_pru_pins)
P9.41                            106 D13 fast         7 gpio 3.20        pruss@4a300000 (pinmux_pru_pru_pins)
P9
.25 / audio osc                107 A14 fast rx down 7 gpio 3.21
P9
.41 / jtag emu3                109 D14 fast rx down 7 gpio 0.20


Here my DTS:
/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>

 
/ {
   
// This determines which boards can use this DTS overlay
   compatible
= "ti,beaglebone", "ti,beaglebone-green", "ti,beaglebone-black";

   
// I think part-number is supposed to correspond with the filename,
   
// so we'd save this as "PRU-GPIO-MTV-00A0.dts".
   part
-number = "PRU-GPIO-MTV";

   version
= "00A0";

   exclusive
-use =
     
"P9.41", "P9.27", "pru0";

   fragment@0
{
    target
= <&am33xx_pinmux>;
    __overlay__
{
      example_pins
: pinmux_pru_pru_pins {

       pinctrl
-single,pins = <
         
0x1a8 0x0f
         
0x1a4 0x0f
       
>;
     
};
   
};
   
};

   
// This enables the PRU and assigns the GPIO pins to it for use in EGP mode.
   fragment@1
{
    target
= <&pruss>;
    __overlay__
{
      status
= "okay";
      pinctrl
-names = "default";
      pinctrl
-0 = <&example_pins>;
   
};
   
};
 
};

Reply all
Reply to author
Forward
0 new messages