Hi Sterling,
Nice to see this starting to take shape, and looks very good so far!
I onder if instead of having 30 different sensor types for
triplets/vectors like this:
/**
* Meters per second squared.
*
* 32-bit signed integer, with 0xFFFFFFFF reserved for unused.
*/
#define SENSOR_VALUE_TYPE_MS2 (3)
/**
* Triplet of meters per second squared.
*/
#define SENSOR_VALUE_TYPE_MS2_TRIPLET (4)
We can just have the following:
/**
* Triplet of INT32 values.
*/
#define SENSOR_VALUE_TYPE_INT32_TRIPLET (4)
/**
* Triplet of 32-bit float values.
*/
#define SENSOR_VALUE_TYPE_FLOAT_TRIPLET (5)
The rationale here is that we will know based on the sensor type what
kind of data we have, and this might be more concise than having
multiple entries like rad/s, uTesla, etc., for every sensor type or
vector type output. Just detecting the sensor type should be enough if
we standardize sensors to output the same value types, which I think
adds value to the system as well.
If every accelerometer driver outputs m/s^2, and every magnetometer
outputs uTesla, it means you can drop in any other accel/mag/etc. if a
part becomes EOL, and other than changing the driver there should be
very little implact on the rest of the system. It also simplifies the
sensor value types above since the values types can be inferred from the
sensor type, and we just need to know if it's INT32, FLOAT, FLOAT
TRIPLET, (16Q16 fixed???, DOUBLE???), etc.
The only gotcha for vectors is that the order will need be be defined so
that 0 = X, 1 = Y and 2 = Z for triples, etc., and we'll probably also
want a quaternion/quadruplet type though that's down the road:
/**
* 32-bit float based quaternion quadruplet.
*/
#define SENSOR_VALUE_TYPE_QUATERNION (6)
Kevin
