ADC setting for differential and single-ended channels

ADC setting for differential and single-ended channels

[Otavio Salvador]

Hello,

Mario and I are working at TI ADS124x driver and this chip can be used
in two ways:

In case of ADS1247:

 - 2 differential channels
 - 3 single-ended channels

In the first case it take two inputs and the chip returns the
difference between them; in the second case it does the same but you
must choose one channel to be the negative reference for all the other
inputs. This is how we understood the datasheet however the
single-ended use is quite confusing on it so we might be wrong.

So we'd like to know the best way to handle those cases in the driver.
One alternative we discussed is to use two attributes in the dts as:

 ...
 #channels = <2>;
 channels = <0 3
                    1 2>;

So it'd take two channels. One composed by input 0 and input 3 and
another composed by input 1 and input 2.

On the another case, we'd use:

  ...
  #channels = <3>
  channels = <0 3
                     1 3
                     2 3>;

So it'd take three channels and all them comparing to input 3.

Are we in the right route? Any hints how to better solve this?

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: ADC setting for differential and single-ended channels

[Jonathan Cameron]

Otavio Salvador <otavio@ossystems.com.br> wrote:
>Hello,
>
>Mario and I are working at TI ADS124x driver and this chip can be used
>in two ways:
>
>In case of ADS1247:
>
> - 2 differential channels
> - 3 single-ended channels
>
>In the first case it take two inputs and the chip returns the
>difference between them; in the second case it does the same but you
>must choose one channel to be the negative reference for all the other
>inputs. This is how we understood the datasheet however the
>single-ended use is quite confusing on it so we might be wrong.
>
>So we'd like to know the best way to handle those cases in the driver.
>One alternative we discussed is to use two attributes in the dts as:
>
> ...
> #channels = <2>;
> channels = <0 3
>                    1 2>;
>
>So it'd take two channels. One composed by input 0 and input 3 and
>another composed by input 1 and input 2.
>
>On the another case, we'd use:
>
>  ...
>  #channels = <3>
>  channels = <0 3
>                     1 3
>                     2 3>;
>
>So it'd take three channels and all them comparing to input 3.
>
>Are we in the right route? Any hints how to better solve this?

Another option is to leave it entirely up to user space.  See max1363 driver where both single ended and differential channels are supported at the same time with care taken in buffered mode.

Not sure if that works for your case?
>
>Regards,
>
>--
>Otavio Salvador                             O.S. Systems
>http://www.ossystems.com.br        http://projetos.ossystems.com.br
>Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: ADC setting for differential and single-ended channels

[Otavio Salvador]

On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>
>
> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>Hello,
>>
>>Mario and I are working at TI ADS124x driver and this chip can be used
>>in two ways:
>>
>>In case of ADS1247:
>>
>> - 2 differential channels
>> - 3 single-ended channels
>>
>>In the first case it take two inputs and the chip returns the
>>difference between them; in the second case it does the same but you
>>must choose one channel to be the negative reference for all the other
>>inputs. This is how we understood the datasheet however the
>>single-ended use is quite confusing on it so we might be wrong.
>>
>>So we'd like to know the best way to handle those cases in the driver.
>>One alternative we discussed is to use two attributes in the dts as:
>>
>> ...
>> #channels = <2>;
>> channels = <0 3
>>                    1 2>;
>>
>>So it'd take two channels. One composed by input 0 and input 3 and
>>another composed by input 1 and input 2.
>>
>>On the another case, we'd use:
>>
>>  ...
>>  #channels = <3>
>>  channels = <0 3
>>                     1 3
>>                     2 3>;
>>
>>So it'd take three channels and all them comparing to input 3.
>>
>>Are we in the right route? Any hints how to better solve this?
>
> Another option is to leave it entirely up to user space.  See max1363 driver where both single ended and differential channels are supported at the same time with care taken in buffered mode.
>
> Not sure if that works for your case?

I think it is nicer to have it set in the dt; we need the dt anyway so
it seems logical to get it setting  the right channel.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: ADC setting for differential and single-ended channels

[Marek Vasut]

Dear Otavio Salvador,

> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> > Otavio Salvador <otavio@ossystems.com.br> wrote:
> >>Hello,
> >>
> >>Mario and I are working at TI ADS124x driver and this chip can be used
> >>in two ways:
> >>
> >>In case of ADS1247:
> >> - 2 differential channels
> >> - 3 single-ended channels
> >>
> >>In the first case it take two inputs and the chip returns the
> >>difference between them; in the second case it does the same but you
> >>must choose one channel to be the negative reference for all the other
> >>inputs. This is how we understood the datasheet however the
> >>single-ended use is quite confusing on it so we might be wrong.
> >>
> >>So we'd like to know the best way to handle those cases in the driver.
> >>
> >>One alternative we discussed is to use two attributes in the dts as:
> >> ...
> >> #channels = <2>;
> >> channels = <0 3
> >> 
> >>                    1 2>;
> >>
> >>So it'd take two channels. One composed by input 0 and input 3 and
> >>another composed by input 1 and input 2.
> >>
> >>On the another case, we'd use:
> >>  ...
> >>  #channels = <3>
> >>  channels = <0 3
> >>  
> >>                     1 3
> >>                     2 3>;
> >>
> >>So it'd take three channels and all them comparing to input 3.
> >>
> >>Are we in the right route? Any hints how to better solve this?
> >>
> > Another option is to leave it entirely up to user space.  See max1363
> > driver where both single ended and differential channels are supported
> > at the same time with care taken in buffered mode.
> > 
> > Not sure if that works for your case?
> 
> I think it is nicer to have it set in the dt; we need the dt anyway so
> it seems logical to get it setting  the right channel.

Can you please elaborate why is it logical?

I took a brief look over the datasheet [1], here are the facts I see (correct me 
if I'm wrong). I first looked at Figure 51. :

- ADS1246 has two input channels
- ADS1247 has four input channels
- ADS1428 has eight input channels

- Each one of the 2/4/8 input channels can be connected to either P(+) or N(-) 
of the amplifier (figure 53) for the ADC.

- Apparently, according to Figure 51. , it is possible to have only one P and 
one N channel enabled at time (and therefore sample only one pair of channels 
with the ADC) since the P and N rails are shared by all the inputs and there's 
only one ADC block.

Therefore, the userland would have to export sysfs file for each of the channels 
where one would write if the channel is possitive(+) / negative(-) / 
not_connected(NC) and then trigger the start of sampling.

What do you think?

[1] http://www.ti.com/lit/ds/symlink/ads1247.pdf

Best regards,
Marek Vasut

Re: ADC setting for differential and single-ended channels

[Otavio Salvador]

On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> > Otavio Salvador <otavio@ossystems.com.br> wrote:
>> >>Hello,
>> >>
>> >>Mario and I are working at TI ADS124x driver and this chip can be used
>> >>in two ways:
>> >>
>> >>In case of ADS1247:
>> >> - 2 differential channels
>> >> - 3 single-ended channels
>> >>
>> >>In the first case it take two inputs and the chip returns the
>> >>difference between them; in the second case it does the same but you
>> >>must choose one channel to be the negative reference for all the other
>> >>inputs. This is how we understood the datasheet however the
>> >>single-ended use is quite confusing on it so we might be wrong.
>> >>
>> >>So we'd like to know the best way to handle those cases in the driver.
>> >>
>> >>One alternative we discussed is to use two attributes in the dts as:
>> >> ...
>> >> #channels = <2>;
>> >> channels = <0 3
>> >>
>> >>                    1 2>;
>> >>
>> >>So it'd take two channels. One composed by input 0 and input 3 and
>> >>another composed by input 1 and input 2.
>> >>
>> >>On the another case, we'd use:
>> >>  ...
>> >>  #channels = <3>
>> >>  channels = <0 3
>> >>
>> >>                     1 3
>> >>                     2 3>;
>> >>
>> >>So it'd take three channels and all them comparing to input 3.
>> >>
>> >>Are we in the right route? Any hints how to better solve this?
>> >>
>> > Another option is to leave it entirely up to user space.  See max1363
>> > driver where both single ended and differential channels are supported
>> > at the same time with care taken in buffered mode.
>> >
>> > Not sure if that works for your case?
>>
>> I think it is nicer to have it set in the dt; we need the dt anyway so
>> it seems logical to get it setting  the right channel.
>
> Can you please elaborate why is it logical?
>
> I took a brief look over the datasheet [1], here are the facts I see (correct me
> if I'm wrong). I first looked at Figure 51. :
>
> - ADS1246 has two input channels
> - ADS1247 has four input channels
> - ADS1428 has eight input channels
>
> - Each one of the 2/4/8 input channels can be connected to either P(+) or N(-)
> of the amplifier (figure 53) for the ADC.
>
> - Apparently, according to Figure 51. , it is possible to have only one P and
> one N channel enabled at time (and therefore sample only one pair of channels
> with the ADC) since the P and N rails are shared by all the inputs and there's
> only one ADC block.
>
> Therefore, the userland would have to export sysfs file for each of the channels
> where one would write if the channel is possitive(+) / negative(-) /
> not_connected(NC) and then trigger the start of sampling.
>
> What do you think?

This does not make them act as differential  against each other.

We can have several combinations as:

0 - P / 1 - N (differential)
0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
and so on.

So how userland would tell which would be the differential to use?

Our board has:

0 against 1
2 against 3

but it is a design choice.

Am I missing something?




--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: ADC setting for differential and single-ended channels

[Marek Vasut]

Dear Otavio Salvador,

> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> >> > Otavio Salvador <otavio@ossystems.com.br> wrote:
> >> >>Hello,
> >> >>
> >> >>Mario and I are working at TI ADS124x driver and this chip can be used
> >> >>in two ways:
> >> >>
> >> >>In case of ADS1247:
> >> >> - 2 differential channels
> >> >> - 3 single-ended channels
> >> >>
> >> >>In the first case it take two inputs and the chip returns the
> >> >>difference between them; in the second case it does the same but you
> >> >>must choose one channel to be the negative reference for all the other
> >> >>inputs. This is how we understood the datasheet however the
> >> >>single-ended use is quite confusing on it so we might be wrong.
> >> >>
> >> >>So we'd like to know the best way to handle those cases in the driver.
> >> >>
> >> >>One alternative we discussed is to use two attributes in the dts as:
> >> >> ...
> >> >> #channels = <2>;
> >> >> channels = <0 3
> >> >> 
> >> >>                    1 2>;
> >> >>
> >> >>So it'd take two channels. One composed by input 0 and input 3 and
> >> >>another composed by input 1 and input 2.
> >> >>
> >> >>On the another case, we'd use:
> >> >>  ...
> >> >>  #channels = <3>
> >> >>  channels = <0 3
> >> >>  
> >> >>                     1 3
> >> >>                     2 3>;
> >> >>
> >> >>So it'd take three channels and all them comparing to input 3.
> >> >>
> >> >>Are we in the right route? Any hints how to better solve this?
> >> >>
> >> > Another option is to leave it entirely up to user space.  See max1363
> >> > driver where both single ended and differential channels are supported
> >> > at the same time with care taken in buffered mode.
> >> > 
> >> > Not sure if that works for your case?
> >> 
> >> I think it is nicer to have it set in the dt; we need the dt anyway so
> >> it seems logical to get it setting  the right channel.
> > 
> > Can you please elaborate why is it logical?
> > 
> > I took a brief look over the datasheet [1], here are the facts I see
> > (correct me if I'm wrong). I first looked at Figure 51. :
> > 
> > - ADS1246 has two input channels
> > - ADS1247 has four input channels
> > - ADS1428 has eight input channels
> > 
> > - Each one of the 2/4/8 input channels can be connected to either P(+) or
> > N(-) of the amplifier (figure 53) for the ADC.
> > 
> > - Apparently, according to Figure 51. , it is possible to have only one P
> > and one N channel enabled at time (and therefore sample only one pair of
> > channels with the ADC) since the P and N rails are shared by all the
> > inputs and there's only one ADC block.
> > 
> > Therefore, the userland would have to export sysfs file for each of the
> > channels where one would write if the channel is possitive(+) /
> > negative(-) / not_connected(NC) and then trigger the start of sampling.
> > 
> > What do you think?
> 
> This does not make them act as differential  against each other.
> 
> We can have several combinations as:
> 
> 0 - P / 1 - N (differential)
> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
> and so on.
> 
> So how userland would tell which would be the differential to use?
> 
> Our board has:
> 
> 0 against 1
> 2 against 3
> 
> but it is a design choice.
> 
> Am I missing something?

echo 'P' > /sys/.../chan_mux_0
echo 'P' > /sys/.../chan_mux_2
echo 'N' > /sys/.../chan_mux_1
echo 'N' > /sys/.../chan_mux_3

Like this for example ;-) And this could be nicely implemented via IIO, but I 
believe there might even already be an IIO API for this stuff.

Best regards,
Marek Vasut

Re: ADC setting for differential and single-ended channels

[Marek Vasut]

[...]

> > >> 
> > >> I think it is nicer to have it set in the dt; we need the dt anyway so
> > >> it seems logical to get it setting  the right channel.
> > > 
> > > Can you please elaborate why is it logical?
> > > 
> > > I took a brief look over the datasheet [1], here are the facts I see
> > > (correct me if I'm wrong). I first looked at Figure 51. :
> > > 
> > > - ADS1246 has two input channels
> > > - ADS1247 has four input channels
> > > - ADS1428 has eight input channels
> > > 
> > > - Each one of the 2/4/8 input channels can be connected to either P(+)
> > > or N(-) of the amplifier (figure 53) for the ADC.
> > > 
> > > - Apparently, according to Figure 51. , it is possible to have only one
> > > P and one N channel enabled at time (and therefore sample only one
> > > pair of channels with the ADC) since the P and N rails are shared by
> > > all the inputs and there's only one ADC block.
> > > 
> > > Therefore, the userland would have to export sysfs file for each of the
> > > channels where one would write if the channel is possitive(+) /
> > > negative(-) / not_connected(NC) and then trigger the start of sampling.
> > > 
> > > What do you think?
> > 
> > This does not make them act as differential  against each other.
> > 
> > We can have several combinations as:
> > 
> > 0 - P / 1 - N (differential)
> > 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
> > and so on.
> > 
> > So how userland would tell which would be the differential to use?
> > 
> > Our board has:
> > 
> > 0 against 1
> > 2 against 3
> > 
> > but it is a design choice.
> > 
> > Am I missing something?
> 
> echo 'P' > /sys/.../chan_mux_0
> echo 'P' > /sys/.../chan_mux_2
> echo 'N' > /sys/.../chan_mux_1
> echo 'N' > /sys/.../chan_mux_3
> 
> Like this for example ;-) And this could be nicely implemented via IIO, but
> I believe there might even already be an IIO API for this stuff.

btw. you might even implement some kind of channel sets, where you could have 
mapping between 1 P-channel : N N-channel or the other way around , but this 
seems rather complex. I'm just adding this here as an option that came to me.

Best regards,
Marek Vasut

Re: ADC setting for differential and single-ended channels

[Lars-Peter Clausen]

On 07/18/2013 06:08 AM, Marek Vasut wrote:
> Dear Otavio Salvador,
> 
>> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
>>> Dear Otavio Salvador,
>>>
>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Mario and I are working at TI ADS124x driver and this chip can be used
>>>>>> in two ways:
>>>>>>
>>>>>> In case of ADS1247:
>>>>>> - 2 differential channels
>>>>>> - 3 single-ended channels
>>>>>>
>>>>>> In the first case it take two inputs and the chip returns the
>>>>>> difference between them; in the second case it does the same but you
>>>>>> must choose one channel to be the negative reference for all the other
>>>>>> inputs. This is how we understood the datasheet however the
>>>>>> single-ended use is quite confusing on it so we might be wrong.
>>>>>>
>>>>>> So we'd like to know the best way to handle those cases in the driver.
>>>>>>
>>>>>> One alternative we discussed is to use two attributes in the dts as:
>>>>>> ...
>>>>>> #channels = <2>;
>>>>>> channels = <0 3
>>>>>>
>>>>>>                    1 2>;
>>>>>>
>>>>>> So it'd take two channels. One composed by input 0 and input 3 and
>>>>>> another composed by input 1 and input 2.
>>>>>>
>>>>>> On the another case, we'd use:
>>>>>>  ...
>>>>>>  #channels = <3>
>>>>>>  channels = <0 3
>>>>>>  
>>>>>>                     1 3
>>>>>>                     2 3>;
>>>>>>
>>>>>> So it'd take three channels and all them comparing to input 3.
>>>>>>
>>>>>> Are we in the right route? Any hints how to better solve this?
>>>>>>
>>>>> Another option is to leave it entirely up to user space.  See max1363
>>>>> driver where both single ended and differential channels are supported
>>>>> at the same time with care taken in buffered mode.
>>>>>
>>>>> Not sure if that works for your case?
>>>>
>>>> I think it is nicer to have it set in the dt; we need the dt anyway so
>>>> it seems logical to get it setting  the right channel.
>>>
>>> Can you please elaborate why is it logical?
>>>
>>> I took a brief look over the datasheet [1], here are the facts I see
>>> (correct me if I'm wrong). I first looked at Figure 51. :
>>>
>>> - ADS1246 has two input channels
>>> - ADS1247 has four input channels
>>> - ADS1428 has eight input channels
>>>
>>> - Each one of the 2/4/8 input channels can be connected to either P(+) or
>>> N(-) of the amplifier (figure 53) for the ADC.
>>>
>>> - Apparently, according to Figure 51. , it is possible to have only one P
>>> and one N channel enabled at time (and therefore sample only one pair of
>>> channels with the ADC) since the P and N rails are shared by all the
>>> inputs and there's only one ADC block.
>>>
>>> Therefore, the userland would have to export sysfs file for each of the
>>> channels where one would write if the channel is possitive(+) /
>>> negative(-) / not_connected(NC) and then trigger the start of sampling.
>>>
>>> What do you think?
>>
>> This does not make them act as differential  against each other.
>>
>> We can have several combinations as:
>>
>> 0 - P / 1 - N (differential)
>> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
>> and so on.
>>
>> So how userland would tell which would be the differential to use?
>>
>> Our board has:
>>
>> 0 against 1
>> 2 against 3
>>
>> but it is a design choice.
>>
>> Am I missing something?
> 
> echo 'P' > /sys/.../chan_mux_0
> echo 'P' > /sys/.../chan_mux_2
> echo 'N' > /sys/.../chan_mux_1
> echo 'N' > /sys/.../chan_mux_3
> 
> Like this for example ;-) And this could be nicely implemented via IIO, but I 
> believe there might even already be an IIO API for this stuff.

Well the standard API as Jonathan said is to expose all possible pin
combinations. In this case that might be up to 8x8=64 channels. In my
opinion that's fine, but on a specific board maybe not all combinations are
valid. So you might want to specify in your platform data or devicetree that
only a subset of these 64 channels is valid and should be exposed to
userspace. In my opinion it makes the most sense to handle this in the IIO
core since this is a generic requirement, nothing specific to this chip.
E.g. even for 'simple' converters you'll find situations where some pins
might not be connected.

- Lars

Re: ADC setting for differential and single-ended channels

[Otavio Salvador]

On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 07/18/2013 06:08 AM, Marek Vasut wrote:
>> Dear Otavio Salvador,
>>
>>> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
>>>> Dear Otavio Salvador,
>>>>
>>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Mario and I are working at TI ADS124x driver and this chip can be used
>>>>>>> in two ways:
>>>>>>>
>>>>>>> In case of ADS1247:
>>>>>>> - 2 differential channels
>>>>>>> - 3 single-ended channels
>>>>>>>
>>>>>>> In the first case it take two inputs and the chip returns the
>>>>>>> difference between them; in the second case it does the same but you
>>>>>>> must choose one channel to be the negative reference for all the other
>>>>>>> inputs. This is how we understood the datasheet however the
>>>>>>> single-ended use is quite confusing on it so we might be wrong.
>>>>>>>
>>>>>>> So we'd like to know the best way to handle those cases in the driver.
>>>>>>>
>>>>>>> One alternative we discussed is to use two attributes in the dts as:
>>>>>>> ...
>>>>>>> #channels = <2>;
>>>>>>> channels = <0 3
>>>>>>>
>>>>>>>                    1 2>;
>>>>>>>
>>>>>>> So it'd take two channels. One composed by input 0 and input 3 and
>>>>>>> another composed by input 1 and input 2.
>>>>>>>
>>>>>>> On the another case, we'd use:
>>>>>>>  ...
>>>>>>>  #channels = <3>
>>>>>>>  channels = <0 3
>>>>>>>
>>>>>>>                     1 3
>>>>>>>                     2 3>;
>>>>>>>
>>>>>>> So it'd take three channels and all them comparing to input 3.
>>>>>>>
>>>>>>> Are we in the right route? Any hints how to better solve this?
>>>>>>>
>>>>>> Another option is to leave it entirely up to user space.  See max1363
>>>>>> driver where both single ended and differential channels are supported
>>>>>> at the same time with care taken in buffered mode.
>>>>>>
>>>>>> Not sure if that works for your case?
>>>>>
>>>>> I think it is nicer to have it set in the dt; we need the dt anyway so
>>>>> it seems logical to get it setting  the right channel.
>>>>
>>>> Can you please elaborate why is it logical?
>>>>
>>>> I took a brief look over the datasheet [1], here are the facts I see
>>>> (correct me if I'm wrong). I first looked at Figure 51. :
>>>>
>>>> - ADS1246 has two input channels
>>>> - ADS1247 has four input channels
>>>> - ADS1428 has eight input channels
>>>>
>>>> - Each one of the 2/4/8 input channels can be connected to either P(+) or
>>>> N(-) of the amplifier (figure 53) for the ADC.
>>>>
>>>> - Apparently, according to Figure 51. , it is possible to have only one P
>>>> and one N channel enabled at time (and therefore sample only one pair of
>>>> channels with the ADC) since the P and N rails are shared by all the
>>>> inputs and there's only one ADC block.
>>>>
>>>> Therefore, the userland would have to export sysfs file for each of the
>>>> channels where one would write if the channel is possitive(+) /
>>>> negative(-) / not_connected(NC) and then trigger the start of sampling.
>>>>
>>>> What do you think?
>>>
>>> This does not make them act as differential  against each other.
>>>
>>> We can have several combinations as:
>>>
>>> 0 - P / 1 - N (differential)
>>> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
>>> and so on.
>>>
>>> So how userland would tell which would be the differential to use?
>>>
>>> Our board has:
>>>
>>> 0 against 1
>>> 2 against 3
>>>
>>> but it is a design choice.
>>>
>>> Am I missing something?
>>
>> echo 'P' > /sys/.../chan_mux_0
>> echo 'P' > /sys/.../chan_mux_2
>> echo 'N' > /sys/.../chan_mux_1
>> echo 'N' > /sys/.../chan_mux_3
>>
>> Like this for example ;-) And this could be nicely implemented via IIO, but I
>> believe there might even already be an IIO API for this stuff.
>
> Well the standard API as Jonathan said is to expose all possible pin
> combinations. In this case that might be up to 8x8=64 channels. In my
> opinion that's fine, but on a specific board maybe not all combinations are
> valid. So you might want to specify in your platform data or devicetree that
> only a subset of these 64 channels is valid and should be exposed to
> userspace. In my opinion it makes the most sense to handle this in the IIO
> core since this is a generic requirement, nothing specific to this chip.
> E.g. even for 'simple' converters you'll find situations where some pins
> might not be connected.

Right and how should we do this?

Because it would not be 8x8 but it has also the single-ended
combinations (using different N inputs).

So in the end, it'd have a huge number of channels in sysfs where only
few would be used. This seems confusing for user from my POV.

You said about handle this pins to be exposed in IIO core, does IIO
already provide support for it?

Please advice,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: ADC setting for differential and single-ended channels

[Lars-Peter Clausen]

On 07/18/2013 02:02 PM, Otavio Salvador wrote:
> On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 07/18/2013 06:08 AM, Marek Vasut wrote:
>>> Dear Otavio Salvador,
>>>
>>>> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
>>>>> Dear Otavio Salvador,
>>>>>
>>>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>>> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Mario and I are working at TI ADS124x driver and this chip can be used
>>>>>>>> in two ways:
>>>>>>>>
>>>>>>>> In case of ADS1247:
>>>>>>>> - 2 differential channels
>>>>>>>> - 3 single-ended channels
>>>>>>>>
>>>>>>>> In the first case it take two inputs and the chip returns the
>>>>>>>> difference between them; in the second case it does the same but you
>>>>>>>> must choose one channel to be the negative reference for all the other
>>>>>>>> inputs. This is how we understood the datasheet however the
>>>>>>>> single-ended use is quite confusing on it so we might be wrong.
>>>>>>>>
>>>>>>>> So we'd like to know the best way to handle those cases in the driver.
>>>>>>>>
>>>>>>>> One alternative we discussed is to use two attributes in the dts as:
>>>>>>>> ...
>>>>>>>> #channels = <2>;
>>>>>>>> channels = <0 3
>>>>>>>>
>>>>>>>>                    1 2>;
>>>>>>>>
>>>>>>>> So it'd take two channels. One composed by input 0 and input 3 and
>>>>>>>> another composed by input 1 and input 2.
>>>>>>>>
>>>>>>>> On the another case, we'd use:
>>>>>>>>  ...
>>>>>>>>  #channels = <3>
>>>>>>>>  channels = <0 3
>>>>>>>>
>>>>>>>>                     1 3
>>>>>>>>                     2 3>;
>>>>>>>>
>>>>>>>> So it'd take three channels and all them comparing to input 3.
>>>>>>>>
>>>>>>>> Are we in the right route? Any hints how to better solve this?
>>>>>>>>
>>>>>>> Another option is to leave it entirely up to user space.  See max1363
>>>>>>> driver where both single ended and differential channels are supported
>>>>>>> at the same time with care taken in buffered mode.
>>>>>>>
>>>>>>> Not sure if that works for your case?
>>>>>>
>>>>>> I think it is nicer to have it set in the dt; we need the dt anyway so
>>>>>> it seems logical to get it setting  the right channel.
>>>>>
>>>>> Can you please elaborate why is it logical?
>>>>>
>>>>> I took a brief look over the datasheet [1], here are the facts I see
>>>>> (correct me if I'm wrong). I first looked at Figure 51. :
>>>>>
>>>>> - ADS1246 has two input channels
>>>>> - ADS1247 has four input channels
>>>>> - ADS1428 has eight input channels
>>>>>
>>>>> - Each one of the 2/4/8 input channels can be connected to either P(+) or
>>>>> N(-) of the amplifier (figure 53) for the ADC.
>>>>>
>>>>> - Apparently, according to Figure 51. , it is possible to have only one P
>>>>> and one N channel enabled at time (and therefore sample only one pair of
>>>>> channels with the ADC) since the P and N rails are shared by all the
>>>>> inputs and there's only one ADC block.
>>>>>
>>>>> Therefore, the userland would have to export sysfs file for each of the
>>>>> channels where one would write if the channel is possitive(+) /
>>>>> negative(-) / not_connected(NC) and then trigger the start of sampling.
>>>>>
>>>>> What do you think?
>>>>
>>>> This does not make them act as differential  against each other.
>>>>
>>>> We can have several combinations as:
>>>>
>>>> 0 - P / 1 - N (differential)
>>>> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
>>>> and so on.
>>>>
>>>> So how userland would tell which would be the differential to use?
>>>>
>>>> Our board has:
>>>>
>>>> 0 against 1
>>>> 2 against 3
>>>>
>>>> but it is a design choice.
>>>>
>>>> Am I missing something?
>>>
>>> echo 'P' > /sys/.../chan_mux_0
>>> echo 'P' > /sys/.../chan_mux_2
>>> echo 'N' > /sys/.../chan_mux_1
>>> echo 'N' > /sys/.../chan_mux_3
>>>
>>> Like this for example ;-) And this could be nicely implemented via IIO, but I
>>> believe there might even already be an IIO API for this stuff.
>>
>> Well the standard API as Jonathan said is to expose all possible pin
>> combinations. In this case that might be up to 8x8=64 channels. In my
>> opinion that's fine, but on a specific board maybe not all combinations are
>> valid. So you might want to specify in your platform data or devicetree that
>> only a subset of these 64 channels is valid and should be exposed to
>> userspace. In my opinion it makes the most sense to handle this in the IIO
>> core since this is a generic requirement, nothing specific to this chip.
>> E.g. even for 'simple' converters you'll find situations where some pins
>> might not be connected.
> 
> Right and how should we do this?
> 
> Because it would not be 8x8 but it has also the single-ended
> combinations (using different N inputs).

Does the device really support single ended, it looks to me as if it only
supports pseudo-differential configurations.

> 
> So in the end, it'd have a huge number of channels in sysfs where only
> few would be used. This seems confusing for user from my POV.
> 
> You said about handle this pins to be exposed in IIO core, does IIO
> already provide support for it?

No unfortunately not, but as I said, this is not a device specific
requirement and thus we should find a way to handle this generically in the
IIO core.

- Lars

Re: ADC setting for differential and single-ended channels

[Otavio Salvador]

On Thu, Jul 18, 2013 at 10:54 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 07/18/2013 02:02 PM, Otavio Salvador wrote:
>> On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>> On 07/18/2013 06:08 AM, Marek Vasut wrote:
>>>> Dear Otavio Salvador,
>>>>
>>>>> On Thu, Jul 18, 2013 at 12:31 AM, Marek Vasut <marex@denx.de> wrote:
>>>>>> Dear Otavio Salvador,
>>>>>>
>>>>>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>>>> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Mario and I are working at TI ADS124x driver and this chip can be used
>>>>>>>>> in two ways:
>>>>>>>>>
>>>>>>>>> In case of ADS1247:
>>>>>>>>> - 2 differential channels
>>>>>>>>> - 3 single-ended channels
>>>>>>>>>
>>>>>>>>> In the first case it take two inputs and the chip returns the
>>>>>>>>> difference between them; in the second case it does the same but you
>>>>>>>>> must choose one channel to be the negative reference for all the other
>>>>>>>>> inputs. This is how we understood the datasheet however the
>>>>>>>>> single-ended use is quite confusing on it so we might be wrong.
>>>>>>>>>
>>>>>>>>> So we'd like to know the best way to handle those cases in the driver.
>>>>>>>>>
>>>>>>>>> One alternative we discussed is to use two attributes in the dts as:
>>>>>>>>> ...
>>>>>>>>> #channels = <2>;
>>>>>>>>> channels = <0 3
>>>>>>>>>
>>>>>>>>>                    1 2>;
>>>>>>>>>
>>>>>>>>> So it'd take two channels. One composed by input 0 and input 3 and
>>>>>>>>> another composed by input 1 and input 2.
>>>>>>>>>
>>>>>>>>> On the another case, we'd use:
>>>>>>>>>  ...
>>>>>>>>>  #channels = <3>
>>>>>>>>>  channels = <0 3
>>>>>>>>>
>>>>>>>>>                     1 3
>>>>>>>>>                     2 3>;
>>>>>>>>>
>>>>>>>>> So it'd take three channels and all them comparing to input 3.
>>>>>>>>>
>>>>>>>>> Are we in the right route? Any hints how to better solve this?
>>>>>>>>>
>>>>>>>> Another option is to leave it entirely up to user space.  See max1363
>>>>>>>> driver where both single ended and differential channels are supported
>>>>>>>> at the same time with care taken in buffered mode.
>>>>>>>>
>>>>>>>> Not sure if that works for your case?
>>>>>>>
>>>>>>> I think it is nicer to have it set in the dt; we need the dt anyway so
>>>>>>> it seems logical to get it setting  the right channel.
>>>>>>
>>>>>> Can you please elaborate why is it logical?
>>>>>>
>>>>>> I took a brief look over the datasheet [1], here are the facts I see
>>>>>> (correct me if I'm wrong). I first looked at Figure 51. :
>>>>>>
>>>>>> - ADS1246 has two input channels
>>>>>> - ADS1247 has four input channels
>>>>>> - ADS1428 has eight input channels
>>>>>>
>>>>>> - Each one of the 2/4/8 input channels can be connected to either P(+) or
>>>>>> N(-) of the amplifier (figure 53) for the ADC.
>>>>>>
>>>>>> - Apparently, according to Figure 51. , it is possible to have only one P
>>>>>> and one N channel enabled at time (and therefore sample only one pair of
>>>>>> channels with the ADC) since the P and N rails are shared by all the
>>>>>> inputs and there's only one ADC block.
>>>>>>
>>>>>> Therefore, the userland would have to export sysfs file for each of the
>>>>>> channels where one would write if the channel is possitive(+) /
>>>>>> negative(-) / not_connected(NC) and then trigger the start of sampling.
>>>>>>
>>>>>> What do you think?
>>>>>
>>>>> This does not make them act as differential  against each other.
>>>>>
>>>>> We can have several combinations as:
>>>>>
>>>>> 0 - P / 1 - N (differential)
>>>>> 0 - P / 1 - P / 2 - P / 3 - N (all differential to 3)
>>>>> and so on.
>>>>>
>>>>> So how userland would tell which would be the differential to use?
>>>>>
>>>>> Our board has:
>>>>>
>>>>> 0 against 1
>>>>> 2 against 3
>>>>>
>>>>> but it is a design choice.
>>>>>
>>>>> Am I missing something?
>>>>
>>>> echo 'P' > /sys/.../chan_mux_0
>>>> echo 'P' > /sys/.../chan_mux_2
>>>> echo 'N' > /sys/.../chan_mux_1
>>>> echo 'N' > /sys/.../chan_mux_3
>>>>
>>>> Like this for example ;-) And this could be nicely implemented via IIO, but I
>>>> believe there might even already be an IIO API for this stuff.
>>>
>>> Well the standard API as Jonathan said is to expose all possible pin
>>> combinations. In this case that might be up to 8x8=64 channels. In my
>>> opinion that's fine, but on a specific board maybe not all combinations are
>>> valid. So you might want to specify in your platform data or devicetree that
>>> only a subset of these 64 channels is valid and should be exposed to
>>> userspace. In my opinion it makes the most sense to handle this in the IIO
>>> core since this is a generic requirement, nothing specific to this chip.
>>> E.g. even for 'simple' converters you'll find situations where some pins
>>> might not be connected.
>>
>> Right and how should we do this?
>>
>> Because it would not be 8x8 but it has also the single-ended
>> combinations (using different N inputs).
>
> Does the device really support single ended, it looks to me as if it only
> supports pseudo-differential configurations.

I think it is always differential but you can use a single N input for
it. This explain why it's "single-ended" has one less of input ports.

>> So in the end, it'd have a huge number of channels in sysfs where only
>> few would be used. This seems confusing for user from my POV.
>>
>> You said about handle this pins to be exposed in IIO core, does IIO
>> already provide support for it?
>
> No unfortunately not, but as I said, this is not a device specific
> requirement and thus we should find a way to handle this generically in the
> IIO core.

Arrg; :-) Right.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: ADC setting for differential and single-ended channels

[Mario Domenech Goulart]

Hi Lars,

On Thu, 18 Jul 2013 15:54:03 +0200 Lars-Peter Clausen <lars@metafoo.de> wrote:

> On 07/18/2013 02:02 PM, Otavio Salvador wrote:
>> On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>
>>> Well the standard API as Jonathan said is to expose all possible pin
>>> combinations. In this case that might be up to 8x8=64 channels. In my
>>> opinion that's fine, but on a specific board maybe not all combinations are
>>> valid. So you might want to specify in your platform data or devicetree that
>>> only a subset of these 64 channels is valid and should be exposed to
>>> userspace. In my opinion it makes the most sense to handle this in the IIO
>>> core since this is a generic requirement, nothing specific to this chip.
>>> E.g. even for 'simple' converters you'll find situations where some pins
>>> might not be connected.
>> 
>> Right and how should we do this?
>> 
>> Because it would not be 8x8 but it has also the single-ended
>> combinations (using different N inputs).
>
> Does the device really support single ended, it looks to me as if it only
> supports pseudo-differential configurations.

That's not very clear to me either.  The datasheet states the chips have
single-ended inputs, but the mux configuration always assume a positive
input and a negative input.

I'm assuming the "single-ended" mode refers to using an arbitrary input
as negative reference to all the other n-1 inputs.  I suppose that'd be
a pseudo-differential configuration, right?

Best wishes.
Mario

Re: ADC setting for differential and single-ended channels

[Mario Domenech Goulart]

On Thu, 18 Jul 2013 14:59:34 +0000 Mario Domenech Goulart <mario@ossystems.com.br> wrote:

> On Thu, 18 Jul 2013 15:54:03 +0200 Lars-Peter Clausen <lars@metafoo.de> wrote:
>
>> On 07/18/2013 02:02 PM, Otavio Salvador wrote:
>>> On Thu, Jul 18, 2013 at 2:50 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>>
>>>> Well the standard API as Jonathan said is to expose all possible pin
>>>> combinations. In this case that might be up to 8x8=64 channels. In my
>>>> opinion that's fine, but on a specific board maybe not all combinations are
>>>> valid. So you might want to specify in your platform data or devicetree that
>>>> only a subset of these 64 channels is valid and should be exposed to
>>>> userspace. In my opinion it makes the most sense to handle this in the IIO
>>>> core since this is a generic requirement, nothing specific to this chip.
>>>> E.g. even for 'simple' converters you'll find situations where some pins
>>>> might not be connected.
>>> 
>>> Right and how should we do this?
>>> 
>>> Because it would not be 8x8 but it has also the single-ended
>>> combinations (using different N inputs).
>>
>> Does the device really support single ended, it looks to me as if it only
>> supports pseudo-differential configurations.
>
> That's not very clear to me either.  The datasheet states the chips have
> single-ended inputs, but the mux configuration always assume a positive
> input and a negative input.
>
> I'm assuming the "single-ended" mode refers to using an arbitrary input
> as negative reference to all the other n-1 inputs.  I suppose that'd be
> a pseudo-differential configuration, right?

Here's part of a message from a TI employee that explains the
single-ended mode:

  "The ADS1248 has 8 multiplexed inputs. When we describe a single ended
  input, we use one input as a common line, and use the remaining 7
  inputs measured against common. In this way we decribe this each as a
  single ended input. That's how we get 7 single ended inputs."

Quoted from
http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/31638/110153.aspx#110153

Best wishes.
Mario

Re: ADC setting for differential and single-ended channels

[Mario Domenech Goulart]

Hi Marek and folks,

On Thu, 18 Jul 2013 05:31:01 +0200 Marek Vasut <marex@denx.de> wrote:

> Dear Otavio Salvador,
>
>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> > Otavio Salvador <otavio@ossystems.com.br> wrote:
>> >>Hello,
>> >>
>> >>Mario and I are working at TI ADS124x driver and this chip can be used
>> >>in two ways:
>> >>
>> >>In case of ADS1247:
>> >> - 2 differential channels
>> >> - 3 single-ended channels
>> >>
>> >>In the first case it take two inputs and the chip returns the
>> >>difference between them; in the second case it does the same but you
>> >>must choose one channel to be the negative reference for all the other
>> >>inputs. This is how we understood the datasheet however the
>> >>single-ended use is quite confusing on it so we might be wrong.
>> >>
>> >>So we'd like to know the best way to handle those cases in the driver.
>> >>
>> >>One alternative we discussed is to use two attributes in the dts as:
>> >> ...
>> >> #channels = <2>;
>> >> channels = <0 3
>> >> 
>> >>                    1 2>;
>> >>
>> >>So it'd take two channels. One composed by input 0 and input 3 and
>> >>another composed by input 1 and input 2.
>> >>
>> >>On the another case, we'd use:
>> >>  ...
>> >>  #channels = <3>
>> >>  channels = <0 3
>> >>  
>> >>                     1 3
>> >>                     2 3>;
>> >>
>> >>So it'd take three channels and all them comparing to input 3.
>> >>
>> >>Are we in the right route? Any hints how to better solve this?
>> >>
>> > Another option is to leave it entirely up to user space.  See max1363
>> > driver where both single ended and differential channels are supported
>> > at the same time with care taken in buffered mode.
>> > 
>> > Not sure if that works for your case?
>> 
>> I think it is nicer to have it set in the dt; we need the dt anyway so
>> it seems logical to get it setting  the right channel.
>
> Can you please elaborate why is it logical?

I suppose Otavio means that users (i.e., board manufacturers) of the
ADS124x chip will have to require/make/provide a dt (for CS, DRDY
etc. settings), so it wouldn't hurt to specify the channels
configuration in it.

> I took a brief look over the datasheet [1], here are the facts I see (correct me 
> if I'm wrong). I first looked at Figure 51. :
>
> - ADS1246 has two input channels
> - ADS1247 has four input channels
> - ADS1428 has eight input channels
>
> - Each one of the 2/4/8 input channels can be connected to either P(+) or N(-) 
> of the amplifier (figure 53) for the ADC.
>
> - Apparently, according to Figure 51. , it is possible to have only one P and 
> one N channel enabled at time (and therefore sample only one pair of channels 
> with the ADC) since the P and N rails are shared by all the inputs and there's 
> only one ADC block.

That's what we figured too.  I think it's correct.

> Therefore, the userland would have to export sysfs file for each of the channels 
> where one would write if the channel is possitive(+) / negative(-) / 
> not_connected(NC) and then trigger the start of sampling.
>
> What do you think?

That sounds like an interesting option.  It's still not very clear to me
how to specify which input is reference to which input, but I suppose
that must be possible.

As far as I understand, we have three options so far:

a. Specify the channels configuration in the dt.  sysfs would expose the
   exact channels configuration as specified in the dt.

b. Expose all the possible input combinations via sysfs and leave to
   userland to properly read channels.

c. Expose the mux interface via sysfs, so that userland can configure
   channels.

Does that sound right?

Is there any best practice among drivers with regard to how to expose
the interface to channels via sysfs?

> [1] http://www.ti.com/lit/ds/symlink/ads1247.pdf
>
> Best regards,
> Marek Vasut

Best wishes.
Mario

Re: ADC setting for differential and single-ended channels

[Lars-Peter Clausen]

On 07/18/2013 02:44 PM, Mario Domenech Goulart wrote:
> Hi Marek and folks,
> 
> On Thu, 18 Jul 2013 05:31:01 +0200 Marek Vasut <marex@denx.de> wrote:
> 
>> Dear Otavio Salvador,
>>
>>> On Wed, Jul 17, 2013 at 4:12 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>>> Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>>> Hello,
>>>>>
>>>>> Mario and I are working at TI ADS124x driver and this chip can be used
>>>>> in two ways:
>>>>>
>>>>> In case of ADS1247:
>>>>> - 2 differential channels
>>>>> - 3 single-ended channels
>>>>>
>>>>> In the first case it take two inputs and the chip returns the
>>>>> difference between them; in the second case it does the same but you
>>>>> must choose one channel to be the negative reference for all the other
>>>>> inputs. This is how we understood the datasheet however the
>>>>> single-ended use is quite confusing on it so we might be wrong.
>>>>>
>>>>> So we'd like to know the best way to handle those cases in the driver.
>>>>>
>>>>> One alternative we discussed is to use two attributes in the dts as:
>>>>> ...
>>>>> #channels = <2>;
>>>>> channels = <0 3
>>>>>
>>>>>                    1 2>;
>>>>>
>>>>> So it'd take two channels. One composed by input 0 and input 3 and
>>>>> another composed by input 1 and input 2.
>>>>>
>>>>> On the another case, we'd use:
>>>>>  ...
>>>>>  #channels = <3>
>>>>>  channels = <0 3
>>>>>  
>>>>>                     1 3
>>>>>                     2 3>;
>>>>>
>>>>> So it'd take three channels and all them comparing to input 3.
>>>>>
>>>>> Are we in the right route? Any hints how to better solve this?
>>>>>
>>>> Another option is to leave it entirely up to user space.  See max1363
>>>> driver where both single ended and differential channels are supported
>>>> at the same time with care taken in buffered mode.
>>>>
>>>> Not sure if that works for your case?
>>>
>>> I think it is nicer to have it set in the dt; we need the dt anyway so
>>> it seems logical to get it setting  the right channel.
>>
>> Can you please elaborate why is it logical?
> 
> I suppose Otavio means that users (i.e., board manufacturers) of the
> ADS124x chip will have to require/make/provide a dt (for CS, DRDY
> etc. settings), so it wouldn't hurt to specify the channels
> configuration in it.
> 
>> I took a brief look over the datasheet [1], here are the facts I see (correct me 
>> if I'm wrong). I first looked at Figure 51. :
>>
>> - ADS1246 has two input channels
>> - ADS1247 has four input channels
>> - ADS1428 has eight input channels
>>
>> - Each one of the 2/4/8 input channels can be connected to either P(+) or N(-) 
>> of the amplifier (figure 53) for the ADC.
>>
>> - Apparently, according to Figure 51. , it is possible to have only one P and 
>> one N channel enabled at time (and therefore sample only one pair of channels 
>> with the ADC) since the P and N rails are shared by all the inputs and there's 
>> only one ADC block.
> 
> That's what we figured too.  I think it's correct.
> 
>> Therefore, the userland would have to export sysfs file for each of the channels 
>> where one would write if the channel is possitive(+) / negative(-) / 
>> not_connected(NC) and then trigger the start of sampling.
>>
>> What do you think?
> 
> That sounds like an interesting option.  It's still not very clear to me
> how to specify which input is reference to which input, but I suppose
> that must be possible.

I don't think Marek's idea is an option. The purpose of a generic framework
is to hide device specific implementation details like this. Not to expose
them, you don't need a framework for that.

> 
> As far as I understand, we have three options so far:
> 
> a. Specify the channels configuration in the dt.  sysfs would expose the
>    exact channels configuration as specified in the dt.
> 
> b. Expose all the possible input combinations via sysfs and leave to
>    userland to properly read channels.
> 
> c. Expose the mux interface via sysfs, so that userland can configure
>    channels.
> 
> Does that sound right?

I think a mixture of a) and b) will be the best solution. How exactly this
is going to be implemented is something we still need to figure out though.

- Lars

Re: ADC setting for differential and single-ended channels

[Otavio Salvador]

On Thu, Jul 18, 2013 at 10:56 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 07/18/2013 02:44 PM, Mario Domenech Goulart wrote:
>> On Thu, 18 Jul 2013 05:31:01 +0200 Marek Vasut <marex@denx.de> wrote:
>>> Therefore, the userland would have to export sysfs file for each of the channels
>>> where one would write if the channel is possitive(+) / negative(-) /
>>> not_connected(NC) and then trigger the start of sampling.
>>>
>>> What do you think?
>>
>> That sounds like an interesting option.  It's still not very clear to me
>> how to specify which input is reference to which input, but I suppose
>> that must be possible.
>
> I don't think Marek's idea is an option. The purpose of a generic framework
> is to hide device specific implementation details like this. Not to expose
> them, you don't need a framework for that.

Agreed.

>> As far as I understand, we have three options so far:
>>
>> a. Specify the channels configuration in the dt.  sysfs would expose the
>>    exact channels configuration as specified in the dt.
>>
>> b. Expose all the possible input combinations via sysfs and leave to
>>    userland to properly read channels.
>>
>> c. Expose the mux interface via sysfs, so that userland can configure
>>    channels.
>>
>> Does that sound right?
>
> I think a mixture of a) and b) will be the best solution. How exactly this
> is going to be implemented is something we still need to figure out though.

Ok, so let's go back to the start:

One alternative we discussed is to use two attributes in the dts as:

 ...
 #channels = <2>;
 channels = <0 3
                    1 2>;

So it'd take two channels. One composed by input 0 and input 3 and
another composed by input 1 and input 2.

On the another case, we'd use:

  ...
  #channels = <3>
  channels = <0 3
                     1 3
                     2 3>;

So it'd take three channels and all them comparing to input 3.

This allow for us to export only the working channel and in properly
configured way. Does it seems sensible? What are the problems with
this idea?

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750