And, I'm wrong. I rebooted, and now none of them reads successfully. I fucking hate this shit.
> On Oct 27, 2015, at 02:07 , Rick Mann <[email protected]> wrote: > > 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. -- 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.
