Thanks for the detailed response that helped clear up a bit of confusion I was having. I've also been rereading through your pdf. I got the remote_proc up and running again. I started playing around with config-pin and "Universal IO" and was able to successfully toggle the pins how I wanted. However, I still have a few questions. I am debugging with a simple led attached to some pins, ultimately I am going to be driving some ESCs and then later building a custom brushless DC motor controller but that's another animal.
First question, when I set pin P8_11 to "pruout", my testing led turns on, does this mean that the pin is automatically set to "out hi" until I change it again with config-pin? Is there a way to set the pin mode to PRU control and then modify it by writing the desired 1 or 0 to the corresponding register in the PRU code? Second question, is there a way to load a PRU binary program (either compiled c or assembly) directly to the PRU's from the command line or do I need a separate c program for that? That's the part I seems to be stumbling over is how to get the program onto the PRU. I have some device tree questions, even though you recommended against them. With the device trees, is there a list somewhere of the possible targets that you can set? I have seen &ocp or &pruss and a few others but I don't fully understand what these mean. If anyone has a good link to learning about each piece of the device trees I will gladly take that as well. On Tuesday, November 15, 2016 at 8:06:38 AM UTC-5, Greg wrote: > > > Just my advice, especially for a newbie PRU person (maybe even an > experienced one too), don't touch the Device Tree! At least not directly: > > https://github.com/cdsteinkuehler/beaglebone-universal-io > > (Note the path to slots is not the same for 4x kernels) > > I've been using the Debian 8.6 IOT image and the "Universal IO" is already > installed, ready to work its magic. > Follow the directions at the above repository. This will save you much > time fiddling with the Device Tree stuff, highly recommended! > The config-pin utility is AWESOME, try it! > > One thing config-pin can't do. And that is change the pull-up/pull-down > settings on the pads. In that case you may have to tweak a device tree. > But this is relatively simple and won't waste piles of your time debugging. > > Another something to be aware of which can burn time like no tomorrow: > Header P8. There are pins on this header which determine how > the boot process proceeds. Not all of them, but some of the overlap > possible PRU IO. I would avoid these if you can! Use config-pin and > set your PRU IO to pins on header P9 as required. Some pins on P8 are > safe, but proceed with caution. > Even light resistive loading on these pins will corrupt the boot process! > > You can go to the Beaglebone Black system reference manual to see this: > > http://elinux.org/Beagleboard:BeagleBoneBlack#Hardware_Files > > Check out page 68, diagram Figure 38. Note the "LCD_DATA" pins. > Then go to page 84, and you can see which pins on P8 to avoid. > There are probably enough PRU IO possible to route to P9 for many projects. > > I think prussdrv is a UIO related kernel module, not Remoteproc related. > I don't recall seeing that one. > Activation of Remoteproc may not have happened. Use lsmod and look for > pru_rproc, pruss, and pruss_intc. > > With regards to manually running Remoteproc, you can > > modprobe pru_rproc > > to insert and start Remoteproc and > > rmmod pru_rproc > > to remove it (using root privilege). > > To stop and start firmwares already loaded into the PRUs: > > echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind > echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind > > echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind > echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/unbind > > So this is the Debian image I am using successfully: > > bone-debian-8.6-iot-armhf-2016-10-30-4gb.img > > Get that here: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian > > Once again, using the above image, don't touch device tree files (except > one very trivial change to activate Remoteproc) and use config-pin to > change pin modes to PRU. All ready to go on this image. > Get Remoteproc activated and see if you can get the Remoteproc related > kernel modules to appear in lsmod. > > I've attempted to very carefully describe the process in the PDF file here > and did a bunch of updates last weekend: > https://github.com/Greg-R/pruadc1/tree/master/doc/PRUADC1latex > > Regards, > Greg > > On Monday, November 14, 2016 at 10:17:40 PM UTC-5, Zach B wrote: >> >> Hey everyone so I took one step forward and one step back. With the last >> bit of help from Robert I was able to properly disable the universal >> overlay and load my own. It appears that my device overlay loads correctly. >> When I went to test things today however I can't seem to get the >> remote_proc to turn on by following the elinux example like last time. I >> follow all of the steps. I get no errors, but nothing happens. I haven't >> looked through the boot dmesg yet so it could be in there. Is there another >> way to manually turn on the remote_proc? >> >> On a different note after reading some of your comments I am a bit >> confused. Is the device tree overlay the proper way to go about setting the >> header pins to the PRU or not? Also is there a command line method to >> working with the PRUs that would let me test the pins to ensure they are >> working? >> >> I tried compiling a simple c script to run the PRU but I keep getting the >> error pruss/prussdrv.h: no such file or directory. Are the pruss files >> something that needs to be included on my LIBRARY path or LD_LIBRARY path >> or is it an extra package I need to download? >> >> >>> -- 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/2ddb1e32-d499-4ca5-a9d8-49433dcec7dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
