Regarding the device tree, I'm using the "Universal IO" and the
accompanying shell script config-pin and I haven't had any configuration
problems with the PRU pins.
There is an option for config-pin which reads a file and sets all of the
pins per a list of the pins in the file. It works very well. You can put
this command in your .profile or
whatever you do at boot time to set up the pins. I've found this system
works flawlessly and saves a lot of time and confusion.
I have had to tweak the device tree source if a different pull-up/down
resistor is required on a PRU input pin.
Regarding the rmmod problem, use the "force" option -f. This is actually
recommended by TI.
I highly recommend creating simple bash scripts or aliases called
"prumodout" and "prumodin" which execute the rmmod and insmod commands to
remove
and insert your PRU firmwares. Taking it to the next step, you can use
your prumod and prumodin commands in your build script so that the firmwares
are copied to the /lib/firmware directory, old firmwares removed and new
firmwares loaded and started all in a single command.
You should be able to go through a modify-build cycle without reboot, and
very quickly.
Regards,
Greg
On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>
> Alright, I'm making some progress, but am having some issues:
>
> 1. I can't seem to get my device tree to change the mode of pins
> associated with the pruss, but other pins are configured correctly. Is
> there some kind of order that the PRU firmware and device tree has to load
> in?
>
> /* Start EBB-PRU-Example.dts */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> part-number = "EBB-PRU-Example";
> version = "00A0";
>
> /* This overlay uses the following resources */
> exclusive-use =
> "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
>
> gpio_pins: pinmux_gpio_pins { // The GPIO pins
> pinctrl-single,pins = <
> 0x070 0x07 // P9_11 MODE7 | OUTPUT | GPIO pull-down
> 0x074 0x27 // P9_13 MODE7 | INPUT | GPIO pull-down
> >;
> };
>
> pru_pru_pins: pinmux_pru_pru_pins { // The PRU pin modes
> pinctrl-single,pins = <
> 0x1a4 0x05 // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
> PRU
> 0x19c 0x26 // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | PRU
> >;
> };
> };
> };
>
> fragment@1 { // Enable the PRUSS
> target = <&pruss>;
> __overlay__ {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&pru_pru_pins>;
> };
> };
>
> fragment@2 { // Enable the GPIOs
> target = <&ocp>;
> __overlay__ {
> gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&gpio_pins>;
> };
> };
> };
> };
> /* End EBB-PRU-Example.dts */
>
>
> 2. I've got one of the TI examples compiled running as
> /lib/firmware/am335x-pru0-fw
> dmesg seems to show that it loads successfully, without errors.
>
> #include <stdint.h>
> #include <pru_cfg.h>
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;
> volatile register uint32_t __R31;
>
> void main(void)
> {
>
> uint32_t gpio;
>
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> /* gpio = 0x000F; */
> /* gpio = (1 << 5); */
> gpio = 0x0010;
>
> __R30 = 0x0;
>
> /* Toggle the LEDs */
> /* TODO: Create stop condition, else it will toggle indefinitely */
> while (1) {
> __R30 ^= gpio;
>
> __delay_cycles(100000000);
>
> }
> }
>
> As you can see, main is an infinite loop. This means that if I try to
> rmmod pru-rproc, I get the following error:
> rmmod: ERROR: Module pru_rproc is in use
>
> This means that I have to reboot in order to update the code. How do I
> either force the pru to unload or send it signals to stop so I don't have
> to reboot everytime?
>
> Thanks again!
>
> --David
>
>
> On Wed, May 11, 2016 at 5:57 PM, Greg <soapy...@comcast.net <javascript:>>
> wrote:
>
>> Ok, thanks-- no insurmountable legal issues for sharing your own PRU
>> code. Beagleboard PRU fans, please start your code sharing engines!
>>
>> Greg
>>
>>
>> --
>> 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 <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/566d5ab7-7b0d-4445-8c2c-0ed6004d1242%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/beagleboard/566d5ab7-7b0d-4445-8c2c-0ed6004d1242%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/fcf5b029-1239-4ef0-b7d8-2f41822d4416%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
