John, also Audry asked what the values of that device tree fragment mean, not what the code was. As in Audry wants and explanation of the values:
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>; ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>; ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>; As far as I can tell. Quite honestly I could use that explanation myself. But step avg can be a value 0-16 if memory serves from reading the TRM, I'm just not clear exactly on what step avg actually does. . . . the explanation in the TRM is very jumbled / confusing. On Wed, Mar 9, 2016 at 1:58 AM, William Hermans <[email protected]> wrote: > Now if you want to convey more information that is actually *useful* to > anyone reading this post. You can say that both voltageX_raw, and > iio:deviceX are buffers. > > With voltageX_raw being a single value buffer that gets updated only once > every open() call on it's file descriptor. > > Where iio:deviceX is a buffer, defined in size by the value set in > /sys/bus/iio/devices/iio\:device0/buffer/length > > More *useful* information can be found here: > http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide. Then > if you want even more information still, googling "iio" will produce a lot > of information. Much of it not so useful. At least for our use case, the > Beaglebone. > > On Wed, Mar 9, 2016 at 1:47 AM, William Hermans <[email protected]> wrote: > >> what the hell does what you've said there even mean John ? voltagex_raw >> is one shot mode, iio:deviceX is continuous mode. >> >> What you said above only serves to confuse the situation. >> >> On Wed, Mar 9, 2016 at 1:32 AM, John Syne <[email protected]> wrote: >> >>> /* >>> * Copyright (C) 2012 Texas Instruments Incorporated - >>> http://www.ti.com/ >>> * >>> * This program is free software; you can redistribute it and/or modify >>> * it under the terms of the GNU General Public License version 2 as >>> * published by the Free Software Foundation. >>> */ >>> /dts-v1/; >>> /plugin/; >>> >>> / { >>> compatible = "ti,beaglebone", "ti,beaglebone-black", >>> "ti,beaglebone-green"; >>> >>> /* identification */ >>> part-number = "BB-ADC"; >>> version = "00A0"; >>> >>> /* state the resources this cape uses */ >>> exclusive-use = >>> /* the pin header uses */ >>> "P9.31", /* AIN0 */ >>> "P9.40", /* AIN1 */ >>> "P9.37", /* AIN2 */ >>> "P9.38", /* AIN3 */ >>> "P9.33", /* AIN4 */ >>> "P9.36", /* AIN5 */ >>> "P9.35", /* AIN6 */ >>> /* the hardware ip uses */ >>> "tscadc"; >>> >>> fragment@0 { >>> target = <&tscadc>; >>> __overlay__ { >>> >>> status = "okay"; >>> adc { >>> ti,adc-channels = <0 1 2 3 4 5 6>; >>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>; >>> ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>; >>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>; >>> }; >>> }; >>> }; >>> }; >>> >>> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading >>> and attribute of the IIO driver. Reading from /dev/iio:device0 is reading >>> from the same IIO driver, but in this case you are reading from the buffer >>> which stores samples defined in the DT overlay above. >>> >>> Regards, >>> John >>> >>> >>> >>> >>> On Mar 8, 2016, at 9:51 PM, Audrey <[email protected]> wrote: >>> >>> Thanks for the reply John. Could you perhaps explain how to modify the >>> oversample, open delay time, and sample time in greater detail in the >>> BB-ADC overlay? I do not see these variables in the dto in github ( >>> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts). >>> Also, what value can/should I change them to? >>> >>> So just to clarify, reading from >>> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using >>> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also >>> another conceptual question, can you explain what exactly is >>> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact >>> with it by using cat. So is it just like a text file or something? >>> >>> Thanks. >>> >>> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote: >>>> >>>> That is because you are doing this wrong. Reading attributes via sysfs >>>> is slow and not meant for this purpose. With IIO, you enable a scan element >>>> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 > >>>> buffer/enable)and then you read the values from /dev/iio:device0. In the >>>> BB-ADC overlay, you can modify the scan update time by modifying the >>>> Oversample (default is 16x), Open Delay time (default is 0x98) and sample >>>> time (default is 1). Now the IIO ADC driver captures samples using >>>> interrupts which isn’t ideal, but it will capture samples at a much higher >>>> rate than can be read from sysfs. If you want to capture at full speed, the >>>> driver needs to be updated to use DMA. >>>> >>>> Regards, >>>> John >>>> >>>> >>>> >>>> >>>> On Mar 6, 2016, at 12:19 AM, Audrey <[email protected]> wrote: >>>> >>>> Where can I find it (and set it)? >>>> >>>> I'm right now trying to collect voltage readings using beaglebone's >>>> internal adc using a bash script and a while loop. Right now the data >>>> collection is clocking at around 33 microseconds, but I know that the >>>> internal adc should be able to collect data as fast as 5 microseconds. What >>>> should I do to make that happen? Is the problem with making while loops >>>> move faster, or is it about setting the adc configurations? >>>> >>>> This is my bash script: >>>> >>>> #!/bin/bash >>>> >>>> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots >>>> >>>> t0=$(date +%s%6N) >>>> >>>> while true; do >>>> t1=$(date +%s%6N) >>>> rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw) >>>> voltage=$(bc -l <<< $rawVal/4095*1.8) >>>> time=$(expr $t1 - $t0) >>>> echo $time $voltage >>>> done >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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.
