# nRF54L15 Support > Portable C libraries and Zephyr drivers for the Nordic nRF54L15 with examples for the Seeed XIAO nRF54L15 Sense. Canonical page: [nRF54L15 Support]() Project date: Oct 2026 Updated: 2026-10-13 Category: Embedded libraries Status: Open source Tags: C, Zephyr, nRF Connect SDK, Bluetooth LE, Embedded - **My work:** Portable C libraries, Zephyr adapters, firmware examples, and telemetry tools - **Hardware:** Seeed XIAO nRF54L15 Sense - **License:** Apache-2.0 - [View source]() - [v0.1.0 release]() ## In short I built nRF54L15 Support as reusable code for reading sensors, estimating orientation, and sending data from a small Nordic chip. It provides components for my OpenFloat Archery project, along with firmware examples and tests for other applications. This first release is experimental, and its programming interfaces may change. ![Illustration of a schematic MCU board, motion axes, and Bluetooth symbol beside the nRF54L15 Support name; not a photo or screenshot.]() Original illustration of the library's MCU, IMU, and Bluetooth LE themes, not a hardware photo or screenshot. ## Overview I built nRF54L15 Support as portable C libraries for the Nordic nRF54L15 system-on-chip (SoC), which combines a processor and hardware features on one chip. I included examples for the **Seeed XIAO nRF54L15 Sense**. Zephyr hardware adapters connect the libraries to an embedded operating system. The portable code can run on a host computer or sit inside an nRF Connect SDK application, using Nordic’s development toolkit. ### Memory and hardware calls The library code allocates no heap memory: it does not request extra memory dynamically while running. Callers own the state and buffers (the stored working data), while the Bluetooth service is a singleton, meaning there is one shared instance. Zephyr and the SDK manage their own resources. Hardware calls run in thread context, within scheduled tasks rather than interrupt handlers. They must be serialized: callers need to keep those calls from running at the same time. ## Motion and hardware support ### Orientation and motion readings An inertial measurement unit (IMU) measures motion. My orientation code includes: - A **Madgwick IMU filter**, which combines motion readings to estimate orientation. - Quaternion normalization, which keeps the mathematical orientation representation valid. - Euler conversion, which expresses orientation as three angles. - Wrapped angles, which keep angle values within a repeating range. Motion support includes an upstream Zephyr IMU adapter and direct LSM6DS3TR-C I2C access (a wired chip-to-chip connection). Readings can use polling (checking for data), a FIFO (first-in, first-out buffer), INT1 notifications (signals on the sensor’s interrupt pin), and suspend/resume. Stationary gyro calibration adjusts the rotation sensor while it is still, rejecting motion and noise. Records are versioned and CRC-protected, using a cyclic redundancy check to detect corrupted data. Optional Settings/ZMS persistence saves them through Zephyr’s settings and storage systems. Scheduling and event helpers cover fractional sample deadlines (timing samples at intervals that are not whole clock ticks), missed slots, debounce (ignoring repeated signals from one event), impact candidates (possible impacts), and GPIO wake notifications (signals from input/output pins). ### Other hardware adapters - **SAADC:** analog-to-digital conversion, with raw and millivolt reads and calibration. - **Switched battery divider:** a circuit for measuring battery voltage. - **PWM:** pulse-width modulation, with control of duty (the on-time proportion) and pulse length. - **Audio:** PDM (pulse-density modulation) capture into mono PCM16 (16-bit sound samples), capture cleanup, and PCM signal levels. - **Temperature:** die-temperature reads from the microcontroller (MCU) and IMU chips. ## Telemetry and OpenFloat Telemetry means sending measurements to another device. My transport support includes: - Fixed-configuration **SPI**, a wired interface between chips. - **UART**, a serial connection, with receive buffering and recovery when data is lost. - **COBS/CRC packets:** consistently delimited messages with corruption checks. - An **OpenFloat Bluetooth Low Energy (BLE) service** for wireless communication. On the host computer, Python reference codecs (message encoders and decoders), serial telemetry validation, and a UART packet echo probe (which sends packets back) support testing and integration. My related [OpenFloat Archery]() project uses bow-mounted motion sensing and a browser dashboard. This library provides reusable orientation, hardware, and telemetry components for that work. ## Examples and verification The repository includes **15 firmware examples**, native CTest suites (tests run on a host computer), and Python tests. Native tests build the production C code against simulated hardware and operating-system interfaces; the Python packet suite compares 1,028 independent vectors with the built C encoder and decoder. The reference firmware environment is **nRF Connect SDK v3.3.0**, targeting `xiao_nrf54l15/nrf54l15/cpuapp`. The [README]() links the example index, API contracts (the rules applications must follow), integration instructions, and hardware testing setup. ### Hardware testing limits Hardware validation results and remaining fixture requirements are recorded in the [verification record](). Those checks document the tested behavior; they do not establish absolute measurement accuracy. ## Current release **v0.1.0 is an experimental first release**, published October 1, 2026. Public APIs (the programming interfaces applications call) may change before v1.0. The code is Apache-2.0 licensed; Nordic SDK dependencies retain their own licenses and are installed separately. ## Related reading - [6×10 WS2812 Matrix for XIAO nRF54L15]() - [OpenFloat Archery]() - [Tab5 OS]()