> On Mar 9, 2016, at 2:17 PM, William Hermans <[email protected]> wrote: > > 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 > > <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. You have this amazing ability to read peoples minds; at least you think you do. You should reframe from guessing what people know or don’t know, but you do make me smile when I read what you say. If you read the section I referenced in the TRM, it is explained very clearly. Why would I cut and past that is already explained. The ADC uses a scan cycle and in that cycle, it has an open delay, a sample delay and then it oversamples a predefined number of time. The oversampling helps increase the bits of resolution:
https://www.silabs.com/Support%20Documents/TechnicalDocs/an118.pdf <https://www.silabs.com/Support%20Documents/TechnicalDocs/an118.pdf> The open delay and sample delay are used accommodate the sample&hold error that occurs when the source impedance is too high. What isn’t in the TRM, but is understood by EE who design ADC front ends, an analog buffer like an opamp or a instrumentation amplifier or a chopper amplifier is used to eliminate offset errors and present a low impedance to the ADC sample and hold. If you don’t do this, you will see bleedover from one channel to another. Now this probably doesn’t make any sense to you because this is all to EE specific, but you did ask. Regards, John > > > > On Wed, Mar 9, 2016 at 11:24 AM, John Syne <[email protected] > <mailto:[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] >> <mailto:[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] >> <mailto:[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 >> <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] >> <mailto:[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] >> <mailto:[email protected]>> wrote: >> /* >> * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ >> <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] <mailto:[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 >>> >>> <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 <ao...@ <>smith.edu >>>> <http://smith.edu/>> 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 >>>> <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...@ <>googlegroups.com <http://googlegroups.com/>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
