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.
One other thing we should also address is the
byte-ordering/endianess of the scan elements stored in the ring buffers.
Right now the scan_element type details signs, bits, storage bits and
shifts. However it lacks to tell the endianess within the storage bits.
Good point. I'd completely forgotten about that.
How about le:s16/32>>0 or be:s16/32>>0 for example?
Yup, that works for me. In cases where it doesn't matter they driver
can pick one at random.
We need another case - Some drivers use the (be|le)(x)_to_cpu() helpers,
So in case these are used the endianess can be either or, depending on the host.
So maybe have le|be|cpu?
I think we can drop the usage of the (be|le)(x)_to_cpu() helpers. It's
easy to find out the current CPU endianess so we can always provide a
correct term here. Especially important when we use the iiod, as the
data might be processed on a different CPU.
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
--
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
--
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
