Arduino UNO Q 双脑开发初体验：用 Qualcomm Linux 控制 STM32 实时硬件

黑妹天下第一乖 2026-09-20 11:55:39

设备：Arduino UNO Q
MPU：Qualcomm Dragonwing QRB2210
MCU：STM32U585
系统：Debian Linux + Zephyr/Arduino
目标：搞清楚 UNO Q 的“双脑架构”，并完成一次 Linux → MCU 的跨处理器控制。

1. UNO Q 和传统 Arduino 最大的区别是什么？

第一次拿到 Arduino UNO Q，最容易产生的误区，就是把它理解成“性能更强的 Arduino”，实际上它已经不是传统意义上的单 MCU 开发板。
UNO Q 同时搭载了 Qualcomm Dragonwing QRB2210 和 STM32U585：QRB2210 负责 Linux、Python、AI、多媒体和网络等高层任务，而 STM32U585 负责 GPIO、PWM、ADC、传感器以及实时控制，官方将这种设计称为“双脑架构”。

简单理解：

任务	更适合运行的位置
Python / Linux 应用	QRB2210
OpenCV / AI	QRB2210
网络服务	QRB2210
GPIO	STM32U585
PWM	STM32U585
ADC	STM32U585
电机实时控制	STM32U585

这其实非常适合机器人，Linux 负责“思考”，MCU 负责“执行”。

2. Arduino App Lab 是什么？

UNO Q 推荐使用 Arduino App Lab，它和传统 Arduino IDE 最大的区别在于，一个 App 可以同时包含：

Linux 侧 Python 程序；
MCU 侧 Arduino Sketch；
AI 模型或其他 Brick；
Linux 和 MCU 之间的通信逻辑。

官方文档中，App Lab 会负责构建 Linux 应用、编译 MCU 程序、部署 Brick，并统一启动整个应用。所以以后开发 UNO Q 时，可以把一个项目理解成：

UNO Q App
├── python/
│   └── main.py
│
├── sketch/
│   └── sketch.ino
│
└── Bricks
    ├── AI Model
    ├── Camera
    └── Web Service

3. 先验证 MCU 是否正常

第一次使用建议不要直接上 AI，先在 Arduino App Lab 中打开 Blink 示例，点击右上角 Run。如果板载 RGB LED 能正常闪烁，说明：

App Lab
   ↓
编译 Sketch
   ↓
STM32U585
   ↓
 GPIO
   ↓
  LED

这条最基础的链路已经正常，官方用户手册也把 Blink 作为 UNO Q 的基础硬件验证步骤。

4. 真正有意思的地方：Linux 控制 MCU

如果只是让 STM32 自己闪 LED，其实和普通 Arduino 没有本质区别，UNO Q 真正值得玩的地方，是：

Qualcomm QRB2210
      │
    Linux
      │
   Python
      │
   Bridge/RPC
      │
 STM32U585
      │
    GPIO

Linux 和 MCU 之间通过 Bridge RPC 进行通信，例如我们可以让 Python 每隔一段时间向 MCU 发送一次 LED 状态。

Linux 侧：

from arduino.app_utils import App, Bridge
import time

led_on = False

def task():
    global led_on

    led_on = not led_on
    Bridge.call("led_write", led_on)

    time.sleep(0.8)

App.run(user_loop=task)

MCU 侧：

#include <Arduino_RouterBridge.h>

void ledWrite(bool on)
{
    digitalWrite(LED_BUILTIN, on ? LOW : HIGH);
}

void setup()
{
    pinMode(LED_BUILTIN, OUTPUT);

    Bridge.begin();
    Bridge.provide("led_write", ledWrite);
}

void loop()
{
}

这样 LED 的控制逻辑就不再由 MCU 自己决定，而是：

Python → Bridge → STM32 → GPIO。

5. 为什么要绕这么一圈？

有人可能会问：
既然 STM32 自己就可以控制 LED，为什么还需要 Qualcomm？
因为真正的项目不会只是闪灯，例如做一个视觉巡检机器人：

USB / CSI Camera
        ↓
Qualcomm QRB2210
        ↓
目标检测模型
        ↓
发现异常
        ↓
Bridge
        ↓
STM32U585
        ↓
电机 / 蜂鸣器 / 继电器

Linux 侧负责视觉和 AI，MCU 负责确定性的实时动作，我个人觉得这才是 UNO Q 双脑架构真正有价值的地方。

6. 一个很适合继续扩展的案例

下一步可以把 LED 换成：

AI 摄像头
   ↓
检测到 person
   ↓
Python 判断
   ↓
Bridge.call()
   ↓
STM32
   ↓
GPIO 拉高
   ↓
蜂鸣器 / 舵机 / 电机

Arduino App Lab 本身已经提供图像分类、目标检测、二维码识别等示例，因此可以在这个基础上继续做完整的端侧 AI 应用。

7. 常见问题

问题	原因
为什么 Python 不能像普通 Arduino 一样直接写所有 GPIO？	实时 IO 主要由 MCU 管理
Linux 和 MCU 怎么通信？	Bridge / RPC
AI 应该放在哪边？	Qualcomm Linux 侧
电机控制放哪里？	STM32 MCU 更合适
可以只用 Arduino IDE 吗？	MCU 可以，但会损失 App Lab 的双处理器协同能力

8. 总结

Arduino UNO Q 最重要的变化并不是简单地“性能变强”，而是把Linux + AI + MCU 实时控制，放到了同一块 Arduino 开发板上。
在一块开发板当中Qualcomm QRB2210 负责计算、视觉、AI 和网络，STM32U585 负责 GPIO、传感器和实时执行，两者再通过 Bridge 联动。如果后续要做机器人、AI 摄像头、工业检测或者智能控制，这种架构比单纯的 Linux SBC 或传统 MCU 都更有意思。

...全文