drivers/sensors: add a new sensor type ENG

[Otpvondoiats]

Summary

• add a new sensor type ENG (Electroneurography).

Provides: apache/nuttx-apps#3312.

Impact

• uorb / new sensor type.

Testing

We have conducted tests on the following platforms:
Simulator - single core:pass
BES Platform - multi-core:pass;

Platform - xiaomi watch 5

grass:/ # uor
uorb_advertise_demo  uorb_downsample      uorb_listener        uorb_rpmsg_test      uorb_unit_test
grass:/ # uorb_listener -n 10 sensor_eng0

Mointor objects num:1
object_name:sensor_eng, object_instance:0
sensor_eng(now:2942986005):timestamp:1555925885,eng0:-0.283753,eng1:4.146453,eng2:-10.340199,eng3:0.000000,status:0x7
sensor_eng(now:2942988113):timestamp:1555930885,eng0:2.807018,eng1:-0.033562,eng2:-3.261632,eng3:0.000000,status:0x7
sensor_eng(now:2942989815):timestamp:1555935885,eng0:4.707857,eng1:0.018306,eng2:-2.935164,eng3:0.000000,status:0x7
sensor_eng(now:2942991548):timestamp:1555940885,eng0:1.281465,eng1:2.248665,eng2:-6.340199,eng3:0.000000,status:0x7
sensor_eng(now:2942993269):timestamp:1555945885,eng0:-5.714722,eng1:2.709382,eng2:-7.572845,eng3:0.000000,status:0x7
sensor_eng(now:2942994463):timestamp:1555950885,eng0:-3.078566,eng1:0.073226,eng2:-4.173913,eng3:0.000000,status:0x7
sensor_eng(now:2942994755):timestamp:1555955885,eng0:2.556827,eng1:-0.070175,eng2:-3.682685,eng3:0.000000,status:0x7
sensor_eng(now:2942995046):timestamp:1555960885,eng0:-0.189169,eng1:1.809306,eng2:-6.468345,eng3:0.000000,status:0x7
sensor_eng(now:2942995230):timestamp:1555965885,eng0:-6.599542,eng1:2.245614,eng2:-7.139588,eng3:0.000000,status:0x7
sensor_eng(now:2942995411):timestamp:1555970885,eng0:-3.130435,eng1:-0.427155,eng2:-3.240275,eng3:0.000000,status:0x7
Object name:sensor_eng0, recieved:10
Total number of received Message:10/10
grass:/ #

[cederom]

TODO: codespell :-)

[Otpvondoiats]

TODO: codespell :-)

Done

[cederom]

Thank you @Otpvondoiats :-)

I am not sure if changing numbers for other sensors is okay each time when we add a new type @linguini1 ? Wouldn't that bring some debug / log / recording issues?:-)

[cederom]

Thank you @Otpvondoiats :-)

• Let's just make sure CU builds fine.
• After this PR is merged apache/nuttx-apps#3312 should follow.

[linguini1]

Thank you @Otpvondoiats :-)

I am not sure if changing numbers for other sensors is okay each time when we add a new type @linguini1 ? Wouldn't that bring some debug / log / recording issues?:-)

In theory I don't think it matters, but I think this should be added at the end of the list without changing any numbers because it clutters the diff and blame history.

[linguini1]

Please add the new type at the bottom of the list to avoid changing the numerical values of other types.

[jerpelea]

please fix the commit title typo

drivers/sensors

[acassis]

@Otpvondoiats I think when adding a new type of sensor it is not a good idea to change the previous sensor type IDs, if someone is using system in protected mode or kernel mode and updating only the kernel the sensor applications will break.

So considering it, this PR is a breaking change

[acassis]

@Otpvondoiats which Electroneurography sensor are you using to test it?

[cederom]

Thank you folks that was exactly my feeling about the numbers :-)

[Otpvondoiats]

please fix the commit title typo

drivers/sensors

done

@Otpvondoiats which Electroneurography sensor are you using to test it?

xiaomi watch 5 https://www.youtube.com/watch?v=PQh7yKgPQyY

[Otpvondoiats]

Thank you @Otpvondoiats :-)

I am not sure if changing numbers for other sensors is okay each time when we add a new type @linguini1 ? Wouldn't that bring some debug / log / recording issues?:-)

It won't have any impact; the type parameter is mainly used by the sensor's internal functions.

[Otpvondoiats]

@Otpvondoiats I think when adding a new type of sensor it is not a good idea to change the previous sensor type IDs, if someone is using system in protected mode or kernel mode and updating only the kernel the sensor applications will break.

So considering it, this PR is a breaking change

The eng type is special because it wasn't uploaded to the community before, and the sensor type synchronization has been constantly changing, causing it to appear earlier in the list. Later types could be added earlier in the gnss module.

[cederom]

Please add new sensor type to the end of the existing sensors identifiers, thanks :-)

[Otpvondoiats]

Please add new sensor type to the end of the existing sensors identifiers, thanks :-)

"eng" needs to be placed in this position. The order of the types does not affect the use by external users. For users, it is a macro that is being used. If numbers are used, then what is the point of defining a macro?

[cederom]

What if you record a data stream / log with these identifiers, use current code to decode it, then someone changes the numbers and you want to decode old recording with a new code?

What if the application and kernel versions mismatch and they contain different identifiers for the same sensor?

3 people are telling you that this is bad practice to add one new thing and break everything around.. usually you append new identifiers to the end of exiting list so that existing identifiers are untouched ;-)

[Otpvondoiats]

What if you record a data stream / log with these identifiers, use current code to decode it, then someone changes the numbers and you want to decode old recording with a new code?

What if the application and kernel versions mismatch and they contain different identifiers for the same sensor?

3 people are telling you that this is bad practice to add one new thing and break everything around.. usually you append new identifiers to the end of exiting list so that existing identifiers are untouched ;-)

1. As I mentioned above, eng is a special type, used since early last year, but its owner was forgotten to be uploaded.
2. To maintain compatibility, Nuttx types need to be aligned with Android. Nuttx has far more types than Android, and new types don't necessarily need to be added to the end. To maintain alignment with Android, it may be necessary to keep the same ID as Android.
3. Sensor-related data streams are identified by topic, not type. In the sensor framework, type is not a type binding. Don't worry too much about this.

https://cs.android.com/android/_/android/platform/hardware/libhardware/+/7e08958a6cbe2b02c9d80a66fba68fd8a864d73d:include_all/hardware/sensors-base.h?hl=zh-cn

enum {
    SENSOR_TYPE_META_DATA = 0,
    SENSOR_TYPE_ACCELEROMETER = 1,
    SENSOR_TYPE_MAGNETIC_FIELD = 2,
    SENSOR_TYPE_ORIENTATION = 3,
    SENSOR_TYPE_GYROSCOPE = 4,
    SENSOR_TYPE_LIGHT = 5,
    SENSOR_TYPE_PRESSURE = 6,
    SENSOR_TYPE_TEMPERATURE = 7,
    SENSOR_TYPE_PROXIMITY = 8,
    SENSOR_TYPE_GRAVITY = 9,
    SENSOR_TYPE_LINEAR_ACCELERATION = 10,
    SENSOR_TYPE_ROTATION_VECTOR = 11,
    SENSOR_TYPE_RELATIVE_HUMIDITY = 12,
    SENSOR_TYPE_AMBIENT_TEMPERATURE = 13,
    SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED = 14,
    SENSOR_TYPE_GAME_ROTATION_VECTOR = 15,
    SENSOR_TYPE_GYROSCOPE_UNCALIBRATED = 16,
    SENSOR_TYPE_SIGNIFICANT_MOTION = 17,
    SENSOR_TYPE_STEP_DETECTOR = 18,
    SENSOR_TYPE_STEP_COUNTER = 19,
    SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR = 20,
    SENSOR_TYPE_HEART_RATE = 21,
    SENSOR_TYPE_TILT_DETECTOR = 22,
    SENSOR_TYPE_WAKE_GESTURE = 23,
    SENSOR_TYPE_GLANCE_GESTURE = 24,
    SENSOR_TYPE_PICK_UP_GESTURE = 25,
    SENSOR_TYPE_WRIST_TILT_GESTURE = 26,
    SENSOR_TYPE_DEVICE_ORIENTATION = 27,
    SENSOR_TYPE_POSE_6DOF = 28,
    SENSOR_TYPE_STATIONARY_DETECT = 29,
    SENSOR_TYPE_MOTION_DETECT = 30,
    SENSOR_TYPE_HEART_BEAT = 31,
    SENSOR_TYPE_DYNAMIC_SENSOR_META = 32,
    SENSOR_TYPE_ADDITIONAL_INFO = 33,
    SENSOR_TYPE_LOW_LATENCY_OFFBODY_DETECT = 34,
    SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED = 35,
    SENSOR_TYPE_HINGE_ANGLE = 36,
    SENSOR_TYPE_HEAD_TRACKER = 37,
    SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES = 38,
    SENSOR_TYPE_GYROSCOPE_LIMITED_AXES = 39,
    SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED = 40,
    SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED = 41,
    SENSOR_TYPE_HEADING = 42,
    SENSOR_TYPE_DEVICE_PRIVATE_BASE = 65536 /* 0x10000 */,
};

nuttx:
https://github.com/apache/nuttx/blob/master/include/nuttx/uorb.h

[cederom]

If Android is considered standard's upstream and NuttX has more new identifiers it may be good to provide these identifiers to the upstream so the world uses the same identifiers, even if unimplemented on their side, correct?

You can try and see would Google say if you add EMP to their existing list as number 5 and increment all following existing id defines.

I have no more comments here.

[Otpvondoiats]

If Android is considered standard's upstream and NuttX has more new identifiers it may be good to provide these identifiers to the upstream so the world uses the same identifiers, even if unimplemented on their side, correct?

You can try and see would Google say if you add EMP to their existing list as number 5 and increment all following existing id defines.

I have no more comments here.

I've already replied above. The "eng" case is special; he was the previous owner and forgot to upload it. The ID position is now set to 48.

Subsequent new sensor types will be placed at the end, before the GNSS module. The order will only change if new types are added for alignment purposes in Android.

Gnss is a special module, so put it at the end.

[Otpvondoiats]

If Android is considered standard's upstream and NuttX has more new identifiers it may be good to provide these identifiers to the upstream so the world uses the same identifiers, even if unimplemented on their side, correct?

You can try and see would Google say if you add EMP to their existing list as number 5 and increment all following existing id defines.

I have no more comments here.

If Android is considered standard's upstream and NuttX has more new identifiers it may be good to provide these identifiers to the upstream so the world uses the same identifiers, even if unimplemented on their side, correct?

You can try and see would Google say if you add EMP to their existing list as number 5 and increment all following existing id defines.

I have no more comments here.

Following your idea, the difference in type id will not be sorted.