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] 
> <mailto:[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] 
> <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.

Reply via email to