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.
Add 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; the new one replaces it when
SENSORS_TMP112_UORB is set, and the part then appears as a temperature
topic that the common sensor tools can read without knowing what a
TMP112 is.
It reads on the low priority work queue at whatever interval the caller
asks for. The part converts continuously out of reset, so nothing is
configured and the temperature register always holds the last completed
conversion: a reading is one bus transaction with nothing to wait for.
Reading faster than the part converts repeats a value, which costs bus
traffic and nothing else, so the interval is taken as given: the upper
half treats a lower half that hands back a longer interval than it was
given as a failed request, so clamping here would refuse a fast caller
rather than serve it slowly.
get_info reports what the part is and what its readings mean, so a
consumer need not know it is talking to a TMP112 to know the range and
the resolution.
It also sign extends the reading. The register holds twelve bits, and
the character mode driver treats them as unsigned, so anything below
freezing comes back as a large positive temperature; the part is
specified down to -40C. Fixing that in the old driver would change what
existing callers see, so it is fixed here, where there are no callers
yet to surprise.
This driver also covers the TMP102, which differs in accuracy rather
than in its registers: only the two both parts have are touched.
Documented under the sensors section, beside the other parts with a page
of their own, and listed among the uORB drivers.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A fetch() only lower half is always ready, so a subscriber that asked for
a rate with SNIOC_SET_INTERVAL got no pacing from poll(): the descriptor
reported POLLIN on every pass and the application had to sleep out the
period itself. That does not compose. An application polling several
topics reads them sequentially from one thread, so per read sleeps
serialize: three topics at 10 Hz sleeping 100 ms each yield 3.3 Hz per
topic rather than 10.
Pace it where poll() can act on it instead. A subscriber that never
requested a rate stays always ready, and one that did becomes ready once
per its own interval, driven by a watchdog armed in sensor_poll(). This
is the fetch() side of what sensor_is_updated() already does for a
pushing lower half, so both models now honor a requested rate the same
way.
The wdog_s lives in sensor_user_s rather than in the device, so each
subscriber is paced at its own interval instead of at the minimum across
all of them, and the timer only runs while somebody is polling. The
expiry runs in timer context and takes no lock: poll_notify() is safe
from an interrupt handler, and a teardown that raced it has already
cleared fds, which makes both the notify and the re-arm no-ops. Teardown
therefore just cancels the watchdog where it clears fds, and a watchdog
keeps this off the work queue entirely, which a fetch() only sensor
exists to avoid.
sensor_close() needs nothing of its own: poll_setup() holds a reference
on the file for the duration of the poll, so file_close() cannot run
until poll_teardown() has called sensor_poll() with setup false, and that
already cancelled the watchdog.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
A fetch() only lower half reads the device on demand, so its data is
always available and there is never anything to wait for. The upper half
did not reflect that: poll() only reported POLLIN when the descriptor was
opened O_NONBLOCK, and a blocking read() waited on buffersem, which is
only posted when the lower half drives notify_event from an interrupt of
its own.
A fetch() only sensor with no interrupt therefore never satisfied
poll()/read() at all. This is not hypothetical: in the in tree
nucleo-h563zi:dts configuration CONFIG_STM32_DTS_TRIGGER defaults to 0,
which selects stm32_dts_fetch(), and no CONFIG_STM32_DTS_ITEN_* option is
enabled, so the DTS interrupt never fires. A blocking read() on that
sensor waits forever, even though stm32_dts_fetch() performs a complete
software triggered measurement on its own and needs no interrupt at all.
Applications had to work around this by forcing O_NONBLOCK on the
descriptor themselves, see apache/nuttx-apps#3686.
Drop the O_NONBLOCK special case in both paths: sensor_poll() now always
reports POLLIN for a fetch only sensor and sensor_read() calls fetch()
directly instead of waiting. Update the sensor_ops_s::fetch
documentation, which described the old contract.
With the wait gone, buffersem has no waiters left. Its only two readers
were the ones removed here, both in the fetch path: the wait in
sensor_read() and the nxsem_get_value() in sensor_poll(). The remaining
nxsem_post() calls in sensor_push_event() and sensor_notify_event() had
nothing left to wake, so drop the semaphore and those posts as well.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The driver had two modes selected by CONFIG_SENSORS_L3GD20_BUFFER_SIZE:
with a buffer it pushed samples from a work queue, and without one it
exposed fetch() while still using the data ready interrupt to signal
readiness through notify_event.
That second mode misuses the fetch interface. fetch() means the data is
read from the device on demand and is therefore always available, while
an interrupt driven sensor is exactly what push_event is for. Mixing the
two forces the upper half to guess whether a fetch() only lower half
will ever notify, and it makes poll() unusable in a multi descriptor
loop, because the descriptor reports ready while the read still has to
wait for the next interrupt.
Drop the fetch path and always use the work queue and push_event, which
is what the driver already did by default since BUFFER_SIZE defaults to
1. CONFIG_SENSORS_L3GD20_BUFFER_SIZE gains a range of 1 to 32, as a zero
sized buffer no longer has a meaning, and SCHED_HPWORK is now selected
unconditionally because the work queue is always used.
No in tree configuration enables this driver and the previous default
already took the push path, so no defconfig changes are needed.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
fetch() timestamps a sample when the application asks for it, not when
the device measured it, and reads accel and gyro separately so the two
topics never share an instant. Add an optional push mode behind
CONFIG_SENSORS_MPU6050_INT: the board supplies mpu6050_config_s::attach,
the handler timestamps and defers to HPWORK, and the worker reads once
and pushes both topics. The I2C read cannot run in the interrupt.
The mode is chosen at build time, so fetch() is simply left out of the
ops table and out of the build when the option is set: an instance uses
one model or the other, never the mixture that made poll() unusable on
l3gd20. A board that enables it without attach fails with -EINVAL.
Also set CONFIG so the DLPF is on. Left at reset the gyroscope output is
8 kHz, not 1 kHz, so SMPLRT_DIV 9 gave 800 Hz rather than the documented
100 Hz; measured 833 Hz before and 101 Hz after. fetch() hid this since
the application set the pace.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Summary
Permissions (Part 3)
Description:
In kernel builds, any unprivileged process running on the NuttX device can
open /dev/efuse and attempt to read/write fuse content. Reading the fuses
may provide valuable information to an attacker controlling the user process.
The write operation, in extreme cases where the fuse blocks are not locked,
may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
Impact
See https://github.com/apache/nuttx/issues/19410
Testing
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Add lower-half uORB sensor driver for the InvenSense MPU6050 over I2C. Supports accelerometer and gyroscope sensor types, register read/write, fetch, and control operations.
All internal register definitions and full-scale range constants are placed in the private driver C file (drivers/sensors/mpu6050_uorb.c) for clean encapsulation. The device struct uses explicit named members ('accel' and 'gyro') for high readability.
Add Kconfig option CONFIG_SENSORS_MPU6050 under Sensor Drivers, and add build integration to drivers/sensors/Make.defs and CMakeLists.txt.
Signed-off-by: Shriyans S Sahoo <shriyans.s.sahoo@gmail.com>
Align the NuttX open(2) flag constants with the Linux asm-generic
values so that the FUSE wire protocol and other cross-platform
interfaces work without conversion.
All code that used '(flags & O_RDONLY)' as a bitmask check (always 0
now that O_RDONLY=0) has been updated to use '(flags & O_ACCMODE)'
comparisons.
The NUTTX_O_* constants in include/nuttx/fs/hostfs.h are updated to
match, and the sim hostfs open flag mapping is fixed.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
O_RDOK and O_WROK are non-standard aliases for O_RDONLY and O_WRONLY
respectively. Having two names for the same flag creates confusion,
especially when aligning the flag values with Linux. Remove the
aliases and replace all uses with the standard O_RDONLY/O_WRONLY.
No functional change — O_RDOK was defined as O_RDONLY and O_WROK as
O_WRONLY, so the replacement is a pure text substitution.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Previously bme680 dont register temperature topic when pressure measurement
was enabled. Temperature data is present in barometer data, but sometimes
we need clear separation between these topics.
The old behavior is still achievable by setting CONFIG_BME680_DISABLE_TEMP_MEAS=y
Signed-off-by: raiden00pl <raiden00@railab.me>
BREAKING CHANGE: bme680_register() takes an additional "*config" argument.
When config is NULL - driver behavior is the same as before.
With this change bme680 can be configured during registration in board logic.
This way we don't have to callibrate sensor from user-space but sensor is ready
to use after registration.
This change makes the registration the same as for bme688, which is a similar
sensor.
Signed-off-by: raiden00pl <raiden00@railab.me>
Now that time_t is unconditionally 64-bit (signed int64_t) and the
struct timespec fields tv_sec / tv_nsec are wide enough on their own,
the explicit (uint64_t)/(int64_t)/(int) casts that used to guard the
multiplications and subtractions in *_us / *_ms / *_ns helpers are no
longer needed. Drop them to keep the timekeeping math readable and
consistent with the previous sclock_t/time_t cleanup.
In the same spirit, this commit also:
* Normalises the printf-style format specifiers and casts used to
print tv_sec / tv_nsec / tv_usec values across arch/, drivers/,
fs/, sched/ and libs/. The prior code was a mix of
"%d"/"%u"/"%ld"/"%lu"/"%lld"/PRIu32/PRIu64 with matching
(int)/(unsigned long)/(long long)/PRIu* casts; some formats
truncated time_t on 32-bit hosts, others mismatched signedness or
width. Replace all such cases with the portable POSIX-recommended
forms:
- tv_sec (time_t, signed, impl-defined width) -> %jd + (intmax_t)
- tv_nsec (long, signed) -> %ld (no cast)
- tv_usec (suseconds_t / long) -> %ld (no cast)
Add #include <stdint.h> where required.
* Drops a few stale `(FAR const time_t *)&ts.tv_sec` casts and
related `(FAR struct tm *)` / `(const time_t *)` casts in
gmtime_r() / localtime_r() / gmtime() callers; ts.tv_sec is plain
time_t now and the casts only obscured the type.
* Fixes one overflow in fs/procfs/fs_procfscritmon.c where
all_time.tv_sec * 1000000 could overflow on 32-bit time_t before
being multiplied again; cast to uint64_t at the start.
No behavioural change.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
This sensor was not present in the Make.defs file
AMG88xx Infrared Array Sensor
https://github.com/apache/nuttx/pull/12829
Moved:
These drivers can be used with sensor connected over SPI or I2C bus
Bosch Sensortec BMI160
Bosch Sensortec BMI088
Signed-off-by: simbit18 <simbit18@gmail.com>
Move the #endif preprocessor guard to after bmi160_transferspi()
so that both bmi160_configspi() and bmi160_transferspi() are
properly enclosed within the SPI conditional compilation block.
Signed-off-by: likun17 <likun17@xiaomi.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
This commit implements a compile-time warning and in-code comment
warning for legacy sensor drivers. This is intended to:
- Warn users that legacy drivers may eventually be removed
- Warn developers that they should not use a legacy driver as a
reference for their new driver contributions
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
When all signals are disabled, nxsig_notification is not available and
should not be invoked. Remove the call to avoid build and runtime issues
in no-signal configurations.
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
Add sensor monitor logs to analyze issues related to driver activation.
This commit adds comprehensive sensor monitoring logs to the GNSS uORB driver
to facilitate debugging and analysis of driver activation issues.
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
The dhtxx driver previously returned 0 on success, which violates standard
character device behavior where the number of bytes read should be returned.
It also used non-standard error codes like -1 or -ENOSYS for operational
errors.
This commit fixes the following behavior to comply with POSIX standards:
* Return sizeof(struct dhtxx_sensor_data_s) on success instead of 0.
* Return -EINVAL instead of -ENOSYS/-1 for invalid buffer arguments.
* Return -ETIMEDOUT instead of -1 for sensor timeouts.
* Return -EIO instead of -1 for checksum or parsing errors.
Signed-off-by: jklincn <jklincn@foxmail.com>
when remote core connect.
using worker instead of rptun thread to broadcast advertisement
message because the rptun thread can't process rx message when it
calls the ns_bound function.
And the advertisement message to remote core will generate many
the advertisement ack message from remote core, these advertisement
ack messages can't be processed at times by rptun thread.
This can cause rptun thread to block when the number of advertisement
message exceeds the number of ipc buffers between local core and
remote core.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
support set_nonwakeup ops for sensor driver to save power
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Signed-off-by: likun17 <likun17@xiaomi.com>
flush fixes the problem of not being able to get the lock.
call trace:
A thread: rptun thread:
lock upper_lock
lock upper_lock
rpmsg send -> wait upper_lock
unlock upper_lock
wait response <--\-- don't reponse this rpmsg request
unlock upper_lock
Signed-off-by: likun17 <likun17@xiaomi.com>
since creating resources on the remote core takes time,
we need to wait for the remote core to return ack.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
of driver information.
When the local core is a virtual sensor, attempt to retrieve
information from a remote core.
Signed-off-by: likun17 <likun17@xiaomi.com>
