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 <yyrk...@gmail.com> 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 <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > >> On Feb 20, 2016, at 8:11 AM, Greg <soapy-sm...@comcast.net >> <mailto:soapy-sm...@comcast.net>> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
