> > *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]> 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]> 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]> > 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]. >> 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.
