Here is what Robert Nelson said on Dec 17, 2015: "If you want "uio_pruss" use "4.1.x-bone", while this "4.1.x-ti" branch is developing "pruss_remoteproc" which will be replacing uio_pruss…”
If you look at the development off uio_pruss, it was developed in 2011 and has a few update/fixes since then, but no new development. With RemoteProc/VirtualIO, it is possible to implement custom hardware interfaces on the PRU such as Profibus, Ethernet, UART, i2C, SPI, ADC, DAC, etc and make those look like a device to the Linux kernel. Regards, John > On Feb 10, 2016, at 6:35 PM, William Hermans <[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 ;-) > > 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] > <mailto:[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] >> <mailto:[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 >> >> <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 >>> <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 >>> <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] <>. >>> 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] <>. >> 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 > <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 > <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.
