Not to add add data points to the flames but - That example code in that link works fine. Was able to use that sample code to build a rpmsg simulator for other hw using the PRU. The PRU firmware creates 2 rpmsg channels that gets messages sent between then. Setup is: Kernel driver A is a I2C driver attaches to one rpmsg channel. It reads data from the I2C channel and forwards it to the PRU using that rpmsg channel.
Kernel driver B is rpmsg/IIO driver that attaches to the other rpmsg channel and sends out IIO data based on the rpmsg packets from the PRU. Having used both UIO_pruss and remote proc/rpmsg - - remoteproc/rpmsg is a lot easier to use with standard kernel interfaces (i.e. tying in I2C, etc). - remoteproc/rpmsg really works better with the C compiler which adds a layer of overhead compared to pure ASM. The UIO_pruss interface gives a raw processor which simplifies pure ASM code. - Passing large amounts of data using rpmsg could have considerable overhead. For example, I would just do just pure remoteproc or stay with UIO for my PRUSS driven video capture code. But for slower data rates, rpmsg could simplify things as the buffer management/interrupt/driver attachment code is done for you. - Just keep in mind resources are limited on the PRUSS and accessing resources outside of the PRUSS can be expensive. On Wednesday, February 10, 2016 16:37:12 Soapy Smith wrote: > http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_B > linking_LEDs_with_RPMsg_from_Linux_User_Space > > Hi William, please see the above. I have the PRU Cape, but I haven't got > this far in the labs. The other labs with remoteproc and other associated > modules works so far. > > Regards, > Greg > > On Wednesday, February 10, 2016 at 7:25:27 PM UTC-5, William Hermans wrote: > > *William, what are you talking about? Why would I take what you say > > > >> personally? You make these blanket statements about a technology you say > >> you don’t know how to use and recommend that everyone else not use this > >> technology. If you want to stay with a dead technology, that is your > >> call, > >> but there is no reason for anyone to stay away from RemoteProc/RPMSG. > >> Manufacturers other than TI have embraced this technology which open up a > >> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. > >> Yes, > >> I know you told me you have no interest in the x15 so this is probably > >> not > >> important to you and I respect that. * > > > > So, using something consistent , that is well documented, and has been > > proven to work over the last several years does not make it "dead tech". > > It > > makes it something that actually works for many people. No one cares what > > TI adopts, except perhaps you, and TI. People care what works, with the > > least amount of resistance. > > > > So hey lets put the squash on this right now. Why don't you write us some > > code in the next day or two that blinks the USR leds in some kind of > > pattern that proves the remoteproc / rpmsg is actually functional / > > usable. > > As no one cares if you can write 100 "hello world " messages into > > /var/log/messages . . . I can do that with a bash script and no PRU . . . > > > > You do that, and I'll concede that remoteproc is at least semi useful. > > > > > > On Wed, Feb 10, 2016 at 4:57 PM, John Syne <[email protected] > > > > <javascript:>> wrote: > >> William, what are you talking about? Why would I take what you say > >> personally? You make these blanket statements about a technology you say > >> you don’t know how to use and recommend that everyone else not use this > >> technology. If you want to stay with a dead technology, that is your > >> call, > >> but there is no reason for anyone to stay away from RemoteProc/RPMSG. > >> Manufacturers other than TI have embraced this technology which open up a > >> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. > >> Yes, > >> I know you told me you have no interest in the x15 so this is probably > >> not > >> important to you and I respect that. > >> > >> Soapy, I use the drivers from Starterware and adapt them to work on the > >> PRU, so I always use the C compiler. There is a github repo were several > >> of > >> the Starterware drivers have been ported to the PRU. This will save you a > >> bunch of time. > >> > >> Regards, > >> John > >> > >> > >> > >> > >> On Feb 10, 2016, at 2:47 PM, William Hermans <[email protected] > >> <javascript:>> wrote: > >> > >> Hi Soapy, > >> > >> Yeah John always seems to take things personally, or out of context. I > >> have no problem what so ever with anyone using whatever they want. > >> Including the OP. My comment were merely to point out that remoteproc / > >> rpmsg are not finished, have known issues, and are a pain in the backside > >> to initially get working. > >> > >> So for someone using prussdrv, it is probably a bad idea to even start > >> thinking about using remoteproc / rpmsg. Unless they're just > >> experimenting > >> . . . where then it could be a good learning experience I suppose. Me . . > >> . > >> I'd rather something were fully functional and well documented before I > >> invest my time into it. remoteproc is neither of these. > >> > >> On Wed, Feb 10, 2016 at 3:42 PM, Soapy Smith <[email protected] > >> > >> <javascript:>> wrote: > >>> remoteproc definitely has some bad behavior. But what I am doing is > >>> just as experimental, and no motors (all data transfer) involved. > >>> > >>> What is currently considered a reliable methodology for getting the most > >>> out of the PRUs? > >>> Also, what about C versus assembler? Will C alone suffice, or is there > >>> real need to do some assembler? > >>> I've found that there are actually two different assemblers, the older > >>> pasm (apparently no longer supported), and the assembler part of clpru. > >>> If you are just starting out in PRU work, should pasm even be > >>> considered? > >>> > >>> Regards, > >>> Greg > >>> > >>> On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans > >>> > >>> wrote: > >>>> I would recommend staying away from remoteproc and rpmsg at least until > >>>> it's out of experimental. -- Hunyue Yau http://www.hy-research.com/ -- 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.
