Zach, your suggestions worked. I changed fragment@1 to:

  fragment@1 {
    target = <&ocp>;
    __overlay__ {
      test_pru_iomap: pru_iomap {
        compatible = "bone-pinmux-helper";
        pinctrl-names = "default";
        pinctrl-0 = <&mygpio>;
        status = "okay";
      };
    };
recompiled, and then when I loaded the overlay, and later did ADC.setup(), 
I was still able to
control the output pins with the ADC simultaneously working using pru0 
commands

    SET r30.t14
and
    CLR r30.t14

I also added pru0 to:
  exclusive-use =
    "P8.12", "pru0";
as you suggested. Finally, your explanations about which files are being 
affected when overlays are loaded
was very illuminating. I have spent time googling to try and understand 
what is going on with device trees, and
read articles such as http://www.devicetree.org/Device_Tree_Usage, but your 
few lines of explanation have been
more useful than anything I have found to date. If there is an article or 
site you would recommend to read, I would
be very interested. Also, if you happen to know where the source code for 
Adafruit_BBIO.ADC can be found,
I would be interested in trying to follow it through. Once again, thank you 
for your
help; with my limited knowledge re device trees, this is not something I 
would have
been able to solve on my own.
Bit Pusher

On Friday, December 6, 2013 2:50:39 PM UTC-5, Zachary Thorson wrote:
>
> Odd, dmesg has no errors, but there is definitely a conflict between the 
> two.
>
> Someone can correct me if I am wrong as this is a guess based on the 
> behavior of the system (I'll have to look it up later) but loading a device 
> tree will dynamically map a bunch of hardware register to the file system 
> in certain locations based on the fragment used. Since the dts file you 
> posted specified &ocp as the target, it placed it into 
> /sys/devices/ocp.*/[Name]. 
>
> In this case [Name] is the name that you specified is the one inside of 
> that __overlay__ keyword.  That would be "helper".
>
> I know for sure that the Adafruit Library looks for 
> /sys/devices/ocp.*/helper.* to read from and control the ADC registers, so 
> if your overlay is overwriting those values, it will lead to problems.  I 
> am not sure why it would affect your pru code without seeing how you are 
> trying to access the IOs.
>
> Anyway, try changing the line:
> test_helper: helper {
>
>
> to something more unique such as:
> pru_iomap {
>
>
> Recompile, then try loading as before.
>
> Though if you are not using the ocp mapping to write to the IO, you could 
> probably drop the section.  Some of the sample dts files in 
> /lib/firmware/BB-BONE-PRU-01.dts do not even map the ocp.
>
> Also, you may want to add "pru0" to your exclusive use list so another 
> cape doesn't try to use it at the same time.
>
> After those changes:
>
>  
> 0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
> root@beaglebone:~# echo BB-BONE-PRU > $SLOTS
> root@beaglebone:~# cat $SLOTS
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU
> root@beaglebone:~# python
> Python 2.7.3 (default, May 29 2013, 21:25:00)
> [GCC 4.7.3 20130205 (prerelease)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import Adafruit_BBIO.ADC as ADC
> >>> ADC.setup()
> >>> ADC.read("P9_40")
> 0.86722224950790405
>
>
>
> Let me know how it goes,
> Zachary Thorson
>
>
>
>
>
>
> On Wednesday, December 4, 2013 8:13:14 PM UTC-6, Bit Pusher wrote:
>>
>> Zach, that would be very good of you; I got if from searching on the net 
>> and it is barely changed (if at all) from what I found (but I didn't record 
>> who I copied it from so I apologize for not giving credit). The *.dts is 
>> below. I might mention that if I load my overlay only, then using >cat 
>> $PINS, I can see the expected pin change to 6. If I setup the AD first in 
>> python, I do not see any changes in the $PINS, and if I then try to load my 
>> overlay and check the pins, they are still the same as just after boot.
>> Bit Pusher
>>
>> /lib/firmware\> cat BB-BONE-PRU-00A0.dts
>> /*
>> * pru dts file BB-BONE-PRU-00A0.dts
>> */
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>>   compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>>   /* identification */
>>   part-number = "BB-BONE-PRU";
>>   version = "00A0";
>>
>>   exclusive-use =
>>     "P8.12";
>>
>>   fragment@0 {
>>     target = <&am33xx_pinmux>;
>>     __overlay__ {
>>       mygpio: pinmux_mygpio{
>>         pinctrl-single,pins = <
>>           0x30 0x06
>>           >;
>>       };
>>     };
>>   };
>>
>>   fragment@1 {
>>     target = <&ocp>;
>>     __overlay__ {
>>       test_helper: helper {
>>         compatible = "bone-pinmux-helper";
>>         pinctrl-names = "default";
>>         pinctrl-0 = <&mygpio>;
>>         status = "okay";
>>       };
>>     };
>>   };
>>
>>   fragment@2{
>>   target = <&pruss>;
>>     __overlay__ {
>>       status = "okay";
>>     };
>>   };
>> };
>>
>>
>> On Wednesday, December 4, 2013 8:17:47 AM UTC-5, Zachary Thorson wrote:
>>>
>>> Could you post or send me your overlay?  I can load it on one of my BBBs 
>>> and take a look for you. 
>>>
>>> Zach 
>>>
>>> On Tuesday, December 3, 2013 8:39:35 PM UTC-6, Bit Pusher wrote: 
>>> > If I load my device tree overlay to use the high-speed GPIO pins 
>>> first, and then try to read the ADC using Adafruit_BBIO, it kicks me out of 
>>> python: 
>>> > 
>>> > 
>>> > 
>>> > ~/pru\> sudo python 
>>> > Python 2.7.5+ (default, Sep 19 2013, 14:17:30)  
>>> > [GCC 4.8.1] on linux2 
>>> > Type "help", "copyright", "credits" or "license" for more information. 
>>> > >>> import Adafruit_BBIO.ADC as ADC 
>>> > >>> ADC.setup() 
>>> > >>> ADC.read("P9_40") 
>>> > ~/pru\>  
>>> > 
>>> > 
>>> > notice no value returned and no python prompt. I suspect this 
>>> indicates a problem. 
>>> > I then rebooted (reset switch), waited until the network started 
>>> working again (it takes 5 minutes each time for the network to work, 
>>> something needs to timeout) 
>>> > and then did the same, but this time did not load the device overlay 
>>> to change one pru gpio to a high-speed output and got as expected 
>>> > 
>>> > 
>>> > 
>>> > ~/pru\> sudo python 
>>> > Python 2.7.5+ (default, Sep 19 2013, 14:17:30)  
>>> > [GCC 4.8.1] on linux2 
>>> > Type "help", "copyright", "credits" or "license" for more information. 
>>> > >>> import Adafruit_BBIO.ADC as ADC 
>>> > >>> ADC.setup() 
>>> > >>> ADC.read("P9_40") 
>>> > 0.8072222471237183 
>>> > >>>  
>>> > 
>>> > 
>>> > I should mention that when I load both overlays, with my overlay 
>>> first, >cat $SLOTS shows them both there, just the ADC overlay load does 
>>> not 
>>> > work correctly. If I run the ADC.setup() first, and then run 
>>> > ~/pru\>>sudo sh -c "echo BB-BONE-PRU > $SLOTS" to load my overlay, 
>>> then 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > /lib/firmware\> cat $SLOTS 
>>> >  0: 54:PF---  
>>> >  1: 55:PF---  
>>> >  2: 56:PF---  
>>> >  3: 57:PF---  
>>> >  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 
>>> >  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 
>>> >  7: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio 
>>> >  9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU 
>>> > /lib/firmware\>  
>>> > 
>>> > 
>>> > and both overlays are  shown but the high 
>>> > speed pin does not work. 
>>> > Loading just my overlay only, works as expected as far as I can tell 
>>> (i.e. the led turns on and off). 
>>> > I'm guessing things are not quite as expected. 
>>> > Also, could someone point me to the file in kernel source that loads 
>>> overlays? 
>>> > Thanks. 
>>> > Bit Pusher 
>>> > 
>>> > 
>>> > On Tuesday, December 3, 2013 12:16:34 PM UTC-5, Zachary Thorson wrote: 
>>> > Correct me if I am wrong, but it appears that you simply want to use 
>>> ADC and PRU pins whose pins DO NOT physically overlap on the board?  The 
>>> cape-bone-iio device tree only grabs the ADC0-ADC7 pins plus analog power 
>>> and ground, so it should not interfere with the PRU pins. 
>>> > 
>>> > 
>>> > What issue are you getting when you try to load the PRU overlay after 
>>> loading the ADC overlay? 
>>> > 
>>> > 
>>> > 
>>> > Note:  The adafruit library has a cleanup function in code, but it is 
>>> commented out due to the lockup on load that you are describing. 
>>> > 
>>> > Zach 
>>>
>>>

-- 
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/groups/opt_out.

Reply via email to