Event Manager Proxy
The Event Manager Proxy sample demonstrates how to use Event Manager Proxy to transport events between remote and host cores. The sample also demonstrates the proposed application structure where common events declarations and definitions are available for both cores.
Requirements
The sample supports the following development kits:
Hardware platforms |
PCA |
Board name |
Build target |
|---|---|---|---|
PCA10095 |
|
Overview
The proxy sample copies the functionality from Application Event Manager sample, but splits it between the two cores. The remote core runs the simulated sensor module, while the host core takes care of configuration and calculates statistics.
The sample uses modules from Application Event Manager sample, which communicate using events:
- Sensor (
sensor_simulated.c): This module waits for a configuration event (which is sent by
main.c). After receiving this event, it simulates measured data at constant intervals. Every time the data is updated, the module sends the current values as measurement event. When the module receives a control event from the Controller, it responds with an ACK event.- Controller (
controller.c): This module waits for measurement events from the sensor. Every time a measurement event is received, the module checks one of the measurement values that are transmitted as part of the event and, if the value exceeds a static threshold, sends a control event.
- Statistics (
stats.c): This module waits for measurement events from the sensor. The module calculates and logs basic statistics about one of the measurement values that are transmitted as part of the event.
The only change compared with the Application Event Manager sample modules is that the Statistic module now also counts control messages. This change allows to transfer different range of messages between cores.
File and directory layout
The application is divided into host and remote.
The host configuration is placed directly in the samples/event_manager_proxy folder.
The remote configuration is placed in the samples/event_manager_proxy/remote folder.
The remote configuration is added to the host as a subproject, which means that it builds as part of the host application build.
Both the remote and the host use common event declarations and definitions that are located in the samples/event_manager_proxy/common_events folder, and modules that are located in the samples/event_manager_proxy/modules folder.
Configuration
See Configuring your application for information about how to permanently or temporarily change the configuration.
Selecting ICMSG backend
By default, the Event Manager Proxy sample uses the OpenAMP backend provided by the IPC Service. You can instead select the ICMSG backend configuration, which has smaller memory requirements.
The ICMSG backend configuration is provided in the prj_icmsg.conf file.
To provide the ICMSG backend configuration, specify the -DCONF_FILE=prj_icmsg.conf parameter along with the build command when building the sample:
west build -p -b nrf5340dk_nrf5340_cpuapp -- -DCONF_FILE=prj_icmsg.conf
Building and running
This sample can be found under samples/event_manager_proxy 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.
In the current sample version, you must separately build and program the firmware for the host and the remote. For example, you can do this from the command line using west by completing the following steps:
Go to the sample directory.
Open the command line terminal.
Run the following command to build the application code for the host and the remote:
west build -b nrf5340dk_nrf5340_cpuapp .Program the host core:
west flash
Testing
After programming the sample to your development kit for both cores, 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 logged on two UART serial terminals. One for the host and the other for the remote core.
On the host core, we expect the following messages:
*** Booting Zephyr OS build v2.7.99-ncs1-17-gc3208e7ff49d *** Event Manager Proxy demo started [00:00:00.284,881] <inf> event_manager: e:config_event init_val_1=3 [00:00:00.285,430] <inf> event_manager: e:measurement_event val1=3 val2=3 val3=3 [00:00:00.785,675] <inf> event_manager: e:measurement_event val1=3 val2=6 val3=9 [00:00:01.285,949] <inf> event_manager: e:measurement_event val1=3 val2=9 val3=18 [00:00:01.786,254] <inf> event_manager: e:measurement_event val1=3 val2=12 val3=30 [00:00:02.286,560] <inf> event_manager: e:measurement_event val1=3 val2=15 val3=45 [00:00:02.286,682] <inf> event_manager: e: control_event [00:00:02.286,682] <inf> stats: Control event count: 1 [00:00:02.787,017] <inf> event_manager: e:measurement_event val1=-3 val2=12 val3=57 [00:00:03.287,322] <inf> event_manager: e:measurement_event val1=-3 val2=9 val3=66 [00:00:03.787,597] <inf> event_manager: e:measurement_event val1=-3 val2=6 val3=72 [00:00:04.287,872] <inf> event_manager: e:measurement_event val1=-3 val2=3 val3=75 [00:00:04.788,177] <inf> event_manager: e:measurement_event val1=-3 val2=0 val3=75 [00:00:04.788,208] <inf> stats: Average value3: 45 [00:00:05.288,452] <inf> event_manager: e:measurement_event val1=-3 val2=-3 val3=72 [00:00:05.788,726] <inf> event_manager: e:measurement_event val1=-3 val2=-6 val3=66 [00:00:06.289,031] <inf> event_manager: e:measurement_event val1=-3 val2=-9 val3=57 [00:00:06.789,306] <inf> event_manager: e:measurement_event val1=-3 val2=-12 val3=45 [00:00:07.289,611] <inf> event_manager: e:measurement_event val1=-3 val2=-15 val3=30 [00:00:07.289,733] <inf> event_manager: e: control_event [00:00:07.289,733] <inf> stats: Control event count: 2
The host starts the communication by sending a
config_event, which is also received and processed by the remote core.On the remote core following messages are expected:
*** Booting Zephyr OS build v2.7.99-ncs1-17-gc3208e7ff49d *** Event Manager Proxy remote_core started [00:00:00.010,864] <inf> event_manager: e:config_event init_val_1=3 [00:00:00.011,047] <inf> event_manager: e:measurement_event val1=3 val2=3 val3=3 [00:00:00.511,322] <inf> event_manager: e:measurement_event val1=3 val2=6 val3=9 [00:00:01.011,566] <inf> event_manager: e:measurement_event val1=3 val2=9 val3=18 [00:00:01.511,871] <inf> event_manager: e:measurement_event val1=3 val2=12 val3=30 [00:00:02.012,176] <inf> event_manager: e:measurement_event val1=3 val2=15 val3=45 [00:00:02.012,298] <inf> event_manager: e: control_event [00:00:02.012,451] <inf> event_manager: e: ack_event [00:00:02.512,634] <inf> event_manager: e:measurement_event val1=-3 val2=12 val3=57 [00:00:03.012,939] <inf> event_manager: e:measurement_event val1=-3 val2=9 val3=66 [00:00:03.513,244] <inf> event_manager: e:measurement_event val1=-3 val2=6 val3=72 [00:00:04.013,488] <inf> event_manager: e:measurement_event val1=-3 val2=3 val3=75 [00:00:04.513,793] <inf> event_manager: e:measurement_event val1=-3 val2=0 val3=75 [00:00:05.014,099] <inf> event_manager: e:measurement_event val1=-3 val2=-3 val3=72 [00:00:05.514,343] <inf> event_manager: e:measurement_event val1=-3 val2=-6 val3=66 [00:00:06.014,648] <inf> event_manager: e:measurement_event val1=-3 val2=-9 val3=57 [00:00:06.514,953] <inf> event_manager: e:measurement_event val1=-3 val2=-12 val3=45 [00:00:07.015,197] <inf> event_manager: e:measurement_event val1=-3 val2=-15 val3=30 [00:00:07.015,350] <inf> event_manager: e: control_event [00:00:07.015,502] <inf> event_manager: e: ack_event
Now all the measurement and control events are generated on the remote core and passed to the host core, where the statistics are generated.
On the remote core, we can also see an ack_event, which is not passed to the host core.
Dependencies
This sample uses the following nRF Connect SDK subsystems:
In addition, it uses the following Zephyr subsystems:
include/ipc/ipc_service.h