The underlying HAL driver may improperly forward an samplerdy event even
if it's disabled in the configuration. Ignore the event to prevent error
logs until the issue is fixed in HAL.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
Avoid integer overflow in temp_sq calculation.
For an analysis of the value ranges for the temp_sq calculation
of mx5837-02 see below:
calculation:
dT = adc_temperature - ((int32_t)(data->t_ref) << 8);
data->temperature = 2000 + (dT * data->tempsens) / (1ll << 23);
temp_sq = (data->temperature - 2000) * (data->temperature - 2000);
given needed storage sizes:
t_ref is uint16_t,
adc_temperature is uint24_t,
data->tempsens is uint16_t,
ranges
=> dT: -16776960 <= dT <= 16777215 (25 bit)
=> data->temperature (TEMP):
intermed.(mult): -1099478073600 <= x <= 1099494785025 (41 bit)
TEMP: 2.000 - 131068 <= TEMP <= 2.000 + 131.069
TEMP: -129068 <= TEMP <= 133069 (17 bit)
So worst case we need 17 bit for TEMP, so the square of it would
overflow an int32_t. The nominal measurement range is
only -40 to 85°C, meaning a range of -4000 to 8500.
So normally the result for temp_seq would fit into a int32_t,
but we cast to be better safe than sorry. Also the 64-bit
multiplication won't be the dominating operation of the
whole calculation.
Fixes#58585
Coverity-CID: 316294
Fixes#58594
Coverity-CID: 316521
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Move LOG_DBG print just after the printed h/w register is read, to avoid
coverity complaining about uninitialized variable.
Fix:
Coverity-CID: 316407 (issue #58591)
Signed-off-by: Armando Visconti <armando.visconti@st.com>
The ISM330DHCX driver immediately segfaults when run in SPI mode. A bad
pointer is being passed into the `dev` param of `ism330dhcx_spi_read`.
Tracing this back, it appears that the handle field of the ctx struct
is being set to the device's data struct while `ism330dhcx_spi_read`
expects `ctx->handle` to be a pointer to a device struct.
Modify `ism330dhcx_spi_init()` to insert the correct pointer into the
context struct. Unfortunately this requires a cast to discard the
`const` qualifier, but this is how it is done in I2C mode (see
`ism330dhcx_i2c_init()`). The only other way would be to change the
declaration of `stmdev_ctx_t`, which is owned by the HAL module.
Signed-off-by: Tristan Honscheid <honscheid@google.com>
Calculate the calibration value at compile for ina23x.
Maximizes the precision of the calcualtion value by
using 64bit math at compile, allows for removal
of rshunt config option.
Code cleaned up with clang-format.
Co-authored-by: Trent Piepho <tpiepho@gmail.com>
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Changes rshunt-milliohms to rshunt-micro-ohms allowing for current
sensing of greater than 16.4A (1mOhm resistor). This is commonly
set to 100 uOhm for VMU/FMU boards/applications.
Co-authored-by: James Goppert <james.goppert@gmail.com>
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Enable automatic temperature measurements during charging.
Allows the PMIC to charge when the host is in low power mode.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
The vbus current limit is now written to the vbus startup
register. It is now applied at all times and does not need
to be updated on charger insertion.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
Update driver with low level power control and OpMode
functions to better represent operations used in power
mode transition diagram Figure 2 from the datasheet.
This also prepares the driver for use of these functions
for PM actions.
Extend the soft reset at initialisation to a full POR.
Add defines for maximum POR time and start up time.
Signed-off-by: Nick Ward <nix.ward@gmail.com>
Shorten lines lengths.
Remove bq274xx prefixes from static function names.
Removes repetition of bq274xx in logging.
Signed-off-by: Oleh Lozynskyy <oleh.lozynskyy@gmail.com>
Local register read/write functions have been removed and replaced
with calls to the new MFD functions.
Signed-off-by: Andy Sinclair <andy.sinclair@nordicsemi.no>
Add driver for TCN75A temperature sensor. The following features are
supported:
- TCN75A oneshot mode, which allows single shot conversions with lower
power consumtion
- Resolution selection, up to 12 bit resolution (9 bit default)
- Triggering based on temperatue thresholds. If the TCN75A exits a set
threshold range, the application can be notified via a callback.
Signed-off-by: Daniel DeGrasse <daniel@degrasse.com>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Fractional part of the conversion was a thousandth of
what it should have been.
Also removes LOG_ERR use which causes excessive output
when logging enabled and using the sensor shell.
Signed-off-by: Nick Ward <nix.ward@gmail.com>
The tachometer collects the data continuously setting a "data ready" bit
when it's ready. The availability bit has to be cleared before the
register is updated.
The driver also supports underflow detection, when the bit indicating it
is set the reading of "0" is returned.
The problem here is that there is that once the underflow bit is cleared
we might end up reading stale data.
To prevent that clear the "data ready" bit when underflow is detected
Signed-off-by: Kornel Dulęba <mindal@semihalf.com>
This is a follow-up to commit 09fa46ee4e.
Before nrfx 3.0, the QDEC interrupt on REPORTRDY event was activated
implicitly when a `reportper` value other than `DISABLED` was used.
Now, the `reportper_inten` field needs to be used to activate this
interrupt.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This PR relocates the sensor trigger sample application from the
`sensor_shell` sample to a subcommand in the actual sensor shell. The
subcommand has a UI for enabling a given trigger on a given sensor.
A built-in handler for the data_ready trigger is included that prints
the latest data to the log. Currently, only `SENSOR_TRIG_DATA_READY` is
supported but the groundwork is there to add others. Tested on a
`tdk_robokit1` board.
Signed-off-by: Tristan Honscheid <honscheid@google.com>
The indended value for the delay after the software reset of adxl372 is
1ms. Adjust the value accordingly.
Fixes: a3e7cea
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Always clearing the interrupt status register was causing issues for
the sensor shell when interrupts were enabled but trying to read
one-off samples.
Signed-off-by: Yuval Peress <peress@google.com>
Update the sensor shell logic to use the new sensor_read() APIs and
make triggers an option of the sensor_shell sample (this avoids the
trigger stealing the interrupt status from one-shot reads).
Signed-off-by: Yuval Peress <peress@google.com>
Add a new async API based on the RTIO subsystem. This new API allows:
1. Users to create sampling configs (telling the sensor which channels
they want to sample together).
2. Sample data in an asynchronous manner which provides greater control
over the data processing priority.
3. Fully backwards compatible API with no driver changes needed for
functionality (they are needed to improve performance).
4. Helper functions for processing loop.
Signed-off-by: Yuval Peress <peress@google.com>
Clean up the include/source lists in the sensors subsystem. Sort the
list, drop the empty lines that makes it look super long for no good
reason, get away with the tabs to align the file names that does not
really work anyway.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add VREF+ sensor driver and DT node definition.
This driver allows determining the actual voltage applied to an SoC's
VREF+ pin, by comparing the VREFINT internal bandgap voltage reference
with its factory calibration data.
In packages where VREF+ is bonded to VDDA, this permits direct measurement
of VDDA voltage.
Signed-off-by: Kenneth J. Miller <ken@miller.ec>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
1. spi.h is included twice. Remove one of the two "#include"
declarations.
2. The 'if' clause requires braces even for one line body.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
The LSM6DSV16X is a system-in-package featuring a 3-axis digital
accelerometer and a 3-axis digital gyroscope for industrial and IoT
solutions. The LSM6DSV16X embeds advanced dedicated features such as
a finite state machine (FSM) for configurable motion tracking and a
machine learning core (MLC) for context awareness.
https://www.st.com/en/mems-and-sensors/lsm6dsv16x.html
This driver is based on stmemsc HAL i/f v2.02
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Bug 1: Fix lsm6dsl_gyro_set_fs_raw does not clear FS125 to register when
setting the full range to be other values.
Bug 2: Fix lsm6dsl_gyro_channel_get does not use the current
gyro_sensitivity when getting data from the gyroscope.
Signed-off-by: Jackie Yang <jackie@jackieyang.me>
LSM6DSL's datasheet [1] lists 1666, 3332 and 6664 as valid ODR values for
accel and gyro. Update those from 1660, 3330 and 6660.
[1] http://www.st.com/en/mems-and-sensors/lsm6dsl.html
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Commit e015c00300 ("sensor: add lsm6dsl sensor driver") that introduced
initial support for lsm6dsl used 245dps instead of 250dps. According to
referenced documentation at [1] the latter is correct.
Use value of 250 instead of 245 for gyro range.
[1] http://www.st.com/en/mems-and-sensors/lsm6dsl.html
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
This instance member is set as part of lsm6dsl_accel_set_odr_raw()
function, so there is no need to do it right before calling it.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
The LSM6DSO16IS is a system-in-package featuring a 3-axis digital
accelerometer and a 3-axis digital gyroscope for industrial and IoT
solutions. The LSM6DSO16IS embeds a new ST category of processing,
ISPU (intelligent sensor processing unit) to support real-time applications
that rely on sensor data. The ISPU is an ultra-low-power, high-performance
programmable core which can execute signal processing and AI algorithms
in the edge.
https://www.st.com/en/mems-and-sensors/lsm6dso16is.html
This driver is based on stmemsc HAL i/f v2.02
Signed-off-by: Armando Visconti <armando.visconti@st.com>
