On Wed, May 22, 2013 at 1:43 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: > On 05/22/2013 11:37 AM, Guillaume Ballet wrote: >>>> >>>>> >>>>>> functions' signature only has one integer >>>>>> in/out parameter. That makes sense in the context of _raw because the >>>>>> value isn't yet processed. >>>>>> >>>>>> However, as the scale is a number encoded over two ints, the >>>>>> _processed value should also span two ints. Is there a reason why it's >>>>>> still only one int? >>>>> >>>>> No it certainly should not be one int for exactly the reasons you have >>>>> stated. >>>>>> >>>>>> >>>> >>>> I'm not to sure about that. I'd rather add a scale parameter to the >>>> iio_read_channel_processed, just in the same way the >>>> convert_raw_to_processed function takes a scale parameter. >>> >>> That may be tricky to do given we often have nasty non linear functions >>> that are the reason we are using processed in the first place. Hmm. >>> Not sure which way works better. >> >> I agree, this is the whole point of using processed. Lars, is there a >> specific reason why you want to keep reading the value and the scale >> in different function calls? > > I don't want to keep reading scale and value in different function calls. > > What's you use case and how do you want to split the data between the two > integers? Since the scale's format can be IIO_VAL_INT_PLUS_MICRO and IIO_VAL_INT_PLUS_NANO, etc... and since iio_read_channel_processed returns a value that is homogeneous to (value * scale), it seems to me the same format should be used as when calling iio_read_channel_raw with IIO_CHAN_INFO_SCALE. My use case is not more complicated than making sure I keep the same precision when getting processed values. Guillaume -- 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
