12.10. 總結

一台透過 USB 線插上的相機，將影格串流到主機程式、接受來自主機的設定更新，並在拔除/重新插上時不失同步——重傳被隱藏、多個邏輯串流共用一個連接埠、應用程式中零框架程式碼——這一切只需要大約四十行相機端程式碼，以及主機端差不多的份量。協定函式庫把一條位元組管線轉變為可程式化的通道介面，並讓應用程式底下的一切保持隱形。

12.10.1. 本章建構了什麼

  • 堆疊的四層心智模型：傳輸、框架、可靠性、通道。每一層解決一個問題，並忽略其上的一切。

  • 傳輸線上的封包格式——10 位元組標頭附 CRC、可變酬載、結尾 CRC。小到可以逐位元組走過一遍。

  • 傳輸連線時相機與主機執行的交握：PROTO_SYNC、能力交換、通道探索。

  • 其上的可靠性機制：序列號、ACK、NAK、帶有指數退避的重傳，以及十種狀態碼。

  • 通道模型：一條傳輸線上最多 32 個具名的邏輯串流，內建 stdin / stdout / stream / profile，以及由 Python 類別註冊的應用程式通道。

  • 後端介面——size、read、write、poll、lock / unlock、shape、ioctl、flush、is_active——以及協定函式庫如何利用後端上存在的方法來決定該通道支援什麼。

  • 主機端：openmv-python SDK 的 Camera 類別、將 USB-CDC 切換進協定模式的 921600 鮑率魔術值，以及 channel_size / channel_read / channel_write 的往返模式。

  • 一種影格串流模式——單緩衝區擷取、帶鎖存的 readp、用於新影格通知的 send_event——以及一種雙向設定模式（主機可寫的通道、JSON 往返），兩者共同構成每個互動式相機工具的基礎。

12.10.2. 參考路線圖

當這些功能之一在真實程式碼中出現時，函式庫參考頁面就是查閱的目的地：

  • protocol --- OpenMV 協定通道 ——protocol 模組、protocol.init()、protocol.register()、ProtocolChannel、通道旗標常數，以及各相機的最大酬載對照表。

  • 主機 SDK——pip install openmv、openmv.camera.Camera。本章觸及的方法：update_channels()、has_channel()、channel_size()、channel_read()、channel_write()、poll_events()、read_frame()、exec()，以及 stop()。

  • openmv-projects 儲存庫——建構於協定函式庫之上的真實工具。tools/ 目錄包含 thermal-overlay-calibration（RGB + 熱影像對齊 GUI）、ccm-tuning（色彩校正矩陣調校器）、genx320-event-streaming 與 genx320-overlay-calibration（事件相機工具）。每一個都從頭到尾運用了本章的各種模式。

12.10.3. 接下來可以往哪走

相機專案從這裡可以發展的幾個方向：

  • 建構主機 GUI。 一個影格通道餵給視訊小工具，一或兩個設定通道餵給滑桿與按鈕。至於 GUI 層本身，DearPyGui 是自然的選擇——純 Python、可用 pip 安裝、快到足以即時預覽，也是每個現有的 OpenMV 主機工具首先採用的選項。

  • 多通道遙測儀表板。 在同一台相機上有數個應用程式通道（感測器讀值、計數器、狀態事件），各自在自己的回呼函式中重新整理，而主機 GUI 以計時器讀取它們並分別呈現每一個。通道層獨立的流量控制意味著一個緩慢的讀取不會拖垮其他通道。

  • 透過 UART 的遠端調校。 同樣的通道回呼函式；應用程式呼叫 protocol.init 以從 USB 切換到 UART 傳輸。相機持續以無頭模式執行，而 Raspberry Pi 或筆電上的 Python 指令碼透過序列線與它通訊，進行現場調校。

傳輸線格式、可靠性層與通道抽象都不會改變。挑選符合部署需求的傳輸，並為主機需要檢視或設定的每件事新增一個通道，從這裡開始就是全部的工程工作。