analogdevicesinc/no-OS for Bare-Metal ADI Systems

What no-OS solves for processor and microcontroller designs

analogdevicesinc/no-OS addresses a specific embedded-systems gap. Many Analog Devices products are peripherals connected to a digital engine such as an FPGA, microprocessor, or microcontroller. The README describes the repository as a bare-metal software framework for systems without an operating system. That makes it relevant when the target is a lower-end processor that cannot run Linux, or when the design does not otherwise use Linux.

The framework is for engineers integrating ADI components into embedded hardware. The intended user needs device drivers, board examples, and a way to make those drivers work across different digital engines. The README specifically lists Xilinx, Intel/Altera, Maxim, STM32, ADuCM3029, and Raspberry Pi Pico as examples of platforms covered by the hardware abstraction layer. The list should not be treated as a promise that every peripheral and every board is interchangeable. The documentation directs users to select a project matching their evaluation board.

There are three distinct layers in the repository. The `drivers/` directory contains device-driver code, `include/` and `capi/` contain interfaces and platform-facing components, and `projects/` contains examples intended to be built and flashed. The repository also includes board configuration, communication, JESD204, networking, library, test, and build-related directories. Based on that layout, no-OS is not one driver or one application. It is a collection of reusable components organized around particular hardware and software targets.

Portable drivers and the hardware abstraction boundary

The central design choice is the separation between an ADI device driver and the hardware underneath it. The README describes platform-agnostic device drivers for ADI components and a hardware abstraction layer that allows the same driver to run on supported digital engines. In practical terms, the driver can represent device behavior such as configuring and communicating with a peripheral, while the abstraction layer handles the differences between an FPGA platform, an STM32-based board, a Maxim target, or a Raspberry Pi Pico target.

This boundary is useful because bare-metal development does not have a single runtime environment. There is no operating system to provide a common device model, filesystem, process model, or standardized hardware interface. Each target has its own processor architecture, peripheral map, compiler toolchain, linker setup, and board support. The HAL gives the driver code a common platform-facing interface, but it does not erase those target-specific requirements. A driver that is portable at the source level still needs the correct implementation and configuration underneath it.

The repository's `projects/` examples are therefore part of the architecture, not merely demonstrations. They show how drivers, board configuration, libraries, and target-specific startup or build settings fit together. The `tests/` directory also indicates that test material is part of the project, although the README does not document a universal test command. The Drivers guide is the appropriate place to investigate the internal driver structure and the process for creating or porting a driver.

Cloning the repository and selecting a buildable example

The documented first step is to clone the repository. This command retrieves the current `main` branch, so it gives access to the latest code rather than the latest release branch. The README separately advises using the latest release branch when the most stable codebase is required.

The first command is:

git clone https://github.com/analogdevicesinc/no-OS

After cloning, the README does not provide one universal build command. It directs the engineer to the platform-specific Build Guide, then to the projects list, and then to the drivers list. That distinction matters. A bare-metal C project cannot be compiled meaningfully without knowing the processor, board, compiler, linker configuration, and programming hardware. The repository contains CMake files and configuration directories, but those entries do not by themselves establish a single command that works for every target.

A first real use therefore consists of selecting a project that matches the evaluation board, following that platform's Build Guide, and then building and flashing the resulting image. The README says that supported evaluation-board projects are ready to build, but it does not document a universal flash command. Do not substitute an arbitrary programmer command or assume that a project for one listed platform can be built for another.

Driver, board, and project organization

The top-level structure gives engineers several entry points. `drivers/` is the obvious location for ADI component drivers, while `projects/` holds examples. `board_configs/` appears to contain target or board configuration, and `libraries/` contains supporting library code. The `iio/`, `capi/`, `include/`, `network/`, and `jesd204/` directories indicate that the framework covers more than register-level device access. They suggest support for interfaces and system components beyond a single peripheral, although the README does not specify every interface or its maturity.

This breadth affects adoption. A team looking for a Linux userspace driver may find that the repository is not aligned with its execution model. A team building an FPGA or MCU data path may find the hardware abstraction and example projects more relevant. The framework does not replace the target's own board support package, timing design, interrupt configuration, clock configuration, or signal integrity work. It provides software building blocks around those hardware concerns.

The `Kconfig` file and `CMakePresets.json` indicate configuration-aware build organization, but the README does not explain the available configuration symbols or presets. That makes source inspection necessary before assuming that a particular board can be enabled with a documented flag. The supported project list and Build Guide should be consulted first, followed by the relevant files in `board_configs/` and `projects/`.

Maintenance, releases, and license obligations

The repository is not archived. Its last push was on 2026-10-15, and the release history includes `admt4000-v1.0.0` dated 2026-09-21, `last_commit` dated 2026-07-02, and `swiot1l-v1.1.0` dated 2025-10-24. The README tells users that `main` contains the greatest and latest code, while the latest release branch is intended for the most stable codebase.

That distinction affects upgrade planning. Moving from a release branch to `main` may expose newer drivers or project changes without the stability associated with the release branch. The repository also contains many platform-specific directories, so an upgrade can require checking board configuration, build settings, and example migration notes. The README does not describe a compatibility matrix, a long-term-support policy, or the effort required to port a project across driver releases.

The repository declares a custom license that GitHub cannot classify, with details in the `LICENSE` file. There are also `LICENSE_BSD`, `COPYING`, and `LICENSES/` entries at the top level. This licensing layout makes a legal review part of adoption for commercial or redistributed firmware. The repository overview alone does not establish which files carry which terms, and this review does not provide legal advice. Check the relevant license file for every driver, library, and copied dependency that will enter a product.

Where no-OS is the wrong choice

The clearest limitation is the absence of a general operating-system environment. no-OS is intended for systems without an operating system, so it should not be judged as a replacement for a Linux userspace driver or a conventional application framework. A product that expects a kernel, standard Linux device interfaces, or operating-system services is outside the stated target, even if an ADI peripheral is involved.

There is also no universal build path in the documented getting-started procedure. The user must supply the platform-specific toolchain and select a matching evaluation-board project. This is a real constraint for teams that want a vendor-neutral build environment or expect one command to generate firmware for every supported target. The hardware abstraction can reduce driver changes, but it cannot remove differences in startup code, linker scripts, memory maps, peripherals, and programming tools.

Compared with the operating-system-based approach described for higher-end microprocessors, no-OS operates closer to the hardware and leaves more platform work with the integrator. That is an advantage when Linux is unavailable or unnecessary. It is a disadvantage when a product depends on an existing OS ecosystem, reusable kernel infrastructure, or a large software development environment.

A practical adoption boundary

Engineers should adopt no-OS when the target is a supported bare-metal FPGA or microcontroller design, the ADI peripheral is part of the product, and board-specific firmware is acceptable. The framework is a sensible fit for reference-based development because it provides device drivers, a HAL, and ready-to-build projects instead of requiring every integration to start at the register level.

A team should not adopt it merely because it contains an ADI driver name. It may be the wrong tool if the product runs Linux, if the chosen processor has no supported project, if the required protocol or board configuration is absent, or if licensing terms do not fit the intended distribution. The README does not confirm whether every driver is portable to every listed platform, so portability must be checked against the driver documentation and the relevant project.

The first verification should be concrete: identify the evaluation board, locate its project, read the Build Guide for that processor, inspect the required license files, and confirm that the selected driver supports the device and communication path needed by the design. For a release-oriented build, compare the chosen release branch with `main` before adopting a specific revision.

Editorial conclusion

Adopt no-OS when the target processor cannot run Linux and the system needs ADI peripheral drivers with reusable hardware-specific examples. Do not treat it as a portable application framework or assume that one repository build works across every supported board. First verify the matching evaluation-board project, its platform toolchain, the required hardware support, and the license terms in LICENSE before committing to the repository.

Frequently asked questions

Official sources

1. analogdevicesinc/no-OS on GitHub
2. Issues
3. Project website
4. README
5. Releases