> > *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?* >
Whatever works for you. Me, I opted for C in Linux of course, and ASM for the PRU's because it is the best documented. But I've experimented with it all including attempting remoteproc . . . The assembler I decided to use was the one included with the am335x_pru_package. I have not really spend a lot of time writing PRU assembly yet, but was reading up on the registers, etc, and then got busy with other things. But I did start to understand the prussdrv driver, and API set . . . Anyway, pick something, and go with it. If you ask me the old way of using the PRU is the best way to go right now. Later, when remoteproc / rpmsg is mainline, and perhaps well documented. Then I personally plan on giving it a more serious look. Right now, I consider it a toy . . . On Wed, Feb 10, 2016 at 3: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.
