Fishwaldo opened a new pull request, #19890:
URL: https://github.com/apache/nuttx/pull/19890
## Summary
The TMP112 driver was character mode only, and carried the warning that says
so:
a read returns a bare float at a size the driver chose, and nothing but code
written for this one part can make sense of it.
This adds the sensor framework version beside it, in the shape the tree
already
uses for a part that has both. The old driver is untouched and still builds
by
default; `CONFIG_SENSORS_TMP112_UORB` selects the new one instead, and the
part
then appears as a `sensor_temp<n>` topic the common sensor tools can read
without
knowing what a TMP112 is.
Only one of the two is ever built, and the header only declares the
registration
function belonging to the variant in force, so a board that enables the new
driver without switching to `tmp112_register_uorb()` fails to compile rather
than
failing to link.
This also covers the TMP102, which differs in accuracy rather than in its
registers; only the two registers both parts have are touched.
## Two things it fixes relative to the character mode driver
**The reading is sign extended.** The temperature register holds twelve bits
and
the character mode driver treats them as unsigned, so anything below freezing
comes back as a large positive temperature. This part is specified down to
-40°C. Fixing it in the old driver would change what existing callers see,
so it
is fixed here, where there are no callers yet to surprise.
**A reading is one bus transaction with nothing to wait for.** The part
converts
continuously out of reset, so this driver configures nothing and the
temperature
register always holds the last completed conversion. The pointer write and
the
data read go out as a single transfer with a repeated start.
## Interval handling
The interval is taken as asked. The upper half treats a lower half that hands
back a *longer* interval than it was given as a failed request
(`drivers/sensors/sensor.c`, `min_interval > expected_interval` returns
`-EINVAL`), so clamping to some minimum would refuse a fast subscriber rather
than serve it slowly. Reading faster than the part converts simply repeats a
value, which costs bus traffic and nothing else.
The requeue delay is floored at one tick, so a request for a zero interval
polls
as fast as the clock allows instead of requeueing without ever yielding.
`get_info` reports what the part is and what its readings mean — vendor,
resolution and range — so a consumer does not have to know it is talking to a
TMP112 to interpret the numbers. That matches `sht4x_uorb` and
`mcp9600_uorb`,
the two nearest drivers that implement it.
## Testing
ESWIN EIC7700 EVB (EIC7700X, 4 x RV64GC), part strapped to 0x48 on I2C10,
published as `sensor_temp6`. The board port is being upstreamed separately;
this
PR adds no in-tree user.
At the default interval:
```
nsh> sensortest -n 2 temp6
SensorTest: Test /dev/uorb/sensor_temp6 with interval(1000000us),
latency(0us)
temp6: timestamp:43767502 value:34.13
temp6: timestamp:44768500 value:34.13
```
At 10 ms, which is faster than the part converts:
```
nsh> sensortest -i 10000 -n 3 temp6
SensorTest: Test /dev/uorb/sensor_temp6 with interval(10000us), latency(0us)
temp6: timestamp:47327504 value:34.13
temp6: timestamp:47338500 value:34.13
temp6: timestamp:47349500 value:34.13
```
Samples arrive ~11 ms apart, repeating the value as expected. An earlier
version
of this driver clamped the interval and that request failed with
`Invalid argument`, which is what led to the interval handling described
above.
At 200 ms, samples arrive ~201 ms apart, so the requested rate is honoured
rather than rounded to something convenient.
Also compiled standalone against master with the CI warning set
(`-Wall -Wstrict-prototypes -Wshadow -Wundef`), clean. `tools/checkpatch.sh`
and
`nxstyle` pass. Documentation builds with no new warnings.
## Notes for reviewers
* **CI will not compile this file.** The build picks one variant or the
other,
and the only in-tree configuration that enables TMP112 at all is
`boards/arm/rp2040/raspberrypi-pico/configs/tmp112`, which does not set
`SENSORS_TMP112_UORB`. So CI keeps building the character mode driver and
never
sees this one; the testing above is the only evidence.
* **Documentation.** Added
`Documentation/components/drivers/special/sensors/tmp112.rst`
and listed the driver among the uORB drivers, following `sht4x` and
`adt7320`.
The character mode driver has never been documented; this does not attempt
to
fix that.
* The `resolution` and `max_range` reported by `get_info` come from the
datasheet
rather than from anything the driver measures, so they describe the part
and not
a particular board's wiring.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
