http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_Blinking_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. >>>> >>>> >>>> >>> -- >>> 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] <javascript:>. >>> 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] <javascript:>. >> 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] <javascript:>. >> 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.
