Zephyr App Event Manager (app_event_manager)

2026-04-06T00:00:00Z

Another design of event-driven architecture is the AEM (app_event_manager) in Zephyr. This subsystem/framework enforces its users to structure their code in modules. Each module connected to the event-driven backend will need to explicitly subscribe/listen to another module to get notified of any events happening.

To me, this architecture style really helps when I need to isolate a particular module to debug or test easily. I could simply remove it from the CMakeLists.txt, and logically, the tight coupling design will not affect other modules.

https://docs.nordicsemi.com/bundle/ncs-3.0.2/page/nrf/libraries/others/app_event_manager.html

Here’s a small snippet of how it looks in practice:

/* --- Event Definition --- */
APP_EVENT_TYPE_DEFINE(sensor_data_event,
		  NULL,
		  NULL,
		  APP_EVENT_FLAGS_CREATE(
			APP_EVENT_TYPE_FLAG_INIT_LOG_ENABLE
		  ));

/* --- Module A: Publisher --- */
static void publish_sensor_data(int32_t value) {
	struct sensor_data_event *evt = new_sensor_data_event();
	evt->value = value;
	APP_EVENT_SUBMIT(evt);
}

/* --- Module B: Subscriber --- */
static bool app_event_handler(const app_event_header *aeh) {
	if (is_sensor_data_event(aeh)) {
		struct sensor_data_event *evt = cast_sensor_data_event(aeh);
		LOG_INF("Received sensor data: %d", evt->value);
		return true;
	}
	return false;
}

APP_EVENT_LISTENER_DEFINE(sensor_event_listener, app_event_handler);
APP_EVENT_SUBSCRIBE(sensor_event_listener, sensor_data_event);

With this approach, if I want to test Module B in isolation, I can simply remove Module A from the build, and the app still runs, it simply stops sending events. Really nice for unit testing and incremental development.

Zephyr Modern C++ - State Machine Size Comparison

2026-01-12T00:00:00Z

Can we use the latest C++ features on microcontrollers? Yes.

I’ve been testing out to use it on Zephyr and ESP-IDF.

One particular feature I tried out in this example is the use of std::variant for different States, and ultimately using std::visit to iterate through them. Here I provide implementation of a general get_state_info to read what the current state is using the Overloaded Lambda idiom (to enforce availability of all StateVariants), it will then return a std::string_view of different messages based on the current_state_.

Let’s say, a more shiny StateMachine haha. A different approach than using bare enums and switch statements (not simply saying they are less).

Check it out! https://github.com/royyandzakiy/zephyr-modern-cpp

So far, there is a 540 bytes difference when using std::variant/std::visit, compared to raw enum/switch.

First build (std::variant/visit):

FLASH: 73,112 bytes (6.97% of 1MB)
RAM: 53,928 bytes (11.76% of 448KB)

Second build (enum/switch) (code depicted in image below):

FLASH: 72,572 bytes (6.92% of 1MB)
RAM: 53,928 bytes (11.76% of 448KB)

I also tried comparing when adding the C++ library to the compilation, and removing it. There is a 4256 byte addition.

Third build (converting all C++ to pure C & but still compiling C++ library in kconfig):

FLASH: 71,588 bytes (6.83% of 1MB)
RAM: 53,952 bytes (11.76% of 448KB)

Fourth build (converting all C++ to pure C & removing C++ library in kconfig):

FLASH: 67,332 bytes (6.42% of 1MB)
RAM: 53,840 bytes (11.74% of 448KB)

State machine using std::variant, std::visit

State machine using enum & switch

Removing most all CPP code, change into C

Removing CPP lib in prj.conf

Code using enum & switch

The variant doesn’t add too much overhead. I was expecting a lot more bytes eaten up just by using Templates itself 😄

cc Srdjan Stokic

Articles tagged zephyr at Royyan Dzakiy

Zephyr App Event Manager (app_event_manager)

Zephyr Modern C++ - State Machine Size Comparison