> > *Hi Greg,* > > *I’ve pointed this out to William before, but he doesn’t like to use > CCSV6, so you are wasting your time ;-)* >
Actually John, I was well aware of that guide long before you ever mentioned it. *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. * That's not for you, or even TI to decide. That is for the community to decide. Especially since TI has pretty much refused to support the PRU since day one. As for what who does when. You seem to conveniently selectively reading what I write in my post. As I've said like 500 times already. I do not care what people use. I will however come into a post like this where the OP originally posted in relation to something am335x_pru_package specific. and you or anyone for that matter jumps in suggesting to use remoteproc / rpmsg. Why ? Because obviously this person has a time investment into the am335x_pru_package already. I'd like to try and save them from chasing yet another rabbit down yet another useless rabbit hole. As many people here use this software in products, school projects, or just something very serious in the hobbyist circles. They do not care what you think about some experimental bit of software that has yet to be proven . . . You're like TJP or whatever his name. Everything is a nail, except instead of prusio, or whatever it is, remoteproc is your hammer. On Wed, Feb 10, 2016 at 7:22 PM, John Syne <[email protected]> wrote: > 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]> 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. > > > -- > 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.
