從一顆 LED 開始

這 30 天，我想用 Arduino UNO Q 做一個看起來不大、但很容易失控的小作品，桌上放一顆 LED 和一顆實體按鈕，手機瀏覽器裡再放一顆網頁按鈕，人站在桌前時可以伸手按，離開座位後也能從手機操作，不管從哪一邊切換，現場的燈和網頁上的狀態都必須保持一致。

把 LED 打開並不難，麻煩的是「兩邊都能控制」

實體按鈕剛把燈關掉，手機畫面不能還顯示 ON，網頁送出的命令如果沒有成功，畫面也不能自己假裝燈已經亮了，這些看似細小的問題，正是物聯網、智慧家庭和工業控制每天都在處理的事，我們會把問題縮小到一顆 LED，再用 30 天慢慢把整條資料流接起來。

從熟悉的 Arduino 走到另一個世界

傳統 Arduino 很適合處理現場工作，按鈕被按下，它立刻讀到，感測器數值改變，它馬上反應，LED、蜂鳴器和馬達也都能直接控制，許多人第一次感受到程式可以碰到真實世界，就是從一顆燈亮起來開始。

不過當作品開始需要網頁、Python、資料庫、影像辨識或 AI，事情就會變得不太一樣，一般做法常是保留 Arduino 負責硬體，再接上一台樹莓派或其他小型電腦負責高階應用，兩塊板子各做各的事，工程上沒有問題，但供電、通訊、體積和程式部署都會跟著增加。

UNO Q 把這兩個原本分開的世界放到同一塊控制板上，板上保留一顆擅長即時控制的 MCU，也加入一顆能執行 Linux、Python、Web 與邊緣 AI 的 MPU。拿在手上仍看得到熟悉的 Arduino 接腳排列，但接上 USB-C 之後，它又更像一台能跑完整應用的小電腦，這也是這塊板子最吸引我的地方，不是單純把處理器做得更快，而是讓兩種不同的工作可以留在同一個專案裡。

兩顆腦袋各做擅長的工作

UNO Q 的 MCU 是 STM32U585，負責讀取按鈕、控制 LED、輸出 PWM，以及和感測器、致動器打交道，這些工作通常不複雜，卻很在意反應時間與穩定性，網頁塞車、Python 忙著處理資料，都不應該讓按鈕慢半拍，因此現場狀態會交給 MCU 管理。

另一邊的 MPU 是 Qualcomm Dragonwing QRB2210，可以執行 Debian Linux，處理 Python、Web 服務、資料運算與邊緣 AI，它比較像應用程式的運行環境，負責接收手機送來的操作、整理資料，再把真正需要碰硬體的命令交給 MCU。

兩邊不是誰取代誰，也不是一顆比較高級，MCU 擅長穩定地守在現場，MPU 擅長和外面的軟體世界溝通，它們透過板上的橋接機制交換命令與狀態，後面幾天我們會親手把這條橋架起來，到了那時，Python 才能請 MCU 開燈，MCU 也能把實體按鈕的最新狀態回報給網頁。

App Lab 是兩個世界的工作桌

硬體整合在一起之後，軟體如果仍要分散在不同工具裡，開發體驗還是會很零碎，Arduino 為 UNO Q 準備了 App Lab，讓 MCU 程式、MPU 端的 Python、Web 介面與功能模組可以放在同一個專案流程中，較複雜的能力還能透過 App Bricks 封裝，開發者不必每次都從底層重新搭建。

第二天我們就會安裝 App Lab，不過接下來不會立刻把所有功能一次打開，而是從最小的成果開始，先讓 MCU 點亮 LED，再加入按鈕、狀態變數與除彈跳，接著喚醒 MPU，用 Python 和 MCU 通話，最後才做出網頁，讓手機與現場按鈕共同控制同一顆燈。

30 天就聚焦一條主線

前十天會留在 MCU 端，把 LED 和實體按鈕做穩，中間幾天加入 MPU 與 Bridge，先在沒有網頁的情況下完成雙向溝通，後段再建立 Web UI，讓操作從瀏覽器一路送到 MPU、MCU 與 LED，也讓現場狀態沿著相反方向回到畫面。

到了第 29 天，整個作品會形成一條完整的資料流，網頁按鈕可以控制桌上的 LED，實體按鈕也會即時更新網頁，而且真正的狀態只由 MCU 保存，第 30 天再把門打開，看看同一塊板子如何繼續接上影像辨識、語音、Arduino Cloud 與其他邊緣 AI 應用。

第一天介紹脈絡

我們第一天只先確認兩件事，我們要做的是一個實體與網頁同步的開關，UNO Q 則用 MCU 負責現場控制，用 MPU 負責 Linux、Python、Web 與 AI，讓這兩個世界留在同一塊板子上合作。

明天會先把 App Lab 裝好，建立第一個專案，第三天再讓 MCU 接手，點亮這 30 天旅程中的第一顆 LED。

下一篇：先把 App Lab 裝好，後面才不會卡在門口