> > *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.* >
Hi Soapy, Thanks, but I have been aware of that guide for some time now. The example, blinks a PRU cape LED, not one of the USR leds on beaglebone. That's problem #1( not everyone wants to buy yet more hardware to explore an experimental concept). Problem #2 the guide is based on code composer studio. If you can not see the problem with that, then chances are I will probably never convince you it is a problem. For many of us though, a requirement of using CCS is a major problem. Problem #3, there is no in depth code explanation, just setup "do x.y.z exact steps", and thats it. So, for me, no code explanation is not really the problem. The problem is no one bothers explaining how the rpmsg mechanism works in conjunction with our specific hardware. That is to say, many of us already know how the hardware works, but how do "WE" control the hardware through this software ? 1 or 2 *good* examples would go a very long ways here. Problem #4, as ybeagle3 mentions above, performance. If we're wanting to use a PRU or two, chances are pretty good we want / need performance. Granted, there are probably ways to tweak rpmsg, but at some point one has to wonder why even bother. Problem #5, and possibly the biggest turn off for me aside from very little documentation. This software is experimental, incomplete, and has no proven track record. Which means, no one knows how stable the software is right now. Anyone saying they know if full of it. While on the other hand, the UIO PRU based software has been around a good long time, is proven, and is probably in many commercial grade applications. Not to mention scientific applications, etc. Anyway, I still think remoteproc / rpmsg is a really cool idea - In concept. In reality though it has a very long ways to go, and no telling if it will ever make it passed the experimental stage. Then if it does, how long will it take ? Another thing. This hardware( beaglebone ) is an open sourced design. So who in their right mind thought it would be a good idea to demonstrate such a cool idea using a closed source toolchain / toolset ? Oh, right. The same company who says they do not support the PRU's to begin with . . . Do also keep in mind, that I actualy am PRO TI . . . On Wed, Feb 10, 2016 at 6:22 PM, <[email protected]> wrote: > Not to add add data points to the flames but - > > That example code in that link works fine. Was able to use that sample > code to > build a rpmsg simulator for other hw using the PRU. The PRU firmware > creates 2 > rpmsg channels that gets messages sent between then. Setup is: > Kernel driver A is a I2C driver attaches to one rpmsg channel. It reads > data > from the I2C channel and forwards it to the PRU using that rpmsg channel. > > Kernel driver B is rpmsg/IIO driver that attaches to the other rpmsg > channel > and sends out IIO data based on the rpmsg packets from the PRU. > > Having used both UIO_pruss and remote proc/rpmsg - > - remoteproc/rpmsg is a lot easier to use with standard kernel interfaces > (i.e. tying in I2C, etc). > - remoteproc/rpmsg really works better with the C compiler which adds a > layer > of overhead compared to pure ASM. The UIO_pruss interface gives a raw > processor which simplifies pure ASM code. > - Passing large amounts of data using rpmsg could have considerable > overhead. > For example, I would just do just pure remoteproc or stay with UIO for my > PRUSS driven video capture code. But for slower data rates, rpmsg could > simplify things as the buffer management/interrupt/driver attachment code > is > done for you. > - Just keep in mind resources are limited on the PRUSS and accessing > resources > outside of the PRUSS can be expensive. > > > > On Wednesday, February 10, 2016 16:37:12 Soapy Smith wrote: > > > http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_B > > linking_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. > > -- > Hunyue Yau > http://www.hy-research.com/ > > -- > 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.
