From: Michael Hennerich <michael.hennerich@analog.com>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"device-drivers-devel@blackfin.uclinux.org"
<device-drivers-devel@blackfin.uclinux.org>,
Drivers <Drivers@analog.com>
Subject: Re: [PATCH] IIO: ADC: New driver for AD7792/AD7793 3 Channel SPI ADC
Date: Fri, 27 May 2011 13:30:57 +0200 [thread overview]
Message-ID: <4DDF8B71.9000200@analog.com> (raw)
In-Reply-To: <4DDF87F0.1060506@cam.ac.uk>
On 05/27/2011 01:16 PM, Jonathan Cameron wrote:
> On 05/27/11 11:55, Michael Hennerich wrote:
>> On 05/27/2011 12:53 PM, Jonathan Cameron wrote:
>>> On 05/27/11 11:23, Michael Hennerich wrote:
>>>> On 05/27/2011 11:44 AM, Jonathan Cameron wrote:
>>>>> ...
>>>>>> Hi Jonathan,
>>>>>>
>>>>>>
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> ls
>>>>>> device0:buffer0 power
>>>>>> in-in_scale range
>>>>>> in0-in0_raw range_available
>>>>>> in1-in1_raw sampling_frequency
>>>>>> in2-in2_raw sampling_frequency_available
>>>>>> in3_raw subsystem
>>>>>> in4_supply_raw temp0_raw
>>>>>> in4_supply_scale temp_scale
>>>>>> in_scale trigger
>>>>>> name uevent
>>>>>>
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_s=
cale
>>>>>> 0.000140
>>>>>>
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat rang=
e_available
>>>>>> 2500 1250 625 312 156 78 39 19
>>>>>>
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 312=
> range
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_s=
cale
>>>>>> 0.000010
>>>>>>
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> echo 78>=
range
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0> cat in_s=
cale
>>>>>> 0.000000
>>>>>> root:/sys/devices/platform/bfin-spi.0/spi0.18/device0>
>>>>>>
>>>>>> with these 24-bit converters and input AMPs we are already exhaust=
ed
>>>>>> the number of available digits we have for scale.
>>>>> Time for a new return type and extra logic in the core.
>>>>> IIO_VAL_INT_PLUS_NANO
>>>>>
>>>>> should still fit in a 32 bit long. Perhaps it's better to make a =
bigger jump - or
>>>>> this will just bite us again sometime soon.
>>>>>
>>>>> After nano we will have to start having padding zeros which is goin=
g to be a little
>>>>> strange - or I guess we don't have to keep val as being int...
>>>>>
>>>>> IIO_VAL_MICRO_PLUS_PICO maybe? The maximum option of IIO_VAL_NANO_=
PLUS_ATTO seems a little
>>>>> 'odd'.
>>>>>
>>>>> The more complex question is going to be writing values that are th=
is small. I think we will
>>>>> have to add another callback into the drivers where they can query =
what format a value should
>>>>> be in so the core can provide it. Make this optional so it doesn't=
effect the majority
>>>>> of drivers where int + micro does the job.
>>>>>
>>>> IIO_VAL_INT_PLUS_NANO should do the job for now.
>>>>
>>>>>> What shall we do?
>>>>>>
>>>>>> Also how would you name AIN1(-) - AIN1(-)?
>>>>>>
>>>>>> #define AD7793_CH_AIN1P_AIN1M 0 /* AIN1(+) - AIN1(-) */
>>>>>> #define AD7793_CH_AIN2P_AIN2M 1 /* AIN2(+) - AIN2(-) */
>>>>>> #define AD7793_CH_AIN3P_AIN3M 2 /* AIN3(+) - AIN3(-) */
>>>>>> #define AD7793_CH_AIN1M_AIN1M 3 /* AIN1(-) - AIN1(-) */
>>>>>>
>>>>>> in0-in0_zerooffset_raw ?
>>>>> Hmm.. That is awkward. Given only the channel numbers exist in eve=
nt codes
>>>>> it will also possibly cause us issues at some later date.
>>>>> How about having in0-in0_raw then in0-in0_offset + in0-in0_offset_a=
vailable.
>>>>> (actually this would be shared I guess so in-in_offset_available).
>>>>> A little clunky, but does fit better within the api. Is there a re=
al use case
>>>>> for buffering where one grabs both offsets in the same scan?
>>>> As far as I understand things - We do zero and full scale calibratio=
n,
>>>> The results read from the other channels should have the offset elim=
inated.
>>>> I agree the offset read from AIN1(-) - AIN1(-) should be the same f=
or all channels.
>>>> So in-in_offset sounds good to me - why _available?
>>> Because there are two options possible. One when we are doing signed=
output
>>> and one for differential but with only positive values possible.
>> Sorry I can't follow here. These 3 differential channels pairs always =
deliver signed values.
>> Why would a differential channel only deliver positive values?
>> If the voltage on AINx(+) is lower then the voltage on AINx(-) the res=
ult is negative.
> So what is AIN1(-) - AIN1(-) ?
>
> I thought that was unipolar differential.
No - In this mode the AIN1(=E2=88=92) input is internally shorted to itse=
lf.
This can be used as a test method to evaluate the noise performance of th=
e
parts with no external noise sources. In this mode, the AIN1(=E2=88=92) i=
nput should
be connected to an external voltage
within the allowable common-mode range for the part.
As you see this is only for test and evaluation purposes...
--=20
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
next prev parent reply other threads:[~2011-05-27 11:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 15:02 [PATCH] IIO: ADC: New driver for AD7792/AD7793 3 Channel SPI ADC michael.hennerich
2011-05-26 10:18 ` Jonathan Cameron
2011-05-26 14:29 ` Michael Hennerich
2011-05-26 14:58 ` Jonathan Cameron
2011-05-27 8:09 ` Michael Hennerich
2011-05-27 9:09 ` [Device-drivers-devel] " Michael Hennerich
2011-05-27 9:49 ` Jonathan Cameron
2011-05-27 9:44 ` Jonathan Cameron
2011-05-27 10:23 ` Michael Hennerich
2011-05-27 10:53 ` Jonathan Cameron
2011-05-27 10:55 ` Michael Hennerich
2011-05-27 11:16 ` Jonathan Cameron
2011-05-27 11:30 ` Michael Hennerich [this message]
2011-05-27 12:23 ` Jonathan Cameron
2011-05-27 14:46 ` Hennerich, Michael
2011-05-31 7:23 ` Jonathan Cameron
-- strict thread matches above, loose matches on Subject: below --
2011-06-07 15:45 michael.hennerich
2011-06-08 14:12 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDF8B71.9000200@analog.com \
--to=michael.hennerich@analog.com \
--cc=Drivers@analog.com \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox