Device Firmware

This repo is home to the firmware for the nrf54l15 CGC device.

Repo Structure

The repo will be structured into three main directories, that correspond to three distinct layers:

• drivers/: This directory contains low-level drivers for hardware components, such as sensors, communication modules, and power management units. These drivers provide an interface for higher-level software to interact with the hardware. Drivers should not contain any logic beyond what is necessary to operate the hardware. As most services will call into Zephyr drivers, we may not need many or any custom drivers. Drivers should NOT be aware of services or application logic, and should NOT call into other drivers.
• services/: This directory contains mid-level services that build upon the drivers to provide more complex functionality. Examples of services include sensor data processing, ble communication management, and power monitoring/management. Services should encapsulate specific functionality and provide a clean interface for the application layer to interact with. Services should NOT be aware of the top-level application logic. The service layer should contain the bulk of the system's logic. Services may be broken into multiple subdirectories and may run multiple threads if necessary, but should provide a single, clear interface that the application layer can use.
• app/: This directory contains the top-level application logic that orchestrates the overall behavior of the device. The application layer should utilize the services to achieve its goals, such as collecting sensor data, managing communication, and handling user interactions. The application layer should be aware of the overall system state and make decisions based on that state. The repo has been structured so multiple applications can be developed if we choose to do so. The application layer also contains the build context for the given application (e.g., prod for production firmware), including prj.conf, the top level CMakeLists.txt, and any other build-related configuration files.

Having the app contain build context may seem like some unnecessary additional overhead, especially if we only have one application, but it provides a clean separation of concerns and is a learning opportunity for the modular build system Zephyr provides. Essentially, services, drivers, and each app directory could be separate a seperate module and repos if we wanted to have version control for each (common in large embedded systems dev). So while it may seem odd to have separate modules in a single repo, it's a good practice to follow and learn.