> > *William,* > > *Rather you should not comment on my replies. If I say white, you say > black even when you know you are wrong.*
That's funny I was thinking the same, except your answer is wrong. *If you look at the DT overlay the OP referenced, the additional entries > don’t exist and that is why I posted an updated DT overlay. Reading > in_voltagex_raw like your beaglebone-black-adc example was never meant for > high speed capture. In fact you are just reading the same sample over and > over again. * > http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#One-shot_Mode No one said anything about high speed capture. But have you actually ever used one shot mode ? It is *NOT* reading the same sample over and over again. But you do have to open / close the file every time you do want a new reading. That's how it's supposed to work. *Reading the buffer via /dev/iio:device0 is how you are supposed to read > IIO ADC samples.* > No one ask that question. *If you want to understand oversampling, open delay, sample delay, then > read the AM3358 TRM. * > So in other words, you do not know. But again, this is not a question i asked for myself. It's the question I interpreted Audry asking to which you completely blew off. On Wed, Mar 9, 2016 at 11:24 AM, John Syne <[email protected]> wrote: > Look at AM3358 TRM Figure 12-3 on Page 1497 > > Regards, > John > > > > > On Mar 9, 2016, at 1:04 AM, William Hermans <[email protected]> wrote: > > 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. > > > -- > 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.
