> On Mar 10, 2016, at 12:51 AM, William Hermans <[email protected]> wrote: > > Question: > > 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? OK, so if you look at the /driver/iio/adc/ti_am335x_adc.c file, reading in_voltage0_raw is done by the tiadc_read_raw() function. The /dev/iio:device0 is a regular device driver interface, just like /dev/tty0. You can open, poll, read, etc. If you want to know how to interface to this driver, look at tools/iio/generic_buffer.c. So generally, you open /dev/iio:device0, then you poll this interface, which blocks, waiting for the buffer to exceed the watermark (prevents read from reading just a few values) and when poll returns, you read multiple values into a buffer in user space. > > My answer: > in_voltage0_raw == one shot mode. > > /dev/iio:device0 == continuous mode. > > continuous mode is only really useful if you need more than 3-4 thousand > samples a second. Otherwise one shot mode will possibly work just fine. It > really how much you're trying to do all at once. > > > John's answer: > 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 > > Total bullshit answer John. Which is getting to be common place from you. > Sure iio:deviceX is a buffer, for continuous mode operation but > in_voltageX_raw is not an fscking attribute. It's a single value buffer. > What's more, your timing is impeccable. Bullshit answer right after I've > already explained it. You tell me what I'm supposed to think about that. There is no such thing as a single value buffer. Look up sysfs in the kernel docs, it is restricted to a single value (boolean, int, etc) per sysfs interface. Hence the reason why debugfs was developed, which can exchange complex data structures. > > Additionally, you go about spouting complete FUD saying that one shot mode > only gives the same value over, and over again. It's very obvious you have no > personal hands on knowledge here. in_voltageX_raw is refreshed every time the > pseudo file is opened. That means, if you open the file, you *must* close it > , then reopen in order for the value to refresh. I'll also give you another > clue. In continuous mode, you have to read above 200Ksps from a single ADC > channel before you start getting redundant data. So what makes you think that > a very slow operation such as opening a file before reading a value is going > to make the ADC's maximum samples / second any slower ? Bonus hint: it wont. You don’t have to open the file for each read. You can open and then read and read again. That is what your example does. Looking at the code, it looks like you cannot read the same sample over and over again, because it waits for a new sample to complete before returning. This is probably why sysfs is slow because it has to wait for a complete scan cycle of all channels before returning a single value. > > Anyway, I'm starting to feel like a 5 year old fighting over something > incredibly stupid. So I'm done with this conversation. However, again. Stop > spreading FUD about stuff you obviously know nothing about, and I'll stop > putting it back into your face. It surely seems like you know what the iio > buffer is and does, and you know what some obscure device tree values for > the ADC are ( I never even knew of those ). But you definitely have no clue > about one shot mode. > You need to relax, take a breath. If you read the code in the driver, you will see that I am correct.
Regards, John > > > On Thu, Mar 10, 2016 at 12:33 AM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > >> On Mar 9, 2016, at 2:17 PM, William Hermans <[email protected] >> <mailto:[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 > <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.
