move sensor.h to drivers/sensor.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
If we include this headers files in cpp source code,
the compiler say"error: template with C linkage".
Includes must be moved outside the 'extern "C"' section.
Signed-off-by: Benoit Leforestier <benoit.leforestier@sekurity.fr>
Its been at least 2 releases since we marked a number of the sensor enum
values as deprecated. Lets remove them.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Any word started with underscore followed by and uppercase letter or a
second underscore is a reserved word according with C99.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Some device include a temperature sensor, usually used as a
companion for helping in drift compensation, that measure the
die temperature. This temperature IS NOT related to the the
ambient temperature, hence a clean separation between the two
is required.
This commit introduces a clean separation between the two
types of temperature leaving the old deprecated definition
still there.
The list of current drivers that read the die (and not the ambient)
temperature is the following:
- adxl362
- bma280
- bmg160
- bmi160
- fxos8700
- lis3mdl
- lsm6ds0
- lsm6dsl
- lsm9ds0
- mpu6050
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Explicitly show representation peculiarities of the negative values.
Additionally mention that fractional part is in one-millionth parts.
Fixes: #5692
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
CCS811 digital gas sensor supports the following channels:
1. Co2 Channel
2. VOC Channel
3. Voltage Channel
4. Current Channel
Add support for the those in API.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Most of sensor channels defined by Zephyr use the main, unscaled
SI unit. We also have SENSOR_CHAN_ALTITUDE which is defined in
meters. So, it only makes sense to define distance in meters too
The only driver supporting SENSOR_CHAN_DISTANCE as of now is
vl53l0x.c, which was updated accordingly. Also, update doc links
in the driver based on the review comment.
Fixes: #5693
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Based on the discussion in #5693, the reason why humidity was defined
in milli-percent was likely following Linux which defines it as such
in its sensor subsystem:
http://elixir.free-electrons.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-iio#L263
However, Linux defines temperature in milli-degrees either, but
Zephyr uses degrees (similarly for most other quantities). Typical
sensor resolution/precision for humidity is also on the order of 1%.
One of the existing drivers, th02.c, already returned values in
percents, and few apps showed it without conversion and/or units,
leading to confusing output to user like "54500".
So, switching units to percents, and update all the drivers and
sample apps.
For few drivers, there was also optimized conversion arithmetics
to avoid u64_t operations. (There're probably more places to
optimize it, and temperature conversion could use such optimization
too, but that's left for another patch.)
Fixes: #5693
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Add a distance channel in the sensor interface to be used with
time Of flight sensors (vl53l0X for example).This will indicate
the distance from the sensor to the target, in millimeters.
Signed-off-by: Vincent Veron <vincent.veron@st.com>
This commit adds new sensor channel macro SENSOR_CHAN_BLUE which can
be used for RGB sensors to get illuminance in Blue spectrum.
Signed-off-by: Punit Vara <punit.vara@intel.com>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types. This handles the remaining includes and kernel, plus
touching up various points that we skipped because of include
dependancies. We also convert the PRI printf formatters in the arch
code over to normal formatters.
Jira: ZEP-2051
Change-Id: Iecbb12601a3ee4ea936fd7ddea37788a645b08b0
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The max30101 heart rate sensor supports three types of LED channels:
red, infrared, and green. The sensor interface previously defined only a
generic "light" channel and an infrared channel, so add more specialized
red and green channels to the interface.
Jira: ZEP-720
Change-Id: I5f457c335d84cdadde71927a6eb19def3181d32a
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Add SENSOR_CHAN_*_XYZ enum values to be used instead of
SENSOR_CHAN_*_ANY, because the new naming takes into account that
they are used to fetch all the 3 axes for a channel (X, Y and Z)
and not just any number of them.
Also deprecate old SENSOR_CHAN_*_ANY enum values.
Change-Id: I59e9901c1f8879d084bdb7c95583c2b28aa1e025
Signed-off-by: Bogdan Davidoaia <bogdan.davidoaia@linaro.org>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Remove the type field from the sensor value structure. All values will
have the type previously defined by SENSOR_VALUE_TYPE_INT_PLUS_MICRO.
This simplifies the interface, as apps will know what value type to
expect. Apps that prefer to use double values can optain them using the
sensor_value_to_double function.
Change-Id: I3588d74258030eb16c3f89d8eead13cca4606b18
Signed-off-by: Bogdan Davidoaia <bogdan.davidoaia@linaro.org>
Various sensor samples are hardwired to expect returned sensor values
are represented as doubles. In each case this assumption is incorrect.
Introduce a generic sensor_value to double helper function and adjust
the samples to use it.
Change-Id: I89c788686576562b84e07a36064640231340c33b
Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com>
Introduce tap and double tap triggers to the sensor interface.
Change-Id: Ic91d73e4393d643abc4119850d5b02164b1b6843
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Remove SENSOR_VALUE_TYPE_INT as it is the same as
SENSOR_VALUE_TYPE_INT_PLUS_MICRO with val2 set to 0.
Change-Id: If5a9c579b7267701c27f40fd887acae47d64edc5
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
Remove SENSOR_VALUE_TYPE_Q16_16 as it is not used by any driver. Future
drivers can use any of the remaining value types.
Change-Id: I984143cc65d6a6fd0477f310ac17c62498cc05b8
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
A workaround used to silence a warning in the doc generation process
which involved tagging a structure with a #define can now be solved
with a cleaner approach which is non-code-invasive.
Backup said change and update documentation on what to do when the
issue is found.
Change-Id: I1ef5224cd1b2df2e57c2ace438dba90ba3fc8528
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Added missing (placeholder) comment on struct sensor_trigger_config
Removed @ref references to undefined terms
Fixed a misspelling while I was there too.
Jira: ZEP-487
Change-Id: I314f243cbd58cab48da33abd2f181b9aeb17b0e9
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Fixed group end and undefined refs.
Change-Id: Iad0ab7b0dd858955d95f298a772d8d84bb4ee1c9
Signed-off-by: Javier B Perez <javier.b.perez.hernandez@intel.com>
Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:
* device drivers will use SENSOR_DECLARE_* macros in their device
configuration structures and SENSOR_GET_* macros in the init
functions;
* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.
Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Fix with a workaround in unnamed unions / structs in bluetooth, i2c,
sensor and uart.
Current documentation parsers (sphinx under Doxygen) don't seem to
understand well unnamed structs / unions. They will not generate any
documentation for any documented members (see left side of
http://imgur.com/mcpBXWc).
A workaround is to make the parser think there is something like a
struct/union/enum name that is actually something with no effect to
the compiler.
Naming it with __unnamed_workaround__ ensures it is clear it is a
workaround while we wait for a final fix. It is #defined to be a NO-OP
to the compiler and rearrange the member documentation as *@param* so
we have some documentation that the non-worked around code fails to
document.
Anonymous structs/union that declare a variable are just given an
internal name.
Workarounds documented in the contribution guidelines.
Change-Id: I4d32cf444f3c5e7d2fb11581e4b41f80e93c9786
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Some function *typedefs* confuse the *Sphynx* / *breathe* parser [see
the patch for full details]. Implement a workaround (defining the name
with @typedef), add workaround documentation and file a bug with the
sphinx/breathe developers.
Change-Id: I7f3dba4a53d0cc73e12f02511a5f85526f357b5f
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Update all drivers that have vectorial data to return all 3 channels (X,
Y and Z) if the chan parameter is _ANY.
Also fix a compile bug in LSM9DS0 MFD driver.
Change-Id: I5bf261846bcd68c288b96997ff164726f75c151c
Signed-off-by: Murtaza Alexandru <alexandru.murtaza@intel.com>
This accidentally snuck by between iterations of the workqueue patches.
In v1 there was a sensor-specific workqueue, which we then turned into a
global one.
Change-Id: I10b193bb535602a16f6742d057281ba01906228d
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Remove the homegrown sensor delayed work API in favor of using the
system-wide workqueue. Drivers still have the option of using their own
fiber.
In a second step, drivers can be refactored to start and use their own
workqueue.
Change-Id: I70dea6fc2abcbc9e04ac1ed3c837483a3d3c4424
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Rename sensor_value_type enums from SENSOR_TYPE_* to more concludent
name SENSOR_VALUE_TYPE_*. This change is required if we want to
introduce SENSOR_TYPE_* (SENSOR_TYPE_ACCEL - if the sensor/driver
supports accelerometer, SENSOR_TYPE_MAGN - etc.) in the future.
Also it is more clear with this notation what these enums are referring
to.
Change-Id: Ic58e29288669e10c0695e0f86f59b0e57f7ac38c
Signed-off-by: Murtaza Alexandru <alexandru.murtaza@intel.com>
Now you can specify the sensor type you want to fetch using
sensor_sample_fetch_chan. This will inform the driver that you want only
one type of data updated, leaving the others unchanged and enabling
different sampling rates for multi function devices (MFDs).
Change-Id: I403e422dffadc697c19a5372ed55ed8f486a2607
Signed-off-by: Murtaza Alexandru <alexandru.murtaza@intel.com>
Since sensors' API uses SI units, all attributes and channel reading use
SI units. Hence, conversions from other units to SI are necessary.
This patch adds helper for converting:
* m/s^2 to Gs (and vice versa);
* degrees to radians (and vice versa);
Change-Id: I49f8763bed253ff6bde4c97618766b05f97da699
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
