Each module follows a similar design:
- Message channel: Each module defines its own zbus channel. A single channel is used for all messages that are specific to a module.
- Message types: Each module exposes a set of input and output message types. These can be considered events in the state machine sense and might have associated data.
- State machine: Modules with state implement a state machine using SMF to manage their internal state and behavior. Simpler modules handle messages directly, as listed in Modules per application.
- Thread: Each module has its own thread, so that blocking calls in one module cannot stall another.
- Watchdog: Each module thread is monitored by a task watchdog. Each thread periodically calls
task_wdt_feed(). If a thread fails to feed its watchdog within its configured timeout, the system resets. - Initialization: Modules are initialized in their dedicated thread, which is started with
K_THREAD_DEFINE().
The modules are designed as loosely coupled units with well-defined message-based interfaces. They communicate exclusively through their zbus channels, without reference to other modules' internals. This means you can develop, test, and maintain each module independently, and every module except the Main module can be reused in other applications.
Modules often handle state transitions based on messages they themselves publish. For example, when the Network module publishes a NETWORK_CONNECTED message, it also receives this message in its own state machine, allowing it to transition to the connected state with consistent handling.
The Main module deviates from the pattern in the following two ways:
- It runs in the
main()thread instead of a thread of its own. - It is the only module that calls
task_wdt_init()to set up the hardware watchdog (DT_ALIAS(watchdog0)) that all the other modules add their tasks to.