So, I just noticed that only reading channel 0 do I get the busy error:

# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
cat: /sys/bus/iio/devices/iio:device0/in_voltage0_raw: Device or resource busy
# cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw
109
# cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw
681

Moreover, ch 1 and ch 2 are on P9_39 and P9_40, respectively. But the docs say 
39 is AIN0 and 40 is AIN1.

What's up with that?

The only other difference to my working board is perhaps the U-boot version? 
Unfortunately I can't easily connect a serial cable to it, and don't know how 
else to determine its version number.


> On Oct 26, 2015, at 18:17 , William Hermans <[email protected]> wrote:
> 
> Was just reading this post on E2E 
> https://e2e.ti.com/support/arm/sitara_arm/f/791/t/363283
> 
> The original poster says the patch mentioned towards the bottom works on 
> 3.12, and 3.15, but he's also using an EVM, not a BBB. Requires a rebuild . . 
> .
> 
> On Mon, Oct 26, 2015 at 6:13 PM, Rick Mann <[email protected]> wrote:
> Good idea. Sadly, no one has it open.
> 
> 
> > On Oct 26, 2015, at 18:07 , William Hermans <[email protected]> wrote:
> >
> > Additionally, you *could* apt-get install lsof, then run it to see if that 
> > proves useful.
> >
> > On Mon, Oct 26, 2015 at 6:04 PM, William Hermans <[email protected]> wrote:
> > Both say:
> >
> > # zcat /proc/config.gz |grep CONFIG_TI_AM335X_ADC
> > CONFIG_TI_AM335X_ADC=y
> >
> > OK, so both have it built into the kernel. Hmm dunno what the problem could 
> > be. But the ADC module if busy ( obviously ) for some other reason. You'll 
> > have to figure out why.
> >
> > On Mon, Oct 26, 2015 at 6:02 PM, Rick Mann <[email protected]> wrote:
> >
> > > On Oct 26, 2015, at 18:01 , William Hermans <[email protected]> wrote:
> > >
> > > OK so try this on both boards . ..
> > >
> > > $ zcat /proc/config.gz |grep CONFIG_TI_AM335X_ADC
> > > CONFIG_TI_AM335X_ADC=m
> >
> > Both say:
> >
> > # zcat /proc/config.gz |grep CONFIG_TI_AM335X_ADC
> > CONFIG_TI_AM335X_ADC=y
> >
> > >
> > > I'm using a 4.x kernel by the way . . .
> > >
> > > On Mon, Oct 26, 2015 at 5:37 PM, Rick Mann <[email protected]> wrote:
> > >
> > > > On Oct 26, 2015, at 17:05 , William Hermans <[email protected]> wrote:
> > > >
> > > >> I'm using it the same way I always have. On my other BBB running a 
> > > >> 3.8.13-bone68 kernel and an older Debian, I'm able to read it just 
> > > >> fine with the BB-ADC dtbo loaded. As far as I know, I've never set 
> > > >> anything to be continuous (or one-shot, for that matter).
> > >
> > > > You can check the mode the ADC is in by running:
> > > >
> > > > cat /sys/bus/iio/devices/iio\:device0/mode - Output should be either 
> > > > oneshot or continuous
> > >
> > > Hmm, I don't have this file:
> > >
> > > # ls /sys/bus/iio/devices/iio\:device0/
> > > dev  in_voltage0_raw  in_voltage1_raw  in_voltage2_raw  name  power/  
> > > subsystem@  uevent
> > >
> > > > Which kernel are you running on that board ? Anyway, run lsmod and make 
> > > > sure the ti_am335x_adc module is loaded.  But the ADC dts file I have 
> > > > is as such . . .
> > >
> > > I seem to not have the ti_am335x_adc module, but I also don't have it on 
> > > the one that works
> > >
> > > This one doesn't work:
> > >
> > > # uname -r
> > > 3.8.13-bone72
> > >
> > > # lsmod
> > > Module                  Size  Used by
> > > uio_pruss               4066  0
> > > g_ether                23958  0
> > > libcomposite           15028  1 g_ether
> > > 8192cu                449033  0
> > > omap_rng                4062  0
> > > mt7601Usta            458758  0
> > >
> > > # cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
> > > cat: /sys/bus/iio/devices/iio:device0/in_voltage0_raw: Device or resource 
> > > busy
> > >
> > > This one works:
> > >
> > > # uname -r
> > > 3.8.13-bone68
> > >
> > > # lsmod
> > > Module                  Size  Used by
> > > snd_usb_audio         100405  1
> > > snd_hwdep               4885  1 snd_usb_audio
> > > snd_usbmidi_lib        15375  1 snd_usb_audio
> > > g_multi                50407  0
> > > libcomposite           15028  1 g_multi
> > > uio_pruss               4066  2
> > >
> > > # cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
> > > 3680
> > >
> > > >
> > > > /dts-v1/;
> > > >
> > > > / {
> > > >         compatible = "ti,beaglebone", "ti,beaglebone-black", 
> > > > "ti,beaglebone-green";
> > > >         part-number = "BB-ADC";
> > > >         version = "00A0";
> > > >         exclusive-use = "P9.31", "P9.40", "P9.37", "P9.38", "P9.33", 
> > > > "P9.36", "P9.35", "tscadc";
> > > >
> > > >         fragment@0 {
> > > >                 target = <0xdeadbeef>;
> > > >
> > > >                 __overlay__ {
> > > >                         status = "okay";
> > > >
> > > >                         adc {
> > > >                                 ti,adc-channels = <0x0 0x1 0x2 0x3 0x4 
> > > > 0x5 0x6>;
> > > >                         };
> > > >                 };
> > > >         };
> > > >
> > > >         __fixups__ {
> > > >                 tscadc = "/fragment@0:target:0";
> > > >         };
> > > > };
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Oct 26, 2015 at 4:25 PM, Rick Mann <[email protected]> 
> > > > wrote:
> > > > Thanks, William. Questions below
> > > >
> > > > > On Oct 26, 2015, at 15:56 , William Hermans <[email protected]> wrote:
> > > > >
> > > > > Yes.
> > > > >
> > > > > cat /sys/bus/iio/devices/iio\:device0/in_voltageX_raw is single shot 
> > > > > mode. If you're running in continuous mode you need to read from 
> > > > > /dev/iio:device. So you get this "error" when attempting to use 
> > > > > single shot channel files, when the ADC is operating in continuous 
> > > > > mode.
> > > >
> > > > I'm using it the same way I always have. On my other BBB running a 
> > > > 3.8.13-bone68 kernel and an older Debian, I'm able to read it just fine 
> > > > with the BB-ADC dtbo loaded. As far as I know, I've never set anything 
> > > > to be continuous (or one-shot, for that matter).
> > > >
> > > > How do I tell what mode it's in, and how do I change it?
> > > >
> > > > > If I were you, I'd just use single shot mode, as ADC reads through 
> > > > > iio is dog slow. single-shot is around 5x or maybe slightly more - 
> > > > > faster. iio *could* be faster if you could figure out how the buffer 
> > > > > is structured, and make it very large( to cut down on system 
> > > > > interrupts ). But if you need "fast" ADC, you'd be better off using 
> > > > > either mmap on the ADC registers directly, or use the PRU's.
> > > >
> > > > I don't need ADC faster than 100 Hz (on each of up to three channels). 
> > > > I'd love to move it to the PRU, but right now I'm using a library that 
> > > > downloads firmware to both PRU cores to bitbang LED control. I'll have 
> > > > to modify that to add my own ADC needs, and I'm not ready to do that 
> > > > right now.
> > > >
> > > > I can consider using mmap; is there an example of this?
> > > >
> > > > Thanks!
> > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 3:18 PM, Rick Mann <[email protected]> 
> > > > > wrote:
> > > > > Anyone have any advice on why I can't seem to read the ADC? Thanks!
> > > > >
> > > > > --------------
> > > > >
> > > > > What am I missing here?
> > > > >
> > > > > # uname -r
> > > > > 3.8.13-bone72
> > > > >
> > > > > # pwd
> > > > > /sys/bus/iio/devices/iio:device0
> > > > >
> > > > > # ls
> > > > > dev  in_voltage0_raw  in_voltage1_raw  in_voltage2_raw  name  power/  
> > > > > subsystem@  uevent
> > > > >
> > > > > # cat in_voltage0_raw
> > > > > cat: in_voltage0_raw: Device or resource busy
> > > > >
> > > > > The fragment from my DTBO:
> > > > >
> > > > >         fragment@6 {
> > > > >                 target = <&tscadc>;
> > > > >                 __overlay__ {
> > > > >
> > > > >                         status = "okay";
> > > > >                         adc {
> > > > >                                 ti,adc-channels = <0 1 2>;
> > > > >                         };
> > > > >                 };
> > > > >         };
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --
> > > > > Rick Mann
> > > > > [email protected]
> > >
> > > --
> > > Rick Mann
> > > [email protected]
> > >
> > >
> > >
> >
> >
> > --
> > Rick Mann
> > [email protected]
> >
> >
> >
> >
> 
> 
> --
> Rick Mann
> [email protected]
> 
> 
> 


-- 
Rick Mann
[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