TI expands Zephyr RTOS support across its full embedded portfolio

On October 1, Texas Instruments (TI) announced that its broad embedded portfolio now supports the Zephyr Project, the open-source real-time operating system (RTOS) hosted by the Linux Foundation. The scope covers microcontrollers (MCUs), microprocessors (MPUs) and wireless connectivity devices. The date is worth noting too: the announcement went out the same day the Zephyr Project raised TI’s membership tier.

In product terms that spans BLE MCUs, general-purpose MCUs, real-time motor and power-control MCUs, SimpleLink wireless, MSPM0 and Cortex-R platforms, with cores running from ultra-low-power Arm Cortex-M0 devices up to high-performance Cortex-M33. It is not support bolted onto one or two flagship chips: TI is placing an entire map — from low-power wireless to real-time control — inside a single software framework, described officially as a unified, production-ready experience.

Fragmented software ecosystems are the real problem

Embedded software has long been fragmented: every vendor brings its own SDK, build system and driver model, and the same feature has to be rewritten for a different chip. Switching semiconductor suppliers often means rewriting low-level code, relearning the toolchain and re-verifying the test flow. TI puts that problem front and centre — developers often have to rewrite code simply because they changed chip vendors. That duplicated effort never shows up in anyone’s earnings report, yet it slows iteration and raises engineering cost.

Zephyr is positioned as the opposite: a vendor-neutral open-source RTOS hosted by the Linux Foundation, built around consistency across architectures and vendors. It is designed for resource-constrained devices — small, configurable and portable across many processor architectures, which is precisely the precondition for several vendors to adopt it at once. To see why it matters, remember where an RTOS sits: it schedules tasks, manages memory and interrupts and provides the driver framework, the foundation between application code and silicon. Replace the foundation and the layers above usually move too. That is also why an open-source RTOS’s governance and long-term maintenance commitments get questioned again and again.

The first benefit TI lists is “no workflow disruption”: developers already familiar with Zephyr can keep their existing codebase and toolchain when moving to TI silicon, without giving up their open-source workflow, while gaining access to a broader, higher-performing hardware portfolio. That matters most to small and mid-sized teams, which rarely have the resources to maintain a separate low-level codebase per vendor; evaluating a new chip may shrink from “get the low-level layer working” to “tune the drivers and performance”.

Upstream first: code enters the community before the SDK

On collaboration, TI takes an upstream-first approach: it contributes code and board support to the official Zephyr repository while maintaining a downstream repository where new boards and features appear first before moving upstream. Board support means describing a chip’s clocks, pins, peripherals and interrupts inside a neutral code framework so higher-level drivers can be reused — no small amount of work. That is why a vendor’s long-term willingness to maintain matters more than a one-off code drop. The route has an implicit premise as well: the upstream repository’s cadence is set by the community, and no single vendor can speed it up or freeze it on its own.

The most tangible product of that route is upstream code review: TI’s code is vetted by the Zephyr community before any SDK release, giving developers a stable baseline that will not shift suddenly during product ramp-up. For volume customers, having low-level code refactored upstream halfway through a project is a real risk, and reviewing beforehand is aimed squarely at it.

Tools and methods follow the existing Zephyr ecosystem: the Twister and Ztest test frameworks, CI/CD in public GitHub repositories, and GCC, GDB, OpenOCD and VS Code. The point of public CI/CD is early access — new resources and features are often usable and testable long before they land in the final SDK, without waiting for a quarterly release window. Coverage extends beyond silicon too: developers can fold TI’s embedded and analog parts into a system design without leaving the Zephyr environment.

For a vendor, going upstream is not free: once code enters the community it can no longer be changed at will — changes go through review and must stay backward compatible. Accepting that constraint is itself a long-term commitment, and a useful signal for judging whether such cooperation will last.

Long lifecycles and compliance: why CRA keeps coming up

TI’s other set of selling points is long-lifecycle maintenance: validated releases, migration guides and backward-compatibility notes to lower the long-term maintenance burden, with device life cycles running beyond 10 years. For long-lifecycle products in industry and automotive, that promise usually weighs no less than a performance figure. Behind that sits one benefit of an open-source RTOS — the software stack does not die when a particular chip is discontinued, so a vendor no longer has to maintain a separate closed-source SDK for every product line and can concentrate maintenance effort in one place.

Compliance is the announcement’s other main thread: TI writes “compliant with the EU Cyber Resilience Act (CRA)” into the product positioning. On the public record, the CRA is EU regulation setting cybersecurity requirements for products with digital elements, one core idea being that such products stay maintainable and updatable throughout their support period — extra security and maintenance obligations for vendors selling into Europe. TI argues that because the platform is based on Zephyr and it regularly updates its SDKs to patch vulnerabilities, customers can ease that burden.

To be clear, that is TI’s own positioning rather than a third-party certification finding. For teams preparing to enter the European market, a vendor’s built-in compliance narrative is one selection input — but the regulation’s requirements still have to be checked against your own product, and the validation material against your own firmware branch and shipping configuration.

Another announcement on the same day

On the same day, the Zephyr Project announced that TI and Infineon have been upgraded to Platinum members, pledging more investment in technology, infrastructure and community. Read together, the two announcements point to one shift: the RTOS is becoming a shared layer that chip vendors compete over, and their investment now lands not only in their own SDKs but in the open-source RTOS itself.

One judgement follows: once the low-level software moves upstream, “whose board support is maintained longer, and whose contributions the community accepts” gradually becomes a line on the selection sheet. That is good for developers — migration cost drops from rewriting to reconfiguring — while for vendors the contest shifts from SDK feature lists to long-term credibility in an open-source community. That is arguably the most memorable point of the message.