I am testing out the new sensor API. Just want to say that 'const'
need to be dropped since we did modify the cmd variable
https://github.com/apache/incubator-mynewt-core/blob/sensors_branch/hw/sensor/src/sensor_shell.c#L38
I got into "Segmentation Fault" when running it with simulation
(native pc).
One other issue I found with this file working on a driver just now:
I also had to change the printf qualifier to '%li' to get this to
compile since the values being passed in for accelerometers are
currently int32_t:
if (ctx->type == SENSOR_TYPE_ACCELEROMETER) {
sad = (struct sensor_accel_data *) data;
if (sad->sad_x != SENSOR_ACCEL_DATA_UNUSED) {
console_printf("x = %li, ", sad->sad_x);
}
if (sad->sad_y != SENSOR_ACCEL_DATA_UNUSED) {
console_printf("y = %li, ", sad->sad_y);
}
if (sad->sad_z != SENSOR_ACCEL_DATA_UNUSED) {
console_printf("z = %li", sad->sad_z);
}
console_printf("\n");
}
Also related, but separate issue:
If we are going to return m/s^2 (which is the right choice for accels I
think and the defacto standard) then the int32_t used above (defined
here
https://github.com/apache/incubator-mynewt-core/blob/sensors_branch/hw/sensor/include/sensor/accel.h)
probably isn't an ideal choice since accelerometers will be +-2/4/8g
normally (sometimes more, but not often for motion detection), which
translates to ~+/-19.6, 39.2, 78.4 m/s^2. A single precision float would
give a better range here, although if a float is inappropriate on the
smallest systems or for other reasons, we might need to scale this to
something less standard like mm/s^2, which at least gets us in a usable
range for sensor fusion?
I used to be allergic to anything float (I've probably been at this too
long), but with time and on faster ARM processors I finally got over
that mental hurdle and use them all the time, and if I avoid them it's
more for precision than performance. But I understand that people have
strong feelings about this, which is why having a 16Q16 type makes sense
for sensors as well.
