> > *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.* >
Anything can do 100Hz, as long as there is not much using the ARM processor core. It won't be deterministic though if you're in userspace. * I can consider using mmap; is there an example of this?* https://github.com/ehayon/BeagleBone-GPIO Was written with the white in mind, but works fine. Personally, I ripped out all that PIN crap, and everything that was not somehow related to the ADCs. Then wrote a couple custom functions. I wont share my own code though, because I have no way of testing it for validity yet. On Mon, Oct 26, 2015 at 5:05 PM, 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 > > 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 <[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] >> > >> > >> > -- >> > 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. >> > >> > >> > -- >> > 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. >> >> >> -- >> 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. >> > > -- 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.
