Overview
Migrations are the work everyone avoids. A vendor changes a product line, an RTOS goes EOL, a part hits a 52-week lead time, a new chip shows up that's 30% cheaper at scale. The technical answer is “port the firmware,” and the team answer is usually “we'll get to it next quarter,” for many quarters. Embedder shrinks the migration to something you actually do.
What this white paper covers
- The migration tax.
- What the agent does on both sides.
- Diff-driven migration.
- Common patterns — cross-vendor, HAL evolution, RTOS, language.
- Vendor coverage.
- Getting started.
The migration tax
A port is high-risk and low-glamour. The reward for a clean migration is “same product, different chip,” which no customer celebrates. The downside of a botched one is a board that doesn't boot or a regression that only surfaces in the field. So teams defer until they can't — which is usually the worst possible time to do the work.
What the agent does
On the source side it reads the existing firmware, reference manual, errata, schematic, and HAL conventions. On the target side it reads the new chip's reference manual, SVD device file, and the new board's schematic. It maps the peripherals — UART here, UART there; I²C with these pins, I²C with those pins; PWM pair on this timer, PWM pair on that timer — and proposes a port that preserves behavior while translating to the new HAL, RTOS primitives, or language.
For each translated module you get the new code, an explanation of what changed and why with citations, and (where Hardware Interaction is set up) a HIL test that exercises the migrated path on real silicon — including bus-level verification that the same waveform appears at the same pin on the new part.
Diff-driven migration
The deliverable is a PR (or a series of PRs) your team reviews like any other change. Not a black-box codebase regeneration — an auditable, commit-by-commit set of edits with the agent's reasoning attached. Your engineers stay in the loop on every decision that matters.
Common patterns
- Cross-vendor swap — STM32 ↔ NXP ↔ ESP32, TI → STM32, Infineon AURIX moves within the TriCore family.
- HAL evolution — STM32 HAL1 → HAL2; vendor HAL to custom; bare-metal to vendor HAL.
- RTOS port — FreeRTOS to Zephyr, ThreadX to FreeRTOS, bare-metal to RTOS. Native FreeRTOS and Zephyr support on the target side.
- Language port — C to Rust where the team is moving safety-critical paths off raw C.
- iLLD / vendor IP port — porting vendor code examples between MCU family members (e.g., AURIX TC387 → TC4D7 / TC375).
Vendor coverage
Embedder's catalog spans 500+ MCUs and 3,000+ peripherals across STM32, NXP, ESP32, Infineon, Nordic, TI, and others. If both sides of your port are in the catalog, the agent has the reference manuals and SVD files already indexed. If they're not, the custom upload flow brings new parts into scope.
Who it's for
- Teams facing EOL or supply-driven chip changes.
- Companies switching vendors for cost, supply, or capability reasons.
- Programs modernizing to a new RTOS across multiple product lines.
- Safety-critical teams moving from C to Rust on hot paths.
Getting started
The fastest path is a scoping call where we look at the source and target hardware and estimate the work. Book a call.