Yes, and you can switch if you want with alternate modes using the pinmux 
subsystem

On Monday, January 12, 2015 at 1:48:04 PM UTC-8, AndyS wrote:
>
> I think I have grasped it now.  You can set individual pins to different 
> mux modes?
>
>
>
> On Monday, January 12, 2015 at 7:11:37 PM UTC, Neabex wrote:
>>
>> Andy, there are two kinds of PRU GPIO writes,  the direct ones, in which 
>> you write to the R30 register, and ones where you have to access the gpio 
>> subsystem, you only need to mux it to the PRU if you're doing the direct 
>> method.
>>
>>
>> On Monday, January 12, 2015 at 9:07:17 AM UTC-8, AndyS wrote:
>>>
>>> Thank you for your quick replies.  I will work through the examples this 
>>> evening.
>>>
>>> Ok.  I think I might be getting a little confused of something called 
>>> mux mode5 which looks like it is specific to an example I have been 
>>> following on GPIO from Derek Molloy.
>>>
>>> Can I create my own overlays to configure the mux which uses both GPIO 
>>> and PRU IO? ( and the ADC if required)
>>>
>>>
>>>
>>> On Monday, January 12, 2015 at 4:57:19 PM UTC, Charles Steinkuehler 
>>> wrote:
>>>>
>>>> On 1/12/2015 5:11 AM, AndyS wrote: 
>>>> > Hello, 
>>>> > 
>>>> > I have an application which requires use of the PRU for some fast IO. 
>>>>  I 
>>>> > need to use more IO than the PRU can handle, but some of the other IO 
>>>> only 
>>>> > needs to operate in slow time. 
>>>> > 
>>>> > Can I configure the BBB to use both PRU IO and Linux controlled GPIO. 
>>>>
>>>> Yes.  The PRU writes to GPIO pins are not particularly slow unless you 
>>>> saturate the interconnect, but the writes are posted and happen a while 
>>>> after the PRU executes them (apx. 100 nS later).  Unless you need 
>>>> critical timings between the direct PRU outputs and the GPIO pins, this 
>>>> shouldn't be a problem. 
>>>>
>>>> Reads from GPIO pins are another matter.  Since it is not possible to 
>>>> post the reads, and the PRU (by design) doesn't execute instructions 
>>>> out 
>>>> of order or perform speculative execution, the PRU core stalls after 
>>>> issuing a read GPIO request until the data is returned from the 
>>>> interconnect fabric (apx. 165 nS). 
>>>>
>>>> I have timing details in the comments of my PRU code for Machinekit: 
>>>>
>>>>
>>>> https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L135-L163
>>>>  
>>>>
>>>> -- 
>>>> Charles Steinkuehler 
>>>> cha...@steinkuehler.net 
>>>>
>>>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to