Good suggestions Greg! I didn't know about rmmod -f. You learn something
new every day!
I didn't even know about config-pin until yesterday, since I've only ever
used device trees in the past. I guess config-pin might actually be the
best option for my stage of development, but I would like to get the PRU
pins configured with device trees eventually, since that feels more like
the right "embedded" thing to do ;)
--David
On Wed, Jun 8, 2016 at 9:18 AM, Greg <soapy-sm...@comcast.net> wrote:
> 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> 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.
>>> 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
> <https://groups.google.com/d/msgid/beagleboard/fcf5b029-1239-4ef0-b7d8-2f41822d4416%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/CALMFhSy-uD46GDuirUCW-DRMbSkA07NpX-DkkUNxKhb%2B2LyOrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
