Module Catalog¶

The NSX registry ships a curated set of built-in, first-class modules that cover SDK integration, platform plumbing, peripherals, profiling, and common runtime helpers. Every module listed here is discoverable through the CLI and eligible for normal nsx module add workflows.

# List the full catalog from your terminal
nsx module list --registry-only

Need a module that isn't listed here?

NSX supports custom and third-party modules alongside the built-in catalog. You can register a local directory or any git repo as a module for your app — no changes to the upstream registry required.

See Custom Modules for registration commands, scaffolding, and end-to-end authoring guidance.

What First-Class Means¶

In NSX, a first-class module is a module that is:

1. present in the packaged registry
2. discoverable through the CLI
3. eligible for normal nsx module add workflows
4. part of the supported, documented NSX module model

That is separate from how an app builds it. Apps still build from vendored copies in app/modules/ after resolution.

Useful commands:

nsx module list --registry-only
cd <app-dir>
nsx module list --app-dir .

All Modules¶

Use the built-in search field above the table to filter modules, then adjust the page size selector as needed.

Most first-class modules for the current Ambiq families are sourced from the unified nsx-ambiq-sdk monorepo. That includes the SDK providers, HAL/BSP wrappers, CMSIS/startup integration, and most common runtime and peripheral modules across the r3, r4, and r5 lines.

Only a small set of first-class modules are currently sourced from separate repositories, notably nsx-pmu-armv8m, arm-cmsis-nn, nsx-tflite-micro, nsx-cmsis-nn, nsx-helia-rt, nsx-nanopb, helia-dsp, nsx-physiokit, nsx-tileio-ble, nsx-tileio-usb, nsx-sensors, nsx-ethos-u-driver, and the packaged board/tooling content that ships directly from neuralspotx.

Module Families¶

The catalog is easier to navigate if you read it by role rather than by raw module name.

SDK Provider Modules¶

These define the upstream SDK family and revision used by the rest of the dependency graph.

SDK Wrapper and Platform Integration Modules¶

These adapt raw SDK content into the NSX build and target model.

Board Modules¶

Board modules are selected automatically when you create an app for a specific target. They capture board-level wiring and pin configuration.

This table has its own search and pagination controls.

Board modules are first-class because they are packaged and registry-backed, but they are usually selected indirectly through app creation or target configuration rather than being added manually.

Runtime and Helper Modules¶

These make up the common reusable runtime layer for NSX apps.

Migration-friendly portable helpers such as nsx_printf, nsx_delay_us, and interrupt master enable/disable now live in nsx-core directly rather than in a separate first-class nsx-portable-api module.

Profiling and Instrumentation Modules¶

These are the current first-class path for performance instrumentation.

External First-Class Modules¶

These are still part of the built-in NSX catalog, but they are sourced from separate upstream repositories instead of the unified nsx-ambiq-sdk monorepo.

NPU / ML Acceleration Modules¶

Ethos-U NPU support spans two modules that live in two different repositories: a runtime-agnostic core-driver integration sourced from its own standalone repo, and the SoC-specific glue that lives in the nsx-ambiq-sdk monorepo.

Cross-repo module dependencies¶

A module's nsx-module.yaml depends.required list can name a module that lives in a different repository: the registry lockfile pins each module's source project and revision independently and materializes them side by side under modules/ at workspace assembly time (see the metadata model for the general mechanism). nsx-npu is the worked example — it ships from the nsx-ambiq-sdk monorepo but requires nsx-ethos-u-driver from its own standalone repo, so an app created with nsx create-app --template npu-tflm lists only nsx-helia-rt and nsx-npu in its nsx.yml, and nsx-ethos-u-driver is pulled in transitively.

Peripheral and Bus Modules¶

These expose common device and board-access surfaces without forcing those helpers into the baseline runtime core.

Legacy nsx-peripherals is no longer a first-class packaged module. Its useful pieces were retired into focused unified surfaces such as nsx-power, nsx-psram, and board button facts layered on nsx-gpio.

Wireless / BLE Modules¶

Bluetooth LE support is split into a low-level host stack and an app-facing convenience API, so apps that only need the stack (or want to bring their own wrapper) don't have to pull in both.

What Is Not First-Class Yet¶

Some module candidates are not part of the packaged catalog yet. That usually means they are still app-local custom registrations, local development modules, or future migration targets from legacy neuralSPOT.

Working with Modules¶

Add a module to your app¶

cd my-app
nsx module add nsx-uart

NSX resolves the full dependency closure, validates board/SoC compatibility, and vendors the module into my-app/modules/.

Inspect a module¶

nsx module describe nsx-audio

Search by keyword¶

nsx module search "uart serial" --app-dir .

Remove a module¶

cd my-app
nsx module remove nsx-uart

Related Pages¶

• Modules Overview — terminology and CLI workflows
• Custom Modules — register, scaffold, and validate third-party or local modules
• Module Model — architecture deep-dive