Am 28.07.2011 11:52, schrieb Jonathan Cameron:
On 07/28/11 09:33, Manuel Stahl wrote:
Hi,
I had the time to read through the discussion recently, so just a few comments:
Am 28.07.2011 10:08, schrieb Hennerich, Michael:
Jonathan Cameron wrote on 2011-07-28:
On 07/27/11 15:41, Michael Hennerich wrote:
On 07/26/2011 01:06 PM, Jonathan Cameron wrote:
On 07/26/11 11:52, Michael Hennerich wrote:
On 07/26/2011 11:17 AM, Jonathan Cameron wrote:
On 07/26/11 10:01, Hennerich, Michael wrote:
Jonathan Cameron wrote on 2011-07-25:
Michael pointed out the issues that not having an explicit
direction for channels was causing and the inconsistency of the
inX and outX channel naming we got from hmwon.
They are stuck with it, but we aren't, so lets fix this now.
Interesting question is whether we reset the base units to be
volts whilst we are at it? (for voltage channels obviously!)
What do you mean exactly volts versus milli volts?
Make the in_voltage_scale correspond to conversion to volts instead
of millivolts as now (I think). Err. Looking at it that isn't
actually documented... oops. I wonder which drivers actually do
that and which don't.
The ones I wrote provide the scale for millivolts.
With the recent introduction of IIO_VAL_INT_PLUS_NANO we got the
scale accurate enough for the precession 24-bit converters.
If we move to the SI base unit volt, we lose this accuracy again.
Yup, that's the principal counter argument to the change.
If we decide to leave the milli scale for volts... Do we also want to
stay with milli degrees Celsius, etc.? If we do it for one, probably
best to do it for them all..
Hi Jonathan,
So stick with the milli scale for all?
If it's possible, I would like to have pure units. I didn't read the
API with IIO_VAL_INT_PLUS_NANO completely so I don't understand the
problem yet, but using milli just because the drivers we have in
place can measure relatively low voltages make no sense for me.
The issue is we have two integers to play with. The first is
used for the integer part. The second is divided by either 10^6 or 10^9
and added on.
If we go to 10^12, then max value for the decimal bit should be:
999,999,999,999.
Unfortunately we only have a 32 bit int (to avoid use of div64 in drivers).
It's signed as well to allow us to set the integer bit to 0. Hence max
value is 2^31 = 2 147 483 648.
Hence not enough and the hole.
Next question is whether this is an issue. I doubt it with _scale, _offset
_calibbias, but just possibly with _calibscale where very small adjustments
may occur (hence 0.999999999999 is possible.)
Does it help to support exponential formats like 999999.9999999e-10?
--
Manuel Stahl
Fraunhofer-Institut IIS
Leistungsoptimierte Systeme
Nordostpark 93
D90411 Nürnberg
Telefon +49 (0)911/58061-6419
Fax +49 (0)911/58061-6398
E-Mail manuel.stahl@xxxxxxxxxxxxxxxxx
http://www.iis.fraunhofer.de
http://www.smart-power.fraunhofer.de
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
