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/10d2c643-1e9d-4d7e-8c0a-e5dc84369d26%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
