Thanks for the information Greg.

Robert & everyone,
I was digging into that link you sent about which universal overlay gets 
loaded at boot. I have tried modifying my uEnv.txt file to enable different 
overlays but i cant' seem to get config-pin to work for P9_31 and P9_29. It 
responds that config-pin isn't set up for those pins but when I run
config-pin overlay cape-univversala

it seems to load just fine but when I call either:
config-pin-q P9_31
config-pin P9_31 pruout

it says that it is unable to access the "state" of that pin or set the 
"pinmux". What's the right way to enable config-pin on all of the pins so 
that I can set the PRU pins I need to "pruout"?

Zach



On Sunday, November 20, 2016 at 7:51:36 AM UTC-5, Greg wrote:
>
> 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/f243196a-a74b-4f74-ba64-67b34be23f71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to