DOCSEARCHbyAlgolia
Submit Docs

Alp SDK Documentation

website·Indexed 32 days ago

https://docs.alplab.ai

Software Development Kit for Alp hardware, including the E1M-X V2N-M1 module. Features handle-based wrappers for peripherals (GPIO, I²C, SPI, UART), IPC APIs via <alp/rpc.h>, and connectivity helpers. Includes the `tan` CLI tool for project scaffolding, building, and flashing, along with reference examples for AI camera pipelines, ROS 2 perception, and hardware validation.

Tokens
192.5K
Snippets
731
Records
1.4K
Agent score
59%

What's inside Alp SDK

  1. Overview of the Madgwick AHRS orientation filter

    The alp/ahrs.h library provides a caller-owned Madgwick orientation filter that fuses a 3-axis gyroscope and a 3-axis accelerometer into a drift-corrected orientation quaternion. The accelerometer pins roll and pitch against gravity to prevent the drift associated with raw gyroscope integration. Currently, only the IMU variant (gyro + accel) is available; without a magnetometer, yaw is not absolute and will drift around the gravity axis.
    #include <alp/ahrs.h>

  2. Overview of mproc low-level IPC primitives

    The mproc layer provides raw mailbox, shared-memory, and hardware-semaphore primitives for heterogeneous multi-core SoCs (such as Alif Ensemble, Renesas RZ/V2N, and NXP i.MX 9352). This is a low-level API; for framed cross-core RPC, developers should use <alp/rpc.h> instead. Use mproc when raw semantics are required to compose a custom protocol.

  3. Overview of the ALP Backend Dispatch Mechanism

    The ALP SDK uses a class-based backend system to provide portable surfaces for peripheral subsystems (e.g., ADC, SPI, inference). Each subsystem has a class name. Backends register themselves into a per-class linker section. At runtime, the class dispatcher identifies the best backend based on the active silicon reference and priority, caches the choice, and dispatches calls through an operations (ops) vtable. This mechanism is primarily used when adding new vendor ports or test doubles.

    #include <alp/backend.h>

  4. Overview of the Update Log API

    The Update Log API provides a portable, tamper-evident record of every firmware update applied to a device. It uses a hash-chained, monotonic-counter-anchored log to detect mutation, truncation, rollback, and reordering of update records. Depending on the SoC, this is implemented either as a software tier (tamper-evident) or a hardware-enforced tier (tamper-proof via TF-M Protected Storage and a non-decrementable counter).

  5. Overview of E1M-AEN Secure Boot Chain of Trust

    The E1M-AEN establishes a chain of trust starting from the Alif Secure Enclave ROM, which hands off to MCUboot. MCUboot verifies the application's ECDSA-P256 signature against a public key compiled into the bootloader before execution. If a signature is invalid or missing, the image is rejected, and the previous-good slot is maintained (swap-using-scratch).

  6. Overview of the Portable Math Unit (TMU) API

    The alp_tmu API provides twelve portable single-precision math primitives. All calls are stateless (no handles or initialization required). The API acts as a seam, allowing future SoCs to register hardware math accelerators without requiring application changes. On platforms without a dedicated hardware accelerator (such as AEN family or Yocto/baremetal), the API falls back to libm.

  7. Overview of A55 to M33 Inter-Processor Communication

    The E1M-X V2N and V2N-M1 SoM enables message exchange between the Cortex-A55 application cluster (Yocto Linux) and the Cortex-M33 system-manager core (Zephyr). This architecture uses a non-cacheable memory carve-out for RPMsg (Remote Processor Messaging) OpenAMP virtio rings, with the V2N hardware-mailbox doorbell serving as the notification side channel. This setup allows for a combination of deterministic real-time control on the M33 and rich application logic on the A55.

  8. Understand E1M specification coverage and constraints

    The E1M standard defines the mechanical envelope, electrical interface (power, reset, boot-strap), complete pinout (coordinates and default functions), and conformance criteria.

    Key Constraints:

    • Pinout: Pad-to-signal assignments are fixed at the default-function level, with GPIO as a universal secondary. Silicon-specific alternate functions are handled via per-SoM manifests and are not part of E1M conformance.
    • Out of Scope: The spec does not cover internal SoM design (beyond mandatory components), per-SoM peripheral mappings beyond default/GPIO, or carrier-board reference designs.

  9. Package a model for multiple NPUs using .alpmodel

    The .alpmodel container allows a single model artifact to be portable across different NPUs (e.g., Ethos-U, DRP-AI3, DEEPX DX-M1) and CPU fallbacks. The SDK's loader automatically selects the correct backend blob at runtime based on the active SoC and available hardware resources. Note that <alp/model.h>, alp_inference_open_alpmodel(), and the .alpmodel container are currently marked as [ABI-EXPERIMENTAL].

  10. E1M-AEN Operating Conditions and Power Architecture

    The E1M-AEN module is specified for a single ambient temperature range of − 40 °C to +85 °C. Regarding power architecture, no power-rail sequencing is required as the PMIC manages rail bring-up. This is distinct from the carrier-side control-signal bring-up steps defined in the Power-Up & Reset Sequence.

  11. Monitor power rails on E1M-X EVK using INA236

    The v2n-power-monitor example application provides a live per-rail power table for the E1M-X EVK. It uses the on-board INA236 current/voltage monitors via a shared I²C bus to print bus voltage, current, and power once per second. Note that these monitors exist only on EVK carriers and are not present on production E1M-X SoMs; they are intended for bring-up and demo purposes rather than production telemetry.

  12. E1M EVK Hardware Overview

    The E1M EVK is a 35 × 35 mm carrier board designed for E1M-AEN and E1M-N93 family modules. It includes the following populated peripherals:

    • IMU/Sensors: 6-axis IMU (lsm6dso), 3-axis accelerometer (lis2dw12), gyroscope (bmi323, icm42670), barometric pressure sensor (bmp581), and temperature sensor (tmp112).
    • Power/IO: Current monitors (ina236) and I/O expander (tcal9538).
    • Display/Camera: Monochrome OLED (ssd1306), small colour OLED (ssd1331), and camera (ov5640 MIPI CSI + cam_mux).
    • Audio: Speaker amp (tas2563) and PDM microphone (pdm_mic).
    • Other: Rotary encoder, RGB LED, button-LED helper, JTAG/SWD header, and BOOT/reset/module-enable controls.