CAF: Sensor manager
The sensor manager sample demonstrates the functionality of the CAF: Sensor manager module. It uses the Sensor stub 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 |
Board target |
|---|---|---|---|
PCA10175 |
|
||
PCA10095 |
|
||
PCA10056 |
|
Overview
The sample provides stub input data using Sensor stub driver.
The input data simulates acceleration in X, Y, and Z axes.
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.
Configuration
See Configuring and building for information about how to permanently or temporarily change the configuration.
Single-core configuration
For the MCU with multiple cores, the default configuration uses one core to simulate the sensor and the other core to process the sensor.
The multicore MCUs can also support a single-core configuration, where the sensor is simulated and processed on a single, selected core.
The configuration is placed in the boards/<board>_singlecore.conf file.
To use this configuration, run the following command:
west build -b nrf5340dk/nrf5340/cpuapp -- -DFILE_SUFFIX=singlecore
Building and running
For the MCU with multiple cores, the default configuration ensures that all the required cores are built. You can build and flash all the required images by completing the following steps for all the required cores.
This sample can be found under samples/caf_sensor_manager in the nRF Connect SDK folder structure.
To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.
Note
When building repository applications in the SDK repositories, building with sysbuild is enabled by default.
If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.
Complete the following steps to program the sample:
Go to the sample directory.
Start the toolchain environment in a terminal window.
Run the following command to build the application code for the host and the remote:
west build -b nrf5340dk/nrf5340/cpuappProgram both the cores:
west flash
Note
Programming the nRF54H20 SoC can sometimes fail due to conflicts in the resource configuration. This can happen if, for example, an application programmed to the nRF54H20 SoC configured the UICRs for one or more cores in a way that is incompatible with the configuration required by the application you are trying to program on the SoC.
To fix this error and erase the UICR for the application core, run the following command:
nrfutil device recover --core Application
If your sample also uses the radio core, you must also erase the UICRs for the radio core. To erase the UICR for the radio core, run the following command:
nrfutil device recover --core Network
For more information on the command, run:
nrfutil device recover --help
You can then run west flash to program your application.
Note
When using the nRF54H20 DK Engineering B (from v0.8.0 to 0.8.2), you must build samples and applications using the board revision 0.8.0 with the <board>@<revision> syntax.
For example, nrf54h20dk@0.8.0/nrf54h20/cpuapp when building for the application core, or nrf54h20dk@0.8.0/nrf54h20/cpurad when building for the radio core.
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, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.
Reset the kit.
Observe that output similar to the following is logged on UART:
* Booting Zephyr OS build v3.0.99-ncs1-2759-g07737b0b09e7 * [00:00:00.257,232] <inf> main: Event manager initialized [00:00:00.258,239] <inf> event_proxy_init: Event proxy remote added [00:00:00.259,948] <inf> event_proxy_init: Event proxy sensor_data_aggregator_event registered [00:00:00.260,009] <inf> event_proxy_init: Event manager proxy started [00:00:00.260,284] <inf> event_proxy_init: All remotes ready [00:00:00.260,345] <inf> app_event_manager: e:module_state_event module:main state:READY [00:00:00.260,742] <inf> app_event_manager: e:sensor_data_aggregator_event Send sensor buffer desc address: 0x100e28a [00:00:00.260,894] <inf> app_event_manager: e: sensor_data_aggregator_release_buffer_event [00:00:02.260,620] <inf> app_event_manager: e:sensor_data_aggregator_event Send sensor buffer desc address: 0x100e28a [00:00:02.260,864] <inf> app_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