OpenThread released by Google has been ported to several devices and platforms by the OpenThread team, silicon vendors, and the community. Build examples for all ported platforms are included in the OpenThread repository.
See Search Vendors for a searchable list of all vendor-supported platforms and community ports.
Support for each platform varies over time. Some platforms are tagged with the current level of support as identified by the OpenThread team. Untagged platforms have not been recently tested and may be considered as having "Limited Support."
|Full and basic support, as well as any Thread Certified Component that uses OpenThread. Many of these platforms have been tested and used by the OpenThread team, and are recommended for use in our demos and Codelabs.|
|These platforms have not been fully tested and may be missing some key functionality.|
|Not currently supported and may have issues running OpenThread. Use at your own risk.|
OpenThread is designed with portability and flexibility in mind. The code is portable C/C++ (C99 and C++03) that’s system architecture-agnostic due to a narrow abstraction layer. This abstraction layer means that OpenThread can run on either bare-metal or an OS. To date, OpenThread has been demonstrated to run on FreeRTOS, RIOT-OS, Zephyr OS, Linux, and macOS.
OpenThread's portable nature makes no assumptions about platform features. OpenThread provides the hooks to utilize enhanced radio and crypto features, reducing system requirements, such as memory, code, and compute cycles. This can be done per platform, while retaining the ability to default to a standard configuration.
OpenThread has a configurable build system with which a developer can enable or disable features as needed. Beyond the default GNU toolchain, the source is designed to work with a number of other popular toolchains like IAR and Visual Studio.
OpenThread supports both system-on-chip (SoC) and network co-processor (NCP) designs.
An SoC is a single-chip solution that has the combined RFIC (802.15.4 in the case of Thread) and processor, where OpenThread and the application layer run on the local processor.
An NCP design is where the application layer runs on a host processor and communicates with OpenThread via a serial connection using a standardized host-controller protocol we call Spinel. In this design, OpenThread can run on either the radio or host processor.
Single-Chip, Thread-Only (SoC)
In this design, the application layer and OpenThread run on the same processor. The application directly uses the OpenThread APIs and IPv6 stack.
This is the SoC design most commonly used for end devices. Because it is highly integrated into a single silicon, it has the lowest cost and lowest power consumption.
Single-Chip, Multiple-Interface (SoC)
When a SoC has multiple radios, such as 802.15.4 and Wi-Fi, or 802.15.4 and Bluetooth Low Energy (BLE), the application layer and OpenThread still run on the same processor. In the multiple-interface design, OpenThread leverages the shared third-party IPv6 stack via a raw IPv6 datagram interface.
Network Co-Processor (NCP)
The standard NCP design has Thread features on the SoC and runs the application layer on a host processor, which is typically more capable (but has greater power demands) than the OpenThread device. The host processor communicates with the OpenThread device via a serial interface (typically SPI or UART) over the Spinel protocol.
The benefit of this design is that the higher-power host can sleep while the lower-power OpenThread device remains active to maintain its place in the Thread network. And since the SoC is not tied to the application layer, development and testing of applications is independent of the OpenThread build.
This design is useful for gateway devices or devices that have other processing demands like IP cameras and speakers.
Radio Co-Processor (RCP)
This is a variant of the NCP design where the core of OpenThread lives on the host processor with only a minimal MAC layer "controller" on the device with the Thread radio. The host processor typically doesn’t sleep in this design, in part to ensure reliability of the Thread network.
The advantage here is that OpenThread can utilize the resources on the more powerful processor.
This design is useful for devices that are less sensitive to power constraints. For example, the host processor on a video camera is always on to process video.
Open platform issues
The following issues are currently open for OpenThread platforms: