> > > > > *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*
We'll just have to agree to disagree. Since I'm a very experienced programmer who has not had any problems setting up, or writing / using software for multiple other aspects of the hardware. Somehow, it must be my fault. On Sat, Feb 20, 2016 at 2:08 PM, John Syne <[email protected]> wrote: > 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]> 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]> 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]> wrote: >> >>> >>> On Feb 20, 2016, at 8:11 AM, Greg <[email protected]> wrote: >>> >>> The support from TI is quite extensive: >>> >>> 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 >>> >>> 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 >>> --- >>> 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. >>> >>> >>> >>> -- >>> 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. >>> >> >> >> -- >> 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. >> >> >> >> -- >> 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. >> > > > -- > 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. > > > -- > 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. > -- 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.
