drivers: sensor: Add asynchronous sensor simulator driver

[ct-lt]

Introduces a new sensor simulator driver with the new Read and Decode API. The driver allows for the simulation of a sensor with an internal FIFO.

Test data can be fed to the simulator, which then can be streamed with sensor_stream() or queried with sensor_read() in the user application under test. The Fetch + Get API is also supported.
Currently, there is no sensor simulator in Zephyr. Only Nordic provides a simple sensor simulator limited to the Fetch + Get API.

Check the unit test of the driver as a usage example.

[github-actions]

Hello @ct-lt, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[ct-lt]

I am not sure why the CI test line_splitting.Should Split Lines fails with Unknown Instance status. (renode 11.814s <zephyr>) in the workflow and how to address that?

[Copilot]

Copilot reviewed 5 out of 12 changed files in this pull request and generated no comments.

Files not reviewed (7)

• drivers/sensor/CMakeLists.txt: Language not supported
• drivers/sensor/Kconfig: Language not supported
• drivers/sensor/sensor_sim_async/CMakeLists.txt: Language not supported
• drivers/sensor/sensor_sim_async/Kconfig: Language not supported
• tests/drivers/sensor/sensor_sim_async/CMakeLists.txt: Language not supported
• tests/drivers/sensor/sensor_sim_async/app.overlay: Language not supported
• tests/drivers/sensor/sensor_sim_async/prj.conf: Language not supported

Comments suppressed due to low confidence (2)

tests/drivers/sensor/sensor_sim_async/src/main.c:105

• [nitpick] Consider using an explicit boolean expression (e.g., 'bool tap_triggered = ((i % 3) != 0);') to more clearly indicate the intent.

bool tap_triggered = i % 3;

tests/drivers/sensor/sensor_sim_async/src/main.c:120

• [nitpick] Consider defining a named constant or adding a comment to clarify the purpose behind subtracting 10 from ARRAY_SIZE(test_data) for improved maintainability.

sensor_sim_async_feed_data(dev, test_data, ARRAY_SIZE(test_data) - 10, i == 0 ? 0 : -1, SENSOR_CHAN_ACCEL_XYZ);

[kartben]

I am not sure why the CI test line_splitting.Should Split Lines fails with Unknown Instance status. (renode 11.814s <zephyr>) in the workflow and how to address that?

Not your fault :) it's now been fixed in main and I've run the tests again and they pass :)

[teburd]

I like it, seems like it could be expanded to generate data from a compiled in data source instead in the future which would be nice... e.g. here's my pre-recorded data, replay it on repeat?

[ct-lt]

I like it, seems like it could be expanded to generate data from a compiled in data source instead in the future which would be nice... e.g. here's my pre-recorded data, replay it on repeat?

I initially wrote this driver to do exactly that. I generated test data with Python as a C header, which I then included in my test program and fed it to the driver with sensor_sim_async_feed_data(...). Let's say you have recorded (or generated) some noise and want to play that on repeat, then you would have generated C code like this:

#include <drivers/sensor/sensor_sim_async.h>

struct test_data_definition {
    const char* name;
    float frequency;
    int num_samples;
    const struct sensor_sim_async_sensor_fifo_sample *data;
};
const struct sensor_sim_async_sensor_fifo_sample noise_data[] = {
        {.x = 390, .y = 143, .z = 1104},
        {.x = 135, .y = 218, .z = 839},
        {.x = 109, .y = 79, .z = 1191},
        ...
};
const struct test_data_definition noise = {
    .name = "noise",
    .frequency = 400,
    .num_samples = 2000,
    .data = noise_data,
};

and then could "play" that noise like this

static void stream_noise_for_sec(uint32_t sec)
{
	uint32_t samples_to_stream = sec * noise.frequency;
	while (samples_to_stream > 0) {
		sensor_sim_async_feed_data(accel0, noise.data, MIN(samples_to_stream, noise.num_samples), -1,
								   SENSOR_CHAN_ACCEL_XYZ);
		samples_to_stream -= MIN(samples_to_stream, noise.num_samples);
	}
}

Or do you think of some other way to have the data be defined and compiled in?

[avisconti]

Seems quite interesting... I'll add my +1, I just give a quick look though

[yperess]

I don't understand why this is needed. Why can't you use the existing emulator framework that would also allow you to exercise the actual driver you're testing?

@ct-lt please see https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/bosch/bmi160/emul_bmi160.c and https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/emul_sensor.h

[ct-lt]

I don't understand why this is needed. Why can't you use the existing emulator framework that would also allow you to exercise the actual driver you're testing?

@ct-lt please see https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/bosch/bmi160/emul_bmi160.c and https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/emul_sensor.h

This is intended to ease testing user applications that use the Read+Decode API, not to test any actual driver. It offers an easy way to feed test data into the user application and to test on a higher level, independent from the final hardware / driver to be used.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud