Hi Greg, I’ve pointed this out to William before, but he doesn’t like to use CCSV6, so you are wasting your time ;-)
Hi William, By dead technology, I mean there is no further development expected. All future efforts will focus on RemoteProc/RPMSG. For someone looking to start development with remote processor communications, why spend the time learning a technology that isn’t going anywhere? Rather, spend time learning to use a technology that will be enhanced and supported in future kernels. Regards, John > On Feb 10, 2016, at 4:37 PM, Soapy Smith <[email protected]> wrote: > > 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 >> <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 >> <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] <javascript:>. >> 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] <javascript:>. > 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.
