CAF: Sensor manager
The sensor manager sample demonstrates the functionality of the CAF: Sensor manager module. It uses the Simulated sensor driver, the sensor manager module, the CAF: Sensor data aggregator module, and the workload simulator module to automatically sample and gather data and then receive and process it in packages.
Requirements
The sample supports the following development kits:
Hardware platforms |
PCA |
Board name |
Build target |
---|---|---|---|
PCA10095 |
|
||
PCA10056 |
|
Overview
The sample provides simulated input data using Simulated sensor driver.
The input data simulates acceleration in X, Y, and Z axes, with the acceleration generated as value of a periodic wave signal.
Whenever new data is generated, the CAF: Sensor manager module generates the appropriate sensor_event
instances that include the generated data.
The data from the events is then passed to the CAF: Sensor data aggregator module.
When the aggregator’s buffer is full, the application sends aggregated data to the workload simulator module (workload_sim
).
The workload simulator is a custom module used by this sample only.
This module handles the data received from the CAF: Sensor data aggregator module, simulates workload on data using k_busy_wait()
and notifies the aggregator module when the aggregator buffer can be freed.
If you are running this sample on an SoC with multiple cores, the workload simulator module (workload_sim
) is placed on the second core.
All communication between the cores is done using Event Manager Proxy and Zephyr subsystem include/ipc/ipc_service.h
.
Sensor stub
By default, the sensor manager sample uses Simulated sensor driver for sensor data simulation. You can select the sensor stub module instead. The sensor stub module has a simple implementation that relates fully to the application implementing the function to generate the sensor data. This sample implements a simple generator for the sensor stub that uses no floating point mathematics.
For more details on the sensor stub configuration, see the Sensor stub configuration section.
Configuration
See Configuring your application for information about how to permanently or temporarily change the configuration.
Single core configuration
For the MCU with multiple cores, the default configuration will use one core to simulate the sensor and the other core to process the sensor.
These multiple core MCU can support single core configuration, where the sensor is simulated and processed on the single, selected core.
The configuration is placed in the boards/<board>_singlecore.conf file
.
To use this configuration, specify the -DOVERLAY_CONFIG=boards/<board>_singlecore.conf
parameter along with the build command when building the sample:
west build -b nrf5340dk_nrf5340_cpuapp -- -DOVERLAY_CONFIG=boards/nrf5340dk_nrf5340_cpuapp_nrf5340_singlecore.conf
Sensor stub configuration
The Sensor stub configuration is provided in the sensor_stub_overlay.conf
file.
To use this configuration, specify the -DOVERLAY_CONFIG=sensor_stub_overlay.conf
parameter along with the build command when building the sample.
For the multicore configuration, it would change to -Dremote_OVERLAY_CONFIG=sensor_stub_overlay.conf
as shown in the following example:
west build -b nrf5340dk_nrf5340_cpuapp -- -Dremote_OVERLAY_CONFIG=sensor_stub_overlay.conf
When single-core configuration is used on multicore MCU, add the sensor selection after the single-core configuration parameter as shown in the following example:
west build -b nrf5340dk_nrf5340_cpuapp -- -DOVERLAY_CONFIG="boards/nrf5340dk_nrf5340_cpuapp_nrf5340_singlecore.conf;sensor_stub_overlay.conf"
Building and running
This sample can be found under samples/caf_sensor_manager
in the nRF Connect SDK folder structure.
To build the sample with Visual Studio Code, follow the steps listed on the Building nRF Connect SDK application quick guide page in the nRF Connect for VS Code extension documentation. See Building and programming an application for other building and programming scenarios and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.
Testing
After programming the sample to your development kit, test it by performing the following steps:
Connect to the kit with a terminal emulator (for example, PuTTY). See How to connect with PuTTY for the required settings.
Reset the kit.
Observe that output similar to the following is logged on UART:
[00:12:* Booting Zephyr OS build v2.7.99-ncs1-2182-gbb39dfe3121a * [00:00:00.258,605] <inf> event_manager: e:module_state_event module:main state:READY [00:00:00.258,728] <inf> event_manager: e:module_state_event module:sensor_sim_ctrl state:READY [00:00:00.258,850] <inf> event_manager: e:sensor_state_event sensor:accel_sim_xyz state:ACTIVE [00:00:00.258,941] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz [00:00:00.259,033] <inf> event_manager: e: sensor_data_aggregator_release_buffer_event [00:00:00.259,124] <inf> event_manager: e:module_state_event module:sensor_manager state:READY [00:00:00.458,526] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz [00:00:00.458,709] <inf> event_manager: e: sensor_data_aggregator_release_buffer_event [00:00:00.658,538] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz [00:00:00.658,721] <inf> event_manager: e: sensor_data_aggregator_release_buffer_event
Dependencies
This sample uses the following nRF Connect SDK libraries:
This sample uses the following nRF Connect SDK drivers:
In addition, it uses the following Zephyr subsystems:
include/ipc/ipc_service.h