To clarify question 1 of my original post, I'm checking the pin mode settings with 'cat $PINS' and the PRU pins always show 0x27. I'm asking whether there are any other PRUSS specific requirements in the device tree itself or if the load order of the device tree overlay and firmware matter in order for the '$PINS' file to show that the mode was changed to pru_r30_blah_blah.
Thanks! On Wed, Jun 8, 2016 at 12:07 PM, David Good <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALMFhSy943UZnANYJ3gxvV%3D9LWkKvoBb06vRJCYQdqxrPK3ZOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
