I guess a better question would be, what libraries or other files need to be linked to create a file that will load and execute on the PRU? I can compile my code but the linking is a bit of a black box to me. I have been reading a lot of PRU reference documentation and haven't come across the answer yet. I'm still working my way through "PRU Optimizing C/C++ User Guide".
On Sunday, November 27, 2016 at 5:36:15 PM UTC-5, Zach B wrote: > > Has anyone compiled a straight assembly file for the PRU? I know you can > program in C but I can't accurately predict how long each C command takes > to run and I have a time critical portion of my code. > > I have been attempting to use the clpru compiler but I keep getting > linking errors as it is looking for a main function call and not finding > one, since it's just an assembly file. Is it possible to compile assembly > with clpru and link to all of the proper files to ensure it compiles and > runs correctly on the PRUs? I know I ran into that issue in the past when > tried to use pasm and didn't add any linked files. > > On Monday, November 21, 2016 at 12:03:54 PM UTC-5, William Hermans wrote: >> >> There are a few things to note on this subject. >> >> #1 >> >> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L522-L527 >> >> Of these 3 capes shown, only cape-universala will work unmodified. This >> is because this pin in the other two cape overlay's is commented out. >> >> #2 >> Going by the ball info /* P9_31 (ZCZ ball A13) Audio */, this must be an >> HDMI audio pin too ? So you'll probably want to edit /boot/uEnv.txt to load >> this board file. >> >> ##BeagleBone Black: HDMI (Audio/Video) disabled: >> dtb=am335x-boneblack-emmc-overlay.dtb >> >> Initially the line dtb=am335x-boneblack-emmc-overlay.dtb will be >> commented out. Then once you make sure you have that uncommitted, make sure >> no other board file is left uncommitted after this line. Otherwise it may >> load at boot instead. >> >> Once that is done, you should be able to configure the pin via config-pin >> to mux the pin for mode 5, or 6 depending on whether you want GPI, or GPO >> through the PRU. >> >> >> On Mon, Nov 21, 2016 at 8:52 AM, Zach B <zbro...@gmail.com> wrote: >> >>> Sorry for the deleted post I forgot a piece of information... >>> >>> So I'm not exactly sure what modifications I made that fixed my problem >>> because I made a few and somewhere it resolved my issue. I ended up >>> modifying the files listed below. I don't think I had to modify all of them >>> but I figured I would enable the pru_rproc for all variations of device >>> trees that load for future use (whether this is good or bad idk). >>> Uncomment '#include "am33xx-pruss-rproc.dtsi"' in the following files >>> as desired >>> >>> /opt/source/dtb-4.4-ti/src/arm/am335x-boneblack-overlay.dts >>> /opt/source/dtb-4.4-ti/src/arm/am335x-boneblack-audio.dts >>> /opt/source/dtb-4.4-ti/src/arm/am335x-boneblack-hdmi-overlay.dts >>> /opt/source/dtb-4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts >>> >>> be sure to run "make" followed by "make install" after making the above >>> modifications. >>> >>> I then modified my uEnv.txt file as follows: >>> Change >>> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled: >>> #dtb=am335x-boneblack-overlay.dtb >>> to >>> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled: >>> dtb=am335x-boneblack-overlay.dtb >>> this should enable the device tree file "cape-universala-00A0.dts" on >>> boot. The "cape-universala-00A0.dts" has all of the pins pinmuxed and >>> configured for all modes, so it should blow everything wide open for use >>> with config-pin. it worked for all of the pins I wanted to configure. The >>> universal capes can be found (at least for me) at >>> /opt/source/beaglebone-universal-io/ >>> >>> or you can check them out on this github link: >>> https://github.com/cdsteinkuehler/beaglebone-universal-io >>> >>> Doing those 2 things seems to have allowed me to configure any pin I >>> want and starts the pru_rproc on boot ensuring all of the required devices >>> are there to start and stop the PRUs. I ended up not having to mess around >>> with any custom device trees. Hopefully that information helps someone else >>> struggling with the same thing I was. >>> >>> On Sunday, November 20, 2016 at 7:25:06 PM UTC-5, William Hermans wrote: >>>> >>>> On Sun, Nov 20, 2016 at 4:31 PM, Zach B <zbro...@gmail.com> wrote: >>>> >>>>> Thanks for the information Greg. >>>>> >>>>> Robert & everyone, >>>>> I was digging into that link you sent about which universal overlay >>>>> gets loaded at boot. I have tried modifying my uEnv.txt file to enable >>>>> different overlays but i cant' seem to get config-pin to work for P9_31 >>>>> and >>>>> P9_29. It responds that config-pin isn't set up for those pins but when I >>>>> run >>>>> config-pin overlay cape-univversala >>>>> >>>>> it seems to load just fine but when I call either: >>>>> config-pin-q P9_31 >>>>> config-pin P9_31 pruout >>>>> >>>>> it says that it is unable to access the "state" of that pin or set the >>>>> "pinmux". What's the right way to enable config-pin on all of the pins so >>>>> that I can set the PRU pins I need to "pruout"? >>>>> >>>>> Zach >>>>> >>>> >>>> Most likely this is because the universal IO overlay you're loading >>>> does not have those pins muxed. I have run into this myself when working >>>> with a custom cape( physical hardware ). So, I have to create a custom >>>> overlay based on more than one universal IO overlay. Then once I gleaned >>>> how the structure for each pin had to be in the overlay, I modified the >>>> overlay further to only define the exact mux for each pin. That is, >>>> removing all the extra mux modes I did not need. >>>> >>>> So, in short, you're going to have to create your own overlay file >>>> based on multiple universal IO overlays, if you want to use config-pin to >>>> mux the pins. If you just want to use config-pin to load an overlay, then >>>> your overlay does not *have* to be based on a universal IO overlay. >>>> >>>> -- >>> 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/41cefc20-ff0c-49ba-a780-8d25bf4216da%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/41cefc20-ff0c-49ba-a780-8d25bf4216da%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/bc3624c2-62d3-4d8b-9e9d-ee09ed0a1a22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
