apache
drivers/sensors/tc74ax: add driver for TC74Ax thermal sensor
Summary
PR delivered by kerogit over mailing list.
This patch adds support for TC74 Tiny Serial Digital Thermal Sensor from Microchip. It is a standalone chip connected via I2C/SMBus. Documentation for sensor is provided.
IOCTL call used for power management borrows IOCTL code from another driver (ISL29023).
Depends-on: #17403, #17404.
Impact
drivers/sensors: Adds support for TC74 Tiny Serial Digital Thermal Sensor from Microchip + Documentation.
Testing
The driver was tested on AVR128DA28 chip using simple application that read the temperature from it and also switched it to/from standby state.
nsh> tc74_test
tc74_test [4:100]
nsh> Starting TC74 test
Temperature read: 23
Temperature read: 23
I feel bad but should this not be a "uORB" sensor (uORB in quotes because it's just the new sensor framework)? This is what we're asking for from contributors going forward and I think it's counterproductive to keep merging legacy interfaces.
Thanks @linguini1, feedback forwarded to mailing list with additional references :-)
- https://nuttx.apache.org/docs/latest/components/drivers/special/sensors.html
- https://nuttx.apache.org/docs/latest/components/drivers/special/sensors/sensors_uorb.html
- https://nuttx.apache.org/docs/latest/applications/system/uorb/index.html
Response from kerogit:
the TC74Ax driver not being uORB - well, I was not sure whether to submit the driver at all exactly because it is not done the new way. But then I noticed another such driver was merged in August so I posted it. As for the reasons why the driver is not done the new way, there are two:
First - I did not read the documentation. Over my previous submissions, I was never able to find any howto for writing drivers. As in "if you want to make driver for X, do this." (Do not take this as a criticism please, I was thinking about writing such howto but every time I was done with a feature, it seemed to me that there is actually nothing to write about because everything is simple, clear and pretty obvious.) So I got into the habit of simply looking at other code that does the same thing and adapting it. Only after the driver was almost done, I found the documents you linked.
The other reason - and the reason why I did not decide to rewrite the driver - is that unless I misunderstood the documentation, the new way uses floats to exchange data and seems more complex overall. My intended use case is currently 8-bit AVR and I am even not able to compile code that has floats in it. (That can be probably fixed easily by upgrading to newer gcc.) Moreover, floats are expensive to handle. So to put it simple, if I did the driver this way, it would not be of much use to me.
All in all, if the driver gets rejected because it uses deprecated interface, that would be completely understandable from my point of view. However, I have to say that I am not planning to rewrite it in any forseeable future (maybe if it proved easy to have it configurable for both interfaces - judging from bmp180 driver it could be - but I don't think I'll find the time even in such case.)