sensor: sensing: unified api #64478

lixuzha · 2023-10-27T08:08:10Z

Implement the sensing subsystem.

This includes the following features:

Unified API - Use sensor_driver_api instead of sensing_sensor_api to fix Duplicates APIs issue raised in RFC: Architecting a sensor subsystem #62223
Implement the sensing subsystem base on unified API.
Implement phy_3d_sensor driver as the reference code of physical sensor.
Implement hinge_angle driver as the reference code of virtual sensor.

The sensing subsystem working process is as below.

    sequenceDiagram
    title Sensing runtime process

    participant Sensing as Sensing Subsys
    participant Sensing_dispatch as Sensing Dispatch Thread
    participant phy_3d_sensor
    participant hinge_angle_sensor
    participant Application

    Application-->>Sensing: call sensing_open_sensor to get hinge_angle_sensor's handle<br>and registe sensing_callback_list
    activate Application
    Application-->>Sensing: call sensing_set_config to set hinge_angle_sensor's sampling freq.
    activate hinge_angle_sensor
    Sensing-->>hinge_angle_sensor: call .attr_set to set sampling freq.
    hinge_angle_sensor-->>Sensing: call sensing_set_config to config its reporters.
    Sensing-->>phy_3d_sensor: call .attr_set to set sampling freq.
    deactivate hinge_angle_sensor
    deactivate Application

    rect rgb(191, 223, 255)
    loop
        Sensing-->>hinge_angle_sensor: Call its .submit callback to submit SQE periodically.
        Sensing-->>phy_3d_sensor: Call its .submit callback  to submit SQE periodically.
        phy_3d_sensor-->>Sensing_dispatch: Produce the CQE.
        Sensing_dispatch-->>hinge_angle_sensor: Consume CQE produced by phy_3d_sensor<br>and dispatch data to it's clients by calling sensing_callback_list.on_data_event()
        hinge_angle_sensor-->>Sensing_dispatch: Produce the CQE.
        Sensing_dispatch-->>Application: Consume CQE produced by hinge_angle_sensor<br>and dispatch data to it's clients by calling sensing_callback_list.on_data_event()
    end
    end

Depends: #60063

Links

Presentation sensing_unify_api_proposal.pdf

teburd

I really like that we're not adding a new API, that it appears to mostly avoid copying the data around, and that there is a simple callback list involved.

I like that even algorithms are effectively using a pull then push model. As I read the code a read submission comes in from the sensor subsystem and upon completion data is broadcast to the callback list. The read for algorithms is completed once enough callbacks (on data event) occur and the algorithm runs. This feels and looks pretty nice to me.

I think many things here could use with some more code comments and documentation explaining how things are working, but to me this looks like its on the right track.

I think more broadly though that each sensing_sensor needs to connect a sensor to multiple lists of callbacks rather than a single list of callbacks. The assumption that I believe should be made here is that a sensor or algorithm may be a source of multiple data streams (e.g. the muxed FIFO issue noted in #60063) and that for each channel (accel xyz could be a channel) a set of callbacks are associated.

I could very well be wrong on that but I guess that's how I'd expect things to work in some way or another.

teburd · 2023-11-01T22:23:48Z

subsys/sensing/dispatch.c

+	while (true) {
+		struct rtio_cqe cqe;
+
+		rc = rtio_cqe_copy_out(&sensing_rtio_ctx, &cqe, 1, K_FOREVER);


This is a nice usage of the user space abilities here

teburd · 2023-11-01T22:27:28Z

subsys/sensing/sensor_mgmt.h

+
+static inline uint64_t get_us(void)
+{
+	return k_ticks_to_us_floor64(k_uptime_ticks());


Ticks are likely going to represent in the most common case millisecond levels of precision. So I'm skeptical that this get_us(void) function will be able to do what we need it to.

Likely what we want is k_cycle_get_64() and converting the cycle count to microseconds. Or perhaps doing some math to get the cycles since the last tick (maybe we need this functionality) so that sub-tick timing precision without rollovers can be obtained. This would be useful for sensor drivers as well I believe as they need a way to precisely timestamp the data.

Agreed, I'm OK with timing for now just moving forward with more of a "whatever" until #63651 is resolved. I think we're likely to land on cycles like @teburd said.

teburd · 2023-11-01T22:28:08Z

subsys/sensing/dispatch.c

+		 * true: it's time for client consuming the data
+		 * false: client time not arrived yet, not consume the data
+		 */
+		if (!sensor_test_consume_time(sensor, conn, get_us())) {


This seems like it would drop data if the consumer is not yet expecting it based on get_us(). I'd note that ticks are imprecise and this could fail to pass the branch in cases that we might otherwise expect. I'd also note that this is going to decimate data without filtering and this was a concern given in the architecture wg. I don't have a strong opinion on the filtering aspect, but we should definitely ensure the timing precision is good so this sort of branching occurs when we want it to.

I think we discussed this in the AWG before we created the sensor WG. We shouldn't do any filtering in the subsystem. It's better to present the client with ALL the data that's available and let them choose a decimation strategy.

teburd · 2023-11-01T22:29:09Z

subsys/sensing/dispatch.c

+					conn->source->dev->name);
+			continue;
+		}
+		conn->callback_list.on_data_event(conn, data,


I really like that we do not need to copy data as the callbacks are happening

teburd · 2023-11-01T22:36:21Z

subsys/sensing/sensor/hinge_angle/hinge_angle.c

+{
+	struct hinge_angle_context *data = dev->data;
+
+	if (data->sqe) {


This is an interesting idea though I'm not sure I follow entirely the thinking. In this case submit() is expecting to set the current submission the hinge angle algorithm works on. It can do this because there's the knowledge that only the sensor dispatch thread is going to be submitting presumably. So only one read request is ever going to be around I suppose.

I'd rather see this work like everything else and push/pop from a queue. In moving away from submit starting work as it does today I have #62605. In this case submit would push to the queue, the current sqe to fulfill would be setup in a poll call in that case, and only done if in submit it is needed.

e.g.

this would look more like..

/* All request producers call submit */ static void hinge_submit(const struct device *dev, struct rtio_iodev_sqe *sqe) { ... rtio_mpsc_push(iodev->sq, sqe); if (!atomic_ptr_get(data->sqe)) { rtio_add_pollable(sqe->r, iodev); } } /* Request consumer (the iodev) does its work in poll */ static void hinge_poll(struct const device *dev) { ... data->sqe = rtio_mpsc_pop(iodev->sq); /* Do work here if possible */ }

teburd · 2023-11-01T22:55:18Z

subsys/sensing/sensor/hinge_angle/hinge_angle.c

+	return ret;
+}
+
+static int hinge_submit(const struct device *dev,


This is an infallible call and should be void hinge_submit(const struct device *dev, struct rtio_iodev_sqe *sqe);

hinge_submit is an instance of typedef int (*sensor_submit_t)(const struct device *sensor, struct rtio_iodev_sqe *sqe), so it should be int.

Some cleanup needs to be done around this API it seems, thanks for pointing this out

KeHIntel · 2023-11-02T02:05:54Z

I think more broadly though that each sensing_sensor needs to connect a sensor to multiple lists of callbacks rather than a single list of callbacks. The assumption that I believe should be made here is that a sensor or algorithm may be a source of multiple data streams (e.g. the muxed FIFO issue noted in #60063) and that for each channel (accel xyz could be a channel) a set of callbacks are associated.

Thanks for the review, on above requirement, we have a little different concept. In our view, the sensors in sensing subsystem should be a standard part instead of multi-function tools. A standard part means that it has standard input/output defined, no matter it is built by whom. A standard part can help people easily assembly them together into a sensor tree and create a functional sensing subsystem, like playing LEGO blocks.

So for the case that one sensor may be a source of multiple data streams, the preference is to split it into multiple standard sensors, each to serve one type of usages.

lixuzha · 2023-11-02T02:13:09Z

I really like that we're not adding a new API, that it appears to mostly avoid copying the data around, and that there is a simple callback list involved.

Thanks for your comments. I'll update it later.

yperess

Please rebase, streaming APIs landed.

yperess · 2023-11-13T04:06:58Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

+	int64_t scaled_value;
+	int64_t shifted_value;
+
+	shifted_value = (int64_t)q << shift;


You need to be careful with this it caught me off guard a few times, if shift is negative this will not work as expected. you need to left shift on positive and right shift by the absolute value on negative.

Thanks for your reminder. This function can be removed after using sensor_read and decoder instead of fetch/get

yperess · 2023-11-13T04:13:09Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

+	ret = sensor_sample_fetch_chan(cfg->hw_dev, data->custom->chan_all);
+	if (ret) {
+		LOG_ERR("%s: sample fetch failed: %d", dev->name, ret);
+		rtio_iodev_sqe_err(sqe, ret);
+		return ret;
+	}
+
+	ret = sensor_channel_get(cfg->hw_dev, data->custom->chan_all, value);


We shouldn't be using fetch/get anymore

Agreed. Would update later.

yperess · 2023-11-13T04:18:01Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

+	static struct phy_3d_sensor_data _CONCAT(data, _inst);		\
+	static const struct phy_3d_sensor_config _CONCAT(cfg, _inst) = {\
 		.hw_dev = DEVICE_DT_GET(				\
 				DT_PHANDLE(DT_DRV_INST(_inst),		\
 				underlying_device)),			\
 		.sensor_type = DT_PROP(DT_DRV_INST(_inst), sensor_type),\
 	};								\
-	SENSING_SENSOR_DT_DEFINE(DT_DRV_INST(_inst),			\
-		&phy_3d_sensor_reg, &_CONCAT(ctx, _inst),		\
+	SENSING_SENSOR_DT_INST_DEFINE(_inst, &phy_3d_sensor_reg, NULL,	\
+		&phy_3d_sensor_init, NULL,				\
+		&_CONCAT(data, _inst), &_CONCAT(cfg, _inst),		\
+		POST_KERNEL, CONFIG_SENSOR_INIT_PRIORITY,		\


This is a critical nuance, the physical sensors should for example when using the ICM42688 create:

sensor device (const struct device)

3 separate const struct sensing_sensor_info objects for ACCEL, GYRO, and DIE_TEMPERATURE.

The current model creates a separate device for each data type

Yes, I'll fix it.

I would like to do the following change:

Change the type of sensor-type from int to array

# Copyright (c) 2023, Intel Corporation # SPDX-License-Identifier: Apache-2.0 # description: Sensing subsystem sensor common properties bindings. include: sensor-device.yaml properties: --- sensor-type: +++ sensor-types: --- type: int +++ type: array required: true description: sensor type id (follow HID spec definition)

In SENSING_SENSOR_DEFINE, it will create multiple instances of sensing_sensor by enumerating sensor-types.

I think there's a key distinction here, you need 1 sensor but multiple sensor_info nodes. Please see my sample PR at #56963

I updated the PR, and add the commit sensing: support multiple sensor types in one device
In this commit, the single bmi160 device would create two sensing_sensor instances for Accel and Gyro.

nashif · 2023-11-13T15:26:17Z

there is an issue with llvm:

zephyr/subsys/sensing/CMakeFiles/subsys__sensing.dir/sensor/hinge_angle/hinge_angle.c.obj -c /__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c
/__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c:167:29: error: initializer element is not a compile-time constant
DT_INST_FOREACH_STATUS_OKAY(SENSING_HINGE_ANGLE_DT_DEFINE);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/include/zephyr/devicetree.h:4153:25: note: expanded from macro 'DT_INST_FOREACH_STATUS_OKAY'
                              DT_DRV_COMPAT)(fn)),              \
                              ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/twister-out/native_posix/samples/subsys/sensing/simple/sample.subsys.sensing.simple/zephyr/include/generated/devicetree_generated.h:3862:61: note: expanded from macro 'DT_FOREACH_OKAY_INST_zephyr_sensing_hinge_angle'
#define DT_FOREACH_OKAY_INST_zephyr_sensing_hinge_angle(fn) fn(0)
                                                            ^
/__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c:160:2: note: expanded from macro 'SENSING_HINGE_ANGLE_DT_DEFINE'
        SENSING_SENSOR_DT_INST_DEFINE(_inst, &hinge_reg,                        \
        ^
note: (skipping 11 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:64:39: note: expanded from macro '__COND_CODE'
        __GET_ARG2_DEBRACKET(one_or_two_args _if_code, _else_code)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:69:65: note: expanded from macro '__GET_ARG2_DEBRACKET'
#define __GET_ARG2_DEBRACKET(ignore_this, val, ...) __DEBRACKET val
                                                    ~~~~~~~~~~~~^~~
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:72:26: note: expanded from macro '__DEBRACKET'
#define __DEBRACKET(...) __VA_ARGS__
                         ^~~~~~~~~~~
1 error generated.

lixuzha · 2023-11-27T08:18:50Z

there is an issue with llvm:

zephyr/subsys/sensing/CMakeFiles/subsys__sensing.dir/sensor/hinge_angle/hinge_angle.c.obj -c /__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c
/__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c:167:29: error: initializer element is not a compile-time constant
DT_INST_FOREACH_STATUS_OKAY(SENSING_HINGE_ANGLE_DT_DEFINE);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/include/zephyr/devicetree.h:4153:25: note: expanded from macro 'DT_INST_FOREACH_STATUS_OKAY'
                              DT_DRV_COMPAT)(fn)),              \
                              ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/twister-out/native_posix/samples/subsys/sensing/simple/sample.subsys.sensing.simple/zephyr/include/generated/devicetree_generated.h:3862:61: note: expanded from macro 'DT_FOREACH_OKAY_INST_zephyr_sensing_hinge_angle'
#define DT_FOREACH_OKAY_INST_zephyr_sensing_hinge_angle(fn) fn(0)
                                                            ^
/__w/zephyr/zephyr/subsys/sensing/sensor/hinge_angle/hinge_angle.c:160:2: note: expanded from macro 'SENSING_HINGE_ANGLE_DT_DEFINE'
        SENSING_SENSOR_DT_INST_DEFINE(_inst, &hinge_reg,                        \
        ^
note: (skipping 11 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:64:39: note: expanded from macro '__COND_CODE'
        __GET_ARG2_DEBRACKET(one_or_two_args _if_code, _else_code)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:69:65: note: expanded from macro '__GET_ARG2_DEBRACKET'
#define __GET_ARG2_DEBRACKET(ignore_this, val, ...) __DEBRACKET val
                                                    ~~~~~~~~~~~~^~~
/__w/zephyr/zephyr/include/zephyr/sys/util_internal.h:72:26: note: expanded from macro '__DEBRACKET'
#define __DEBRACKET(...) __VA_ARGS__
                         ^~~~~~~~~~~
1 error generated.

I'll check it, thanks.

yperess · 2023-12-07T17:12:02Z

subsys/sensing/dispatch.c

+		 * true: it's time for client consuming the data
+		 * false: client time not arrived yet, not consume the data
+		 */
+		if (!sensor_test_consume_time(sensor, conn, get_us())) {


I think we discussed this in the AWG before we created the sensor WG. We shouldn't do any filtering in the subsystem. It's better to present the client with ALL the data that's available and let them choose a decimation strategy.

yperess · 2023-12-07T17:17:26Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

+static const struct phy_3d_sensor_custom custom_accel = {
+	.chan_all = SENSOR_CHAN_ACCEL_XYZ,
+	.shift = SENSING_ACCEL_Q31_SHIFT,
+	.q31_to_sensor_value = accel_q31_to_sensor_value,
+	.sensor_value_to_q31 = accel_sensor_value_to_q31,
+};


This seems like we're still making the phy_3d_sensor an either/or. In the case of the BMI160 you'll need to support both accel and gyro here.

yperess · 2023-12-07T17:21:32Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

+	switch (cfg->sensor_type) {
+	case SENSING_SENSOR_TYPE_MOTION_ACCELEROMETER_3D:
+		data->custom = &custom_accel;
+		break;
+	case SENSING_SENSOR_TYPE_MOTION_GYROMETER_3D:
+		data->custom = &custom_gyro;
+		break;


From what I can tell this is still the same as my previous comments. You're creating 1 struct device per type. You need to have 1 struct device per physical sensor and N struct sensor_info objects based on the number of types that are supported.

yperess · 2023-12-07T17:24:40Z

subsys/sensing/sensor/phy_3d_sensor/phy_3d_sensor.c

 		.hw_dev = DEVICE_DT_GET(				\
 				DT_PHANDLE(DT_DRV_INST(_inst),		\
 				underlying_device)),			\
-		.sensor_type = DT_PROP(DT_DRV_INST(_inst), sensor_type),\
+		.sensor_type = DT_PROP_BY_IDX(DT_DRV_INST(_inst), sensor_types, 0),\


This is just using the first type in the list.

teburd · 2023-12-15T18:17:38Z

Looks like some minor lint issues on the commits and some code lines are preventing CI from being green, please fix this as usually people won't review without a green CI pass

1) move variable shift behind struct sensing_sensor_value_header in struct sensing_sensor_value_q31 2) add pointer checking for sensing API 3) add context sensing_callback_list and sensing_data_event_t 4) add macro SENSING_SENSITIVITY_INDEX_ALL 5) rename zephyr,sensing-phy-3d-sensor.yaml Signed-off-by: Guangfu Hu <guangfu.hu@intel.com>

1. use the sensor_driver_api instead of the sensing_sensor_api. 2. clean up the sensing_sensor.h after using the unified api. 3. select RTIO while CONFIG_SENSING is enabled. 4. remove the sensing_sensor_post_data and sensing_sensor_xxx_data_ready by introducing the RTIO Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

1. set/get interval sensitivity is implmented in sensor management module. 2. add the runtime thread to handle the sensor configuration. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Create the dispatch thread to send sensor data to its client by checking time. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Add two helper functions as the couple functions of sensor_value_to_milli and sensor_value_to_micro. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

This patch is to implement the phy_3d_sensor in sensing subsystem. It's a wrapper layer of AGM sensor driver for sensing subsystem. It supports the accelerometer and gyrometer now. This has been tested with bmi160 on native_posix simulator. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Add stream-mode property to indicate sensing sensor working stream mode or poll mode. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Add hinge angle virtual sensor for sensing subsystem, hinge angle sensor takes both base accel and lid accel as reporter. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

1. add sensing_set_config/sensing_get_config in sample code 2. add hinge_angle sensor in sample code. Build and test: west build -p -b native_sim samples/subsys/sensing/simple/ -t run Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Many sensors have multiple functions, for example, icm42688 supports accel, gyro and temperature, and the sensor streaming api always mixes the multiple functions in one function call. So we need add a layer in sensing subsystem to dispatch the result returned from sensor streaming api for each function. I changed the sensor-type(int) to sensor-types(array) in sensing sensor device bindings, so that one device can map to multiple instances of sensing sensor. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

Some doc comments were making doxygen unhappy and the doc build fail. The description of the sensor connection was also updated slightly to simplify the description a bit. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>

Fixes a few small code formatting issues in sensor_mgmt.c adding brackets where needed for an if and droping a line continuation slash that failed one of the CI lints. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>

Initializers must be compile time constants (not expressions!) for clang to be happy. Clang rightfully pointed out that the callback_list member of sensing_connection was being initialized using an expression that was not compile-time constant. The macros passed along a pointer created by taking the address of a global constant and then at initialization time attempting to dereference it using the * operator. So in the end the compiler has identifier its trying to first take the address of and then later dereference in an initializer. Clang didn't appreciate this, though gcc seemed to be just fine. Actually clang 17 might work just fine with this as well, but clang 16 (the clang I tried) didn't like it at all. Instead store the pointer to the callback list rather than copying the struct. This could be done the other way and not passing a pointer through the macros perhaps. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>

The sensing_connections can be shared between sensing_sensors under the same device. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

1. add function sensing_iodev_submit and defined struct sensing_submit_config 2. fix the issue of phy_3d_sensor Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

lixuzha · 2023-12-18T08:56:13Z

Looks like some minor lint issues on the commits and some code lines are preventing CI from being green, please fix this as usually people won't review without a green CI pass

Fixed.

Please revisit and re-review.

carlescufi

Changes to the sensing API look good to me

kartben · 2024-01-29T09:44:42Z

include/zephyr/sensing/sensing.h

@@ -110,7 +115,8 @@ typedef void *sensing_sensor_handle_t;
 */
 typedef void (*sensing_data_event_t)(
 		sensing_sensor_handle_t handle,
-		const void *buf);
+		const void *buf,
+		void *context);


needs doxygen comment

Thanks. Submitted #68317 to fix it.

kartben · 2024-01-29T09:45:02Z

include/zephyr/sensing/sensing.h

 	sensing_data_event_t on_data_event;
+	void *context;


need doxygen comment

lixuzha requested review from MaureenHelm and galak as code owners October 27, 2023 08:08

zephyrbot added area: Sensor Subsystem area: Sensors Sensors area: Devicetree Binding PR modifies or adds a Device Tree binding area: Samples Samples labels Oct 27, 2023

lixuzha requested review from teburd, microbuilder, yperess and KeHIntel October 27, 2023 08:08

zephyrbot requested review from avisconti, kartben, nashif and tristan-google October 27, 2023 08:08

zephyrbot assigned MaureenHelm Oct 27, 2023

teburd reviewed Nov 1, 2023

View reviewed changes

yperess requested changes Nov 13, 2023

View reviewed changes

lixuzha force-pushed the sensing_unified_api branch from 1ddcdfc to 020dab8 Compare November 13, 2023 05:14

lixuzha requested a review from qianruh as a code owner November 13, 2023 05:14

This was referenced Nov 27, 2023

sensing: implement the phy_3d_sensor #60331

Closed

ghu sensing upstream pr3 #59469

Closed

lixuzha force-pushed the sensing_unified_api branch 2 times, most recently from 5dc27cd to b4aeea1 Compare November 27, 2023 08:13

teburd mentioned this pull request Nov 27, 2023

sensors: Sensor channel DT child nodes #65830

Closed

teburd force-pushed the sensing_unified_api branch from 107926b to 2c83510 Compare December 1, 2023 17:03

yperess previously requested changes Dec 7, 2023

View reviewed changes

teburd requested a review from yperess December 15, 2023 18:17

lixuzha force-pushed the sensing_unified_api branch from 922949a to b3dfabc Compare December 18, 2023 05:38

ghu0510 and others added 13 commits December 18, 2023 13:40

sensing: implement set/get interval and sensitivity

5577434

1. set/get interval sensitivity is implmented in sensor management module. 2. add the runtime thread to handle the sensor configuration. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensing: implement sensor data dispatching

acb0a57

Create the dispatch thread to send sensor data to its client by checking time. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensor: add helper functions to convert milli/micro to sensor_value

d0b1ec3

Add two helper functions as the couple functions of sensor_value_to_milli and sensor_value_to_micro. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensing: add stream mode property for sensing sensor

206d155

Add stream-mode property to indicate sensing sensor working stream mode or poll mode. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensing: add hinge angle sensor

aa0b05e

Add hinge angle virtual sensor for sensing subsystem, hinge angle sensor takes both base accel and lid accel as reporter. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

samples: sensing: add more sample code

7385ee0

1. add sensing_set_config/sensing_get_config in sample code 2. add hinge_angle sensor in sample code. Build and test: west build -p -b native_sim samples/subsys/sensing/simple/ -t run Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensing: Simplify and correct some docstrings

8940777

Some doc comments were making doxygen unhappy and the doc build fail. The description of the sensor connection was also updated slightly to simplify the description a bit. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>

sensing: Code formatting fixups

4a3da59

Fixes a few small code formatting issues in sensor_mgmt.c adding brackets where needed for an if and droping a line continuation slash that failed one of the CI lints. Signed-off-by: Tom Burdick <thomas.burdick@intel.com>

lixuzha force-pushed the sensing_unified_api branch from b3dfabc to 437501e Compare December 18, 2023 06:22

lixuzha added 2 commits December 18, 2023 14:22

sensing: using the single sensing_connections for the same device

1b5cdef

The sensing_connections can be shared between sensing_sensors under the same device. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

sensing: add rtio implement for sensing subsys

437501e

1. add function sensing_iodev_submit and defined struct sensing_submit_config 2. fix the issue of phy_3d_sensor Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>

teburd approved these changes Jan 9, 2024

View reviewed changes

KeHIntel approved these changes Jan 11, 2024

View reviewed changes

teburd mentioned this pull request Jan 12, 2024

Fixing design concerns with Sensor Subsystem (sensing) #58925

Closed

3 tasks

MaureenHelm assigned teburd and unassigned MaureenHelm Jan 17, 2024

carlescufi approved these changes Jan 24, 2024

View reviewed changes

carlescufi merged commit 5058355 into zephyrproject-rtos:main Jan 24, 2024
18 checks passed

kartben reviewed Jan 29, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sensor: sensing: unified api #64478

sensor: sensing: unified api #64478

lixuzha commented Oct 27, 2023 •

edited

Loading

teburd left a comment •

edited

Loading

teburd Nov 1, 2023

teburd Nov 1, 2023

yperess Nov 13, 2023

teburd Nov 1, 2023 •

edited

Loading

yperess Dec 7, 2023

teburd Nov 1, 2023

teburd Nov 1, 2023 •

edited

Loading

teburd Nov 1, 2023

lixuzha Nov 13, 2023

teburd Nov 13, 2023

KeHIntel commented Nov 2, 2023

lixuzha commented Nov 2, 2023

yperess left a comment

yperess Nov 13, 2023

lixuzha Nov 13, 2023

yperess Nov 13, 2023

lixuzha Nov 13, 2023

yperess Nov 13, 2023

lixuzha Nov 13, 2023

yperess Nov 13, 2023

lixuzha Nov 27, 2023

nashif commented Nov 13, 2023

lixuzha commented Nov 27, 2023

yperess Dec 7, 2023

yperess Dec 7, 2023

yperess Dec 7, 2023

yperess Dec 7, 2023

teburd commented Dec 15, 2023

lixuzha commented Dec 18, 2023

carlescufi left a comment

kartben Jan 29, 2024

lixuzha Jan 31, 2024

kartben Jan 29, 2024

sensor: sensing: unified api #64478

sensor: sensing: unified api #64478

Conversation

lixuzha commented Oct 27, 2023 • edited Loading

Links

teburd left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teburd Nov 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teburd Nov 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KeHIntel commented Nov 2, 2023

lixuzha commented Nov 2, 2023

yperess left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nashif commented Nov 13, 2023

lixuzha commented Nov 27, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teburd commented Dec 15, 2023

lixuzha commented Dec 18, 2023

carlescufi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lixuzha commented Oct 27, 2023 •

edited

Loading

teburd left a comment •

edited

Loading

teburd Nov 1, 2023 •

edited

Loading

teburd Nov 1, 2023 •

edited

Loading