大家好，我是 will2108。延續昨天的硬體架構抉擇，既然我們決定讓「前端 MCU 專心感測」與「後端 Raspberry Pi 處理網路與儲存」，那麼這兩個各自為政的晶片，該怎麼溝通呢？

在眾多硬體通訊介面（SPI、I2C、USB、Ethernet）中，我們最終選擇了最古老、最沒有炫技成分，但也最堅不可摧的介面：UART (通用非同步收發傳輸器)。

為什麼在 2026 年還要用 UART？

你可能會問，為什麼不直接牽一條網路線 (Ethernet) 或用 USB？

1. 硬體成本與功耗：要求一個只吃鈕扣電池或低功耗 MCU 跑起完整的 TCP/IP Stack 或 USB 驅動，實在太強人所難，也會吃光寶貴的記憶體。
2. 極致的簡單 = 極致的穩定：UART 只需要三根線：TX (發送)、RX (接收)、GND (共地)。在充滿馬達雜訊、高頻電磁波的工業或醫療現場，越簡單的實體線路，受到干擾的機率就越低。

UART 的致命傷：它很笨

UART 雖然穩定，但它是一個**「非同步 (Asynchronous)」且「盲目」**的通訊協定。
如果前端 MCU 採集到資料就瘋狂往 TX 線上塞，而後端的 Raspberry Pi 剛好正在把幾百 MB 的資料寫入 SD 卡（這時 CPU 與 I/O 會陷入嚴重阻塞），那些來不及被讀取的 UART 緩衝區資料，就會直接溢位 (Buffer Overflow)，導致珍貴的醫療或環境數據永久遺失。

為了解決這個問題，我們不能讓 MCU 「主動推播」，而是要建立一套**「請求-回應 (Request-Response)」**機制。

Daisy Chain (菊鏈) 請求-回應模式

我們在軟體層面上，為這條 UART 加上了 Daisy Chain (菊鏈) 協定。這也是我們 DataGateway 專案中確保資料「零遺失」的核心防線。

它的運作邏輯非常像接力賽：

1. 由 Gateway (Pi) 發號施令：Pi 送出擷取指令，例如 0x03 [index=1]。
2. MCU 收到才動作：MCU 收到指令後，去記憶體挖出第 1 筆資料，並加上 Checksum (檢查碼) 傳回給 Pi。
3. 安全確認：Pi 收到資料、驗證 Checksum 無誤，並且確認已經安全寫入 SD 卡後，才會送出 0x03 [index=2] 索取下一筆。

透過這種「你一言，我一語」的節奏，不管 Pi 的 SD 卡寫入速度多慢，或者中途 Pi 被 OS 排程器搶走 CPU 資源，都不會發生資料遺失的問題，因為 MCU 會一直癡癡地等 Pi 的下一個指令。

延伸應用：模式切換與時間校準

有了這條雙向通道，我們還能做到更多事：

• 模式切換：我們設計了不同的標頭檔 (Header)。發送 F0 44... 時，MCU 進入「資料傳輸模式」；發送 F0 A4... 時，切換為「除錯/管理模式」，藉此讀取設備的獨特真實序號 (DEVICE_SN_DEMO) 以作為資料加密防偽的依據。
• 時間校準 (Time Sync)：缺乏網路連線的 MCU，內建的時鐘 (RTC) 幾個月後就會有嚴重的秒差。所以每次 Daisy Chain 傳輸完畢的最後一步，Pi 都會發送 0xF1 [Current Unix Timestamp] 指令，強迫 MCU 對時，確保每一筆感測數據的時間戳記都與雲端絕對同步！

解決了硬體溝通的問題，我們已經拿到寶貴的數據了。但接下來我們要面臨一個超級大魔王：「如何把這台 Linux 電腦，瞬間變成一顆可以插在 Windows 上的隨身碟？」

明天 [Day 04]，我們準備揭開 Linux 底層 Device Tree (MMIO) 與 ConfigFS 的神祕面紗！