drivers/sensors: add INA260

[jeanthom]

Summary

Add driver for Texas Instruments INA260 voltage/current/power sensor, based on existing INA226 driver.

The driver only supports polling (like INA226).

Impact

Adds a new sensor driver and its documentation. No board or arch modification.

Testing

Tested using Adafruit's INA260 breakout board on STM32F407G-DISC1 with an upcoming ina260 example program that output readout values periodically:

nsh> ina260
U= 23898mV I=   571mA P= 13680mW
U= 23870mV I=   728mA P= 17400mW
U= 23862mV I=   782mA P= 18680mW
U= 23858mV I=   796mA P= 19030mW
U= 23857mV I=   805mA P= 19200mW
U= 23857mV I=   805mA P= 19200mW

These changes were tested on top of NuttX 12.12.0, built on a macOS computer.

[linguini1]

@acassis we've had a few PRs recently with new sensor drivers that we held because they did not use the new sensor framework. Are we applying this rule again here?

[acassis]

@acassis we've had a few PRs recently with new sensor drivers that we held because they did not use the new sensor framework. Are we applying this rule again here?

@linguini1 I think the issue here is there is none energy meter support on uORB yet. So @jeanthom should implement it from scratch. But I agree with you, we should be consistent, if we blocked char dev sensors, we shouldn't create exceptions :-/

@jeanthom could you please try to modify your sensor to follow the uorb sensors implementation?

[jeanthom]

Hi @acassis @linguini1,

I missed the mandatory uORB move, this is my first time working on sensor drivers... I think migrating to uORB would take more time than I'd like to spend. Sorry, I'll pass on it.

Regards,
Jean.

[linguini1]

Hi @acassis @linguini1,

I missed the mandatory uORB move, this is my first time working on sensor drivers... I think migrating to uORB would take more time than I'd like to spend. Sorry, I'll pass on it.

Regards, Jean.

Sorry @jeanthom , thank you! Do you have any suggestions for how we can maybe make it easier for the new sensor driver requirement to be advertised?

[jeanthom]

@linguini1 I'd suggest to mark all legacy sensor drivers as deprecated - I'm not sure how that's done (or could be done) in NuttX however? snerr says "driver is deprecated" inside register function? GCC warning pragma?

When I need support for a new device, my first instinct is to look for something similar in the codebase - as I expect that code similar to already merged code will be accepted more easily.

[linguini1]

@linguini1 I'd suggest to mark all legacy sensor drivers as deprecated - I'm not sure how that's done (or could be done) in NuttX however? snerr says "driver is deprecated" inside register function? GCC warning pragma?

When I need support for a new device, my first instinct is to look for something similar in the codebase - as I expect that code similar to already merged code will be accepted more easily.

Thank you @jeanthom , I'll open an issue to do that (I think a GCC warning pragma + comment might be good for those reading + compiling code). Good suggestion! I always feel bad when this happens because truthfully the documentation isn't particularly navigable and so many contributors will never encounter these "best practices" there to begin with. Sorry!

[jeanthom]

No worries, that driver will find some use at my company anyway :)