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.
On Wednesday, February 10, 2016 at 9:19:12 PM UTC-5, William Hermans wrote: > > *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 . . . > > > -- 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.
