> > *Hi William, one note on CCS. I haven't used it at all. The > compiler/assembler (clpru) and associated includes and libraries are > present in the Beaglebone testing image (Debian 8, version 4 kernel).* > *I had to tweak add a symbolic link for the clpru, but that's it. After > that, the Makefiles included in the labs worked perfectly. All done at the > command line. No CCS IDE required.* > *I wasn't excited about CCS either, but then I discovered the clpru stuff > and no problems.*
Hi Soapy, Yeah there was what ? 3 different ways one could go. Well technicaly 4-5 I guess including following the gcc path. I messed with attempting to get the standalone TI C compiler, on a cross(Lubuntu 14.04 x64 ) system. No joy after I guess about a day and a half. Normally, I probably would have gotten it to work, but after playing around with that, and several other things all related to the PRU's I decided to toss in the towel. In relation though I was able to work with a custom am335x_pru_package git, that included example code for using the USR LEDs, and a dmx light controller. The USR LED example I got working straight off, no problem, and I'd assume the dmx controller would also have worked, but I had no hardware to test. Plus the am335x_pru_package driver uses UIO, which I find really interesting, and indeed really easy to write a custom driver for when the need arises. Or, more likely just modify the existing one, but it's really easy to read through and understand . . . On Wed, Feb 10, 2016 at 8:41 PM, John Syne <[email protected]> wrote: > 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]> 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. > > > -- > 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.
