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

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

/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 <rm...@latencyzero.com> wrote:

> Thanks, William. Questions below
>
> > On Oct 26, 2015, at 15:56 , William Hermans <yyrk...@gmail.com> 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 <rm...@latencyzero.com>
> 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
> > rm...@latencyzero.com
> >
> >
> > --
> > 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.
> >
> >
> > --
> > 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.
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> 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.
>

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