Arduino marked the first anniversary of UNO Q on October 8, a useful checkpoint for a board whose defining feature is not one benchmark but a split computing model. Current Arduino documentation places Debian Linux on a Qualcomm Dragonwing QRB2210 microprocessor and real-time Arduino work on an STM32U585 microcontroller running Zephyr OS.
The anniversary post looks back at the board’s first year. The more consequential engineering detail is how the two processors divide responsibility: Linux can host applications, networking and higher-level inference, while the MCU owns timing-sensitive control.
Two processors, two timing models
Arduino’s datasheet identifies the QRB2210 as a quad-core Arm Cortex-A53 processor running at up to 2.0 GHz. The STM32U585 uses an Arm Cortex-M33 core running at up to 160 MHz, with 2 MB of flash and 786 KB of SRAM. Those clock figures are not a direct performance comparison; the devices solve different problems.
Linux provides process isolation, files, packages and familiar development tools, but it is not a hard real-time operating environment. Zephyr on the MCU is the appropriate side for bounded-latency pin changes, actuator loops and sensor sampling that cannot tolerate a userspace scheduling pause.
Bridge turns the split into one application boundary
Arduino documents its Bridge mechanism as communication between the Linux microprocessor and the microcontroller. That allows an application to keep camera, network or model code on Debian while exposing selected measurements and commands to an Arduino sketch.
The boundary still needs explicit design. A Linux process should not stream every raw event across the bridge if the MCU can reduce it locally. Conversely, the MCU should not absorb file handling or network policy that Linux already implements well. Message rate, timeout behavior and the safe state after either processor restarts remain application decisions.
The current platform is broader than a classic UNO
Qualcomm’s hardware page confirms the QRB2210 and STM32U585 pairing. Arduino’s current product material also positions UNO Q for camera, display and audio work alongside familiar shield and sketch workflows. That combination makes software ownership more important than on a single-MCU board: each peripheral and control path needs a clear processor, update path and failure response.
The anniversary does not prove field reliability or application performance. It does establish that UNO Q’s durable identity is the coexistence of a general-purpose Debian computer and a real-time Arduino controller. Projects that benefit most are those that genuinely need both, rather than workloads that fit completely on one side.
