I understand that bringing up GPIOs low is good practice. I meant when I set the P8_11 using "config-pin P8_11 pruout" the pin is automatically pulled high it appears. Is there a way to set it as a "pruout" but as a low pruout to start. It appears to be defaulting to "HI" mode when set to "pruout"
Also I had thought that remoteproc was a program with an interface that allowed the user to load a compiled program to the PRU when the host c script was run, I didn't realize it only kicked in at initialization and loaded specific files in /lib/firmware. I was origianlly under the assumption that I needed to enable the remote_proc and uio_pruss and then use the following API in order to load and run the PRU program. http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide#prussdrv_map_prumem Am I over complicating things? Also I have been avoiding use CCS because I wanted to avoid dependencies on automatic tools that abstract away what is running and how. On Tuesday, November 15, 2016 at 10:52:08 AM UTC-5, Greg wrote: > > It's generally considered good design practice to bring up GPIOs low. But > there are exceptions. I'm not sure what the PRU will do when it is > disabled. > I did the same thing months ago, and I do remember LEDs being lit or dimly > lit after boot. Ultimately I got past that concern and it didn't seem to > be a problem. > > The Remoteproc framework does the job of loading the firmware into the > PRUs. This happens seamlessly and the user doesn't do this explicitly. > The firmwares should be compiled with clpru and renamed to am335x-pru0-fw > and am335x-pru1-fw respectively and then copied to /lib/firmware. So you > have 2 firmwares each indendently running in the PRU0 and PRU1. Of course > they can interact in various ways. You could also use only one PRU if you > don't need both by only having one firmware in /lib/firmware. > > There are special files which the clpru must incorporate into the > compilation process and ultimately the firmware. I've added a little > section on this in the PDF file. The TI folks gave me this info. > Remoteproc and Linker involved. > > Best thing to do is to examine the labs and examples in the PRU software > package provided by TI. The labs instructions are designed for the CCS > IDE. You can avoid that and get everything done on the Beaglebone via SSH > and command line. Really not that hard and you need to be an expert at the > command line anyway if you want to be an embedded systems designer. Maybe > I'll use CCS later, but for now SSH + command line is working for me well. > Look at the Labs instructions anyway, as this will give a whole bunch of > hints and clues on how to deal with Remoteproc and PRUs. There is also an > examples directory which overlaps some of the labs. Good stuff in there, > you can dig into the C code and see how to get things done. > > A good start is the usual LED blinker, this will show how to manipulate > the __R30 register to make the header pins go HIGH and LOW programatically > from the PRUs. > You will find the compiler intrinsic __delay_cycles() to be extremely > useful. > > On Tuesday, November 15, 2016 at 10:13:32 AM UTC-5, Zach B wrote: >> >> 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. >> > -- 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/7e03081f-7862-4875-9d75-a8816f9614bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
