Hi Jonathan, thanks for the very good presentation. > Firstly, the quaternion interface. Quaternions require 4 components to > be presented together in order for any meaning to be extracted. Thus it > makes no sense to ever present their components separately. To this end > a new interface is proposed in which all 4 components are presented as > a space separated list. Whilst I welcome comments on this, the actual > question I am raising here concerns not what is presented, but the way we > indicate that this is what is to be expected. > > Two obvious options exist as we have two places this type could be > 'represented'. Either we introduce a new channel type - rotquaternion > which is defined to be a rotation expressed as a quaternion, or we take > the existing channel type rot and apply a modifier (similar to an axis > modifier) to indicate that rather than being a rotation about a given > axis, we have a rotation represented as a quaternion. This would be done > with a new modifier. To illustrate the point, lets take a few example > sysfs attributes. > > Option 1. New channel type > > in_rotquaternion1_raw > in_rotquaternion1_scale > > Option 2. New modifier. > > in_rot1_quaternion_raw > in_rot1_quaternion_scale I prefer option 2 since we still measure a rotation, but an axis makes no sense. I'd even propose to additionally have: in_rot1_xyz_raw to present x y and z in one single reading since a lot of sensor supply a measurement from the same point in time when reading out all values together. > Next lets take the ecap driver and it's pulse characteristic measurement > interface. Here we have a single underlying thing (the waveform) about > which we wish to measure a number of elements. Again, we can either do > this via new channel types, or via modifiers. Note there is precedence for > using index numbers to indicate that multiple measurements are being taken > via the same physical wire of different things. > > Option 1. New Channel types (I'm making the naming up as a go along - the > aim here is generality to other things we might measure and time intervals > are more general than 'pulse' or similar types) > > in_interval1_high_raw (time pulse is high) > in_interval_scale > > in_interval1_low_raw (time pulse is low) > > in_interval_risingtorising_raw (period measured rising edge to rising edge) > in_interval_fallingtofalling_raw (period measured falling to falling) > > > in_interval_rising_raw (rise time of waveform). > in_interval_falling_raw (fall time of waveform). > > in_voltage_peaktopeak_raw (peak to peak voltage). We actually have > interfaces in place for this sort of stuff. > > Option 2 - modifiers for everything. (this is what I suggested in - > http://www.spinics.net/lists/linux-omap/msg103204.html > > in_waveformX_hightime_raw > in_waveformX_lowtime_raw > in_waveformX_period_raw > in_waveformX_markspace_raw > in_waveformX_peaktopeak_raw > in_waveformX_risetime_raw > in_waveformX_falltime_raw > > Personally my thinking has changed since my ecap related email. > I think we want to keep the channel types to be strictly what quantity > is being measured and rely on shared index numbers to indicate that > we are dealing with multiple measurements of a given 'channel'. > > Hence I slightly favour option 1. However the reason I'm sending this > RFC is I definitely want more input on this decision from other regular > IIO developers (and anyone else!). I'm particularly interested in > cases that people don't think are cleanly covered by the proposed options. > I've picked a few people to poke via ccing them, but please do send this > on to anyone else you think might contribute to the discussion. Here I'm with you. Your arguments make perfectly sense for me. > It's going to tie us to a large body of ABI moving forwards. > My apologies to Matt and Srinivas for the fact your drivers have gotten > caught up in this, but we need to get it right. > > Whilst we are talking interface reviews. Another one I proposed recently > was spherical coordinates for position measurements. The main reason > for this is that it gives a unified way of indicating distance from sensor > as > > in_position_r_raw Why would this be a position when you actually measure distance? Can you give an example? > There are also magnetic position sensors that report in full spherical > coordinates so we may want the other elements down the line. > I'm kind of regretting letting the generic 'proximity' interface in now. > Those are measuring something related to distance, but material dependent > so I'm not too bothered if we introduced another similar interface. > Anyone comments on this would be great as well as I'd like to get the > lightning sensor merged sooner rather than later! Regards, Manuel -- 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
