From Two Boards to One Die: How a Decade of Embedded Convergence Killed My Teknofest Hack

An engineer’s view on the architectural shift that turned every "Arduino + Raspberry Pi" project into a relic.

The Underwater Vehicle That Taught Me What Embedded Was

A few years ago, during my time on a Teknofest underwater vehicle team, I was the engineer wrestling with a problem that, in hindsight, was never really about my skills. It was about the architecture I had to work with.

The vehicle needed two things at once: hard real-time control of the thrusters and motors, and high-level autonomy — vision processing, mission logic, sensor fusion. There was no single board on the market — at least not within a student team's budget — that could do both well. So we did what every robotics team did in those years: we strapped an Arduino to a Raspberry Pi and tried to make them talk.

The Arduino handled the motors. The Pi ran the brain — Python, OpenCV, the autonomy decisions — and shouted commands across to the Arduino over serial. We spent more time fighting the link between the two boards than we ever spent on the underwater problem itself. Bash on the Pi side. AVR C on the Arduino side. A sensor fusion algorithm we were implementing from a paper we barely understood, on a microcontroller without a floating-point unit.

It worked, mostly. We learned an enormous amount. And looking back now, with six years of professional embedded experience behind me, I see clearly what we were actually learning: the cost of a problem that semiconductor companies hadn't yet solved.

That problem is now being solved. Quietly, over the last decade. And the way it's being solved is reshaping what an embedded engineer needs to think about in 2026.

Why We Needed Two Boards

To understand the shift, you have to understand the constraint that forced the hack in the first place.

A microcontroller — an Arduino-class chip, an STM32 F0, a PIC — is good at one thing: responding to the physical world in predictable, microsecond-scale time. It runs from flash, has a few kilobytes of RAM, no memory management unit, and no real operating system. You can guarantee that an interrupt will fire within a known number of clock cycles. That guarantee is everything when you're spinning a motor or sampling a sensor.

A microprocessor — Raspberry Pi class, Cortex-A — is good at the opposite. It runs Linux, has gigabytes of RAM, a full networking stack, Python, OpenCV. But it cannot guarantee anything about timing, because Linux is a non-real-time OS by design. The kernel can preempt your loop whenever it wants.

So we paired the two. The MCU did the real-time work. The MPU did the brainwork. They talked to each other over UART, SPI, or USB. The integration was painful, the latency was unpredictable, and the bill of materials was twice what it needed to be.

For about fifteen years, this was simply how embedded systems with any complexity were built.

The Decade of Slow Convergence

The hardware industry noticed the pain, but the convergence didn't happen overnight. It came in stages.

First, MCUs got faster and gained real DSP capability. Cortex-M4 added a floating-point unit. Cortex-M7 went past 500 MHz with a proper cache. The STM32H7 series put an M7 and an M4 on the same die — the first hint that "one MCU is enough" was about to become "one MCU has multiple cores for different jobs."

In parallel, application processors started reaching down toward real-time. Vendors began shipping chips that combined a Cortex-A application processor and a Cortex-M real-time processor on the same die, sharing memory and peripherals.

The pattern was clear. The boundary between "real-time control chip" and "application processor" was being deliberately dissolved, one product generation at a time.

But the third domain — machine learning acceleration — was still external. You bolted on a Google Coral or a Hailo accelerator to do inference. Until very recently.

The Thesis: One Die, Three Domains

The architecture now emerging is what some vendors are calling a fusion processor — a single chip integrating three previously separate computational domains:

A real-time control domain — one or more Cortex-M cores running an RTOS like Zephyr or FreeRTOS, handling deterministic I/O, motor control, sensor sampling.

An application domain — one or more Cortex-A cores running Linux, handling networking, UI, complex business logic.

A neural processing domain — a hardware NPU dedicated to running ML inference at far better energy efficiency than CPU-only execution.

Two recent products make this concrete, and I want to talk about them carefully — because they're both new enough that I'm reading about them like everyone else, not deploying them.

The Arduino UNO Q, announced October 7, 2025 alongside the Qualcomm acquisition of Arduino, pairs a Qualcomm Dragonwing QRB2210 (quad-core Cortex-A53 running Debian Linux) with an STMicro STM32U585 microcontroller for real-time control. One board, dual-brain, $44 retail. It is, almost literally, my Teknofest hack reduced to a single PCB — and sold at a price point that makes the original two-board approach hard to justify for new student projects.

The Alif Semiconductor Ensemble E6 and E8 push the idea further. According to Alif's published material, the E8 combines Cortex-A32 cores for Linux, Cortex-M55 cores for real-time and DSP, an Ethos-U55 NPU for vision inference, and an Arm Ethos-U85 NPU explicitly designed to accelerate transformer-based networks. Alif reports the chip can run at very low microamp-class currents in stop mode, and that running inference on the Ethos-U85 consumes dramatically less energy than CPU-only execution. I haven't held one of these chips yet, so I'm passing along what they say — but if the production silicon delivers anywhere near these numbers, it changes what's possible on a battery-powered edge device.

This is not a future roadmap. The maker version (UNO Q) is on shelves. The industrial version (Alif Ensemble) is sampling. We are in the early months of this architecture becoming the default.

Why the Convergence Matters Beyond Convenience

It's tempting to look at this and say "great, fewer boards on my BOM." That misses the size of the shift.

Edge AI becomes practical on battery. The cloud-dependency of recent AI-style applications wasn't really a software choice; it was a power-budget consequence. A chip with a hardware NPU built for transformer networks changes that constraint at the hardware level. On-device inference that was barely feasible two years ago becomes a normal part of a product spec.

Sensor fusion stops being a wiring problem. What we struggled with at Teknofest — getting IMU, camera, and motor encoder data into one coherent state — was 80% a wiring and timing problem, and only 20% a math problem. On a fusion chip, all the sensors connect to the same SoC and the data lives in shared memory. The math is still hard; the plumbing is no longer the bottleneck.

The role of the embedded engineer is expanding. For a long time, "embedded" and "Linux" were two career tracks with limited overlap. On a fusion chip, the same engineer is increasingly expected to think about both sides — the real-time core and the Linux application core, and the boundary between them. That boundary is now a software concern, not a board-to-board cable. For those of us who started on the MCU side, that's a real direction to grow into. I'm at the beginning of that growth myself.

A Note on Defense and Autonomy

It doesn't take much imagination to see why this architecture matters for unmanned systems. Drones and autonomous vehicles have traditionally needed several separate boards — one for flight control, one for higher-level autonomy, sometimes another for ML — and collapsing those into a single die has obvious benefits for weight and power. Given how central unmanned systems are to the Turkish defense industry, this is a shift worth keeping an eye on. I'll leave the operational implications to people closer to those programs.

A Note on What I'm Learning Next

I won't pretend to be an expert on the parts of this stack I haven't worked with yet. I've spent six years on the MCU side — STM32, Silicon Labs, ESP32, BLE stack development, TinyML on resource-constrained wireless SoCs. The Cortex-A side, the Linux side, the NPU programming side — those are the directions I'm growing into now. My current learning thread is Zephyr (which is increasingly the RTOS designed for these heterogeneous multi-core architectures), and beyond that, the Linux side of the fusion architecture is on my list.

I'm planning to write about each piece as I learn it. Not as the expert handing down knowledge, but as a working engineer in 2026 trying to keep up with where the silicon is going. If you're on the same path, I'd rather we figure it out together than pretend any of us has it solved.

To My Teknofest Self

If I could send a note back to the student sitting in a lab at 3 AM, fighting a serial connection between an Arduino and a Raspberry Pi while a half-built underwater vehicle dripped on the bench:

The integration pain you're experiencing right now is teaching you something the easy version never could. Hold on to that intuition. In a few years the boards will start merging into a single die, and the engineers who understand both sides of that boundary will be the ones the industry needs most. You're learning the hard way, but you're learning the right thing.

The hardware is catching up. The architecture I wished existed back then is showing up on benches now. The work isn't easier — it's just moved up one layer of abstraction.

What architectures are you building on right now? And who else remembers the joy and pain of the two-board era? Let's talk in the comments.