The PRU examples that I have pointed out several times do exactly what you are asking for. Also, several other posters have shown how to build these examples without CCSV6. After you build the PRU code, you have to place it in /lib/firmware so that Remoteproc can load it into the PRU, configure resources and start the PRU code.
Regards, John > On Feb 20, 2016, at 12:29 PM, William Hermans <[email protected]> wrote: > > I hope I’m answering your question. > > No, not even close. I need an answer that gives an example in code, how to > use on die peripherals, through the PRU's, when using remoteproc / rpmsg. > Passed that, I do not want to download a couple gigs of data for software I > do not need, or even want. > > What would be really good, would be a github example. Blinking an on board > LED or toggling a GPIO would be the simplest, but anything demonstrating > using the onboard peripherals. ADC, I2C, CAN, or even just GPIO - whichever. > The ARM processor side code would not exactly be so important, except it > would be a good example of how the two sides of software interact with one > another. > > On Sat, Feb 20, 2016 at 1:01 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > Hi William, > > So here is how I like to use this. The PRU is performing some function and I > send commands to modify that function. An example would be controlling the > position of a stepper motor. The ARM app sends a new position and the PRU > takes care of stepping the motor to that new location. I think of the PRU as > being good at doing low latency stuff and I use RPMSG/Remoteproc to send > instructions and then I get feedback on measurements from the PRU. The > interface isn’t fast enough to do anything more that this. Simply flashing an > LED by sending a command isn’t the best use of this technology. Changing the > flashing rate or the duty cycle is more appropriate. I hope I’m answering > your question. > > Regards, > John > > > > >> On Feb 20, 2016, at 11:45 AM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> >> This is an excellent explanation of the workings of Remoteproc/RPMSG. Thanks >> for sharing. >> >> Regards, >> John >> >> Yeah I've seen that, or something similar it is pretty good, except there is >> still one problem. That explanation implies it instructs us how to use the >> PRU hardware with rpmsg, and I suppose on some level it really does. But >> what it does not explain, is how to interact with the rest of the on chip >> hardware through this mechanism. >> >> Sending text messages between ARM, and PRU processors is a good intro >> demonstration of the software, but it is not really the least bit useful in >> the real world. >> >> Anyway, people like me who are very experienced with writing code, will be >> put off using rpmsg etc because of this. Is it really so much to ask for >> example code to demonstrate how to interact with the on die hardware ? >> Without having to download 1GB of pretty much useless library . . . >> >> On Sat, Feb 20, 2016 at 12:23 PM, John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Feb 20, 2016, at 8:11 AM, Greg <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> The support from TI is quite extensive: >>> >>> http://processors.wiki.ti.com/index.php/PRU-ICSS >>> <http://processors.wiki.ti.com/index.php/PRU-ICSS> >>> >>> Download the C compiler manual. There is a section which describes several >>> ways to incorporate assembly code. >>> This looks like a very detailed manual, which combined with the examples in >>> the pru support package should be very helpful. >>> >>> I'm still coming up to speed on all of this, and it's complicated because >>> you have to think about what is going on with the C compiler, remoteproc, >>> rpmsg, and >>> all of the details of what is going with these sort of kernel processes and >>> the virtIO bus mechanism. Too much going on for a Linux newbie, I've had >>> to retreat >>> and study some of the fundamentals before getting back to this (I hope!). >>> >>> You need to be aware the PASM is no longer supported. The path forward is >>> clpru, which is the C compiler which works with the included assembler >>> (asmpru?). >>> There are some differences in the way assembly code is written for the >>> newer assembler (there are notes on this in the command line package >>> download). >>> >>> I was also able to get the examples going with the PRU cape using >>> remoteproc and version 4 kernel (Robert Nelson's testing image). This >>> massively simplified the process >>> compared to what you see the in the TI "Hands On Labs" tutorial. Pretty >>> much everything with regards to remoteproc and the clpru compiler is >>> ready-to-run. You don't need cross-compilation >>> or the IDE, all can be done at the command line on the BBB. If you prefer >>> to operate at the command line all the tools are there. >>> >>> Please correct me if I've got this wrong, but I think it's fair to say that >>> TI has provided a wealth of information for the PRU, however, they expect >>> further support to be coming from the community. >>> >>> Here's another really great contribution by TI: >>> >>> http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg >>> <http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg> >> This is an excellent explanation of the workings of Remoteproc/RPMSG. Thanks >> for sharing. >> >> Regards, >> John >>> >>> Regards, >>> Greg >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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]. For more options, visit https://groups.google.com/d/optout.
