I found a problem that P9_31 conflicts with the HDMI Overlay so I will have 
to figure out if I try to eliminate it because it is not going to be used 
or if I can move the output to the pru1.


On Wednesday, October 8, 2014 11:59:37 PM UTC-7, Ray Madigan wrote:
>
> I also noticed in the exclusive-use list in the universal overlays you 
> have "pru0", "pru1", "pruss" with no other reference.  I don't have them in 
> mine?  What are they for?
>
> On Wednesday, October 8, 2014 11:47:04 PM UTC-7, Ray Madigan wrote:
>>
>> Taking your suggestion I went out to /lib/firmware and found several dts 
>> files that used pins like I want to use them.  The number of pins in the 
>> list I want are 1 to all Plus some.  The one that used all the pins I want 
>> to use include lots of stuff in the ocp fragment.  Is there a way to use a 
>> modified version of this one.  It is
>>
>> BB-BONE-PRU-04-00A0.dts
>>
>> On Wednesday, October 8, 2014 8:56:47 PM UTC-7, Ray Madigan wrote:
>>>
>>> I can't thank you enough for your help.  Every response is at least 
>>> another two day learning activity.  I just wish I didn't have to work to 
>>> pay the bills.
>>>
>>> I went back to see what I did and it turns out I misspelled the name of 
>>> the dtbo file that I was using so there is no wonder it didn't work.
>>> Now I get an error that the file exists when I:
>>>
>>> echo pru_enable > /sys/devices/bone_capemgr.8/slots
>>>
>>> echo: write error: File exists
>>> prussdrv_open open failed
>>>
>>> so I guess I have more to learn :(
>>>
>>> What I am really trying to do is learn how to work with this device.  
>>> This activity is to learn to write to a set of 9 or 10 pins, 8 data and 
>>> one enable or 2 handshake.
>>>
>>> My next step is to read fro a set of 9 or 10 pins, 8 for data and one 
>>> for write enable or 2 for a handshake.
>>>
>>> So:
>>>
>>> If I add your desired pinmux settings to a custom PRU overlay based off 
>>> of one of the BB-BONE-PRU overlays provided with the standard kernel.  What 
>>> would be the limitations?  
>>>
>>> I figure I could work out the problems at a later time.  after I see an 
>>> led light up:)
>>>
>>>
>>> On Wednesday, October 8, 2014 12:21:37 PM UTC-7, Charles Steinkuehler 
>>> wrote:
>>>>
>>>> On 10/8/2014 11:43 AM, Ray Madigan wrote: 
>>>> > 
>>>> > All I need to do is comment out the pins in exclusive-use section 
>>>> that I 
>>>> > don't want to use and comment out all of the entries for those pins 
>>>> in the 
>>>> > fragment.  Then comment out the sections for the modes I don't want 
>>>> for the 
>>>> > pins I do want? 
>>>>
>>>> If you use a "stripped down" version of the universal cape overlay, 
>>>> you'll still have the pinmux helper in control of the pin multiplexing. 
>>>>
>>>> That means you'll need to either setup the proper pin choice using 
>>>> sysfs 
>>>> after loading the overlay or make the desired PRU pinmux mode the 
>>>> default (or both). 
>>>>
>>>> Alternately, you could add your desired pinmux settings to a custom PRU 
>>>> overlay based off of one of the BB-BONE-PRU overlays provided with the 
>>>> standard kernel.  This would prevent any changes to the pinmux setting 
>>>> after loading the overlay, which might be good or bad, depending on 
>>>> exactly what you're attempting to do. 
>>>>
>>>> -- 
>>>> Charles Steinkuehler 
>>>> [email protected] 
>>>>
>>>

-- 
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