Excellent! It's challenging to get Remoteproc to work and remember it is still experimental, still evolving. So remember what works today may not work tomorrow when you update your OS. But I think that is more or less true with all of Linux!
The only question I can even halfway answer is #1. The Universal IO has more than one possible overlay. I think a different overlay might solve this problem. Looking in /lib/firmware, I see 5 different "univ" overlays. How to change them? I don't know. My boards are booting up with univ-emmc in slot 4. That overlay has been sufficient for my projects so far, but it might not be enough for the next. I tried a few experiments, and only got errors. I'm sure the process is simple, but I can't tell you what it is. We really need to find more documentation on how to use the Universal IO. The README on github seems to be a bit behind the current design. The other questions I have no idea! Hopefully a PRU expert can comment on those. I've made some progress on translating the motor controller to BBG non-CCS and latest interrupt scheme. The code in that project is way more complex than anything I have seen so far. I wonder if it represents something close to the upper limit of how much code you can jam in a single PRU? I'll get it to github, hopefully pretty soon. On Saturday, November 19, 2016 at 9:27:38 PM UTC-5, Zach B wrote: > > Thank you for all of the help Greg, I was finally able to get one of the > examples to compile and execute. I'm still doing a bit of reading with > regards to the reference manuals to figure out the proper registers and > values for everything. I did have a few left over questions though. > > 1) Is "config-pin" able to override the HDMI allocation on pin header 8 or > is that something that needs to be taken care of in the master device tree > that gets loaded? It seems whenever I activate the HDMI/emmc disable > portion of the uEnv.txt it disables my ability to start and stop the PRUs > with the echo command. The device is just no longer found, but if I can > simply override those pin settings and switch them to PRU outputs without > having to use anything in the uEnv.txt then that works just as well, even > better if I don't have to mess with the device tree again haha. > > 2) My second question, is there a better way to execute tasks at specific > timing intervals that having one PRU count and set bits in shared memory > for the other PRU? I guess I am asking if there are internal timer > interrupts that I could use to trigger events or ISRs? > > 3) Has anyone ever put a simplified RTOS on the PRUs or are they not > capable of handling that? Seems like you could use a combination of both > PRUs to accomplish some pretty cool timing or interrupt driven real time > tasks. > > Thanks again for all of the help, I couldn't have done it with you guys! > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b20df5fe-efa9-4dd4-85e6-7264496d14cd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
