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>
