來源 | 嵌入式大雜燴
在嵌入式開發中，我們經常面臨一個經典困境：底層硬件千變萬化，上層應用卻渴望統一接口。
今天要介紹的開源項目——EC Proxy（Embedded Controller Proxy），正是用“橋接模式”思想完美解決這一問題的典范之作。
項目地址：https://github.com/m5stack/AI-Pyramid-EC-Proxy
許可證：MIT License
EC Proxy是一個高性能嵌入式控制器通信系統，由知名硬件廠商M5Stack開源，采用MIT許可證。它的核心使命很簡單：讓開發者用幾條命令就能控制復雜的硬件外設，而不用糾結于底層的Modbus寄存器、串口波特率等細節。
簡單來說，EC Proxy在“硬件端”與“客戶端”之間架起了一座橋梁：
上層應用（CLI工具、Python程序等）通過ZeroMQ的RPC接口調用功能；EC Proxy服務端將請求翻譯成Modbus RTU指令，通過串口發給硬件控制器；硬件狀態變化則通過PUB/SUB機制實時推送給訂閱者。
在傳統的嵌入式開發中，如果你要控制一個硬件設備，通常需要：
EC Proxy的核心價值在于“分離抽象與實現” ——這正是橋接模式的設計初衷：
ec_cli | /dev/ttyS3 |
這種分層設計帶來三大好處：
ec_cli device --fan -d 80這樣直觀的命令，而非晦澀的寄存器操作EC Proxy由兩大核心組件構成：
ec_proxy）這是常駐后臺的守護進程，負責所有硬件通信的“翻譯”工作：
ipc:///tmp/rpc.ec_prox）ipc:///tmp/llm/ec_prox.event.socket）ec_cli）這是給開發者使用的命令行工具，一行命令控制硬件：
# 控制風扇轉速
ec_cli device --fan -d 80 # 設置風扇80%轉速
# 控制RGB LED
ec_cli device --rgb -d 5 # 設置RGB LED模式
# 獲取功耗信息
ec_cli device --board # 查看整板功耗
# 訂閱按鍵事件
ec_cli echo --button # 實時監聽按鍵按下
當你在終端輸入 ec_cli device --fan -d 60 時，背后發生了什么？
步驟1：CLI工具通過ZeroMQ RPC向ec_proxy發起調用
↓
步驟2：ec_proxy解析RPC請求，轉換為Modbus指令
↓
步驟3：通過串口(/dev/ttyS3)以921600bps發送給硬件EC
↓
步驟4：硬件EC執行指令，控制風扇PWM輸出
↓
步驟5：硬件返回執行狀態，ec_proxy回傳給CLI
反過來，當硬件狀態發生變化（如用戶按下按鈕），事件會沿著相反方向流動——通過PUB/SUB機制實時廣播給所有訂閱者，實現事件驅動的響應式架構。
EC Proxy的硬件支持相當全面：
| 電源管理 | |
| 外設接口 | |
| 顯示與LED | |
| 傳感器與控制 | |
| 網絡 |
這些硬件圍繞AI-Pyramid系列開發板設計，采用ARM64架構，搭載AX630C/AX650N等芯片。
如果說Modbus是EC Proxy與硬件對話的“口舌”，那么ZeroMQ RPC就是連接客戶端與服務端的“神經系統”——它讓上層應用能夠像調用本地函數一樣，遠程操控千里之外的硬件設備。
RPC（Remote Procedure Call，遠程過程調用）是一種經典的通信模式，讓程序可以調用另一臺機器上的函數，就像調用本地函數一樣簡單。在嵌入式領域，RPC的價值尤為突出——它將復雜的底層通信細節（串口協議、數據幀構造、校驗等）封裝起來，上層開發者只需關心“調用什么功能”，而不用關心“怎么調用”。
EC Proxy選擇ZeroMQ作為RPC的底層通信引擎，絕非偶然。ZeroMQ（簡稱ZMQ）是一個輕量級、無中心Broker的消息庫，它直接集成到應用程序中，不依賴外部消息代理。
ZeroMQ支持多種通信模式：
| REQ/REP（請求-響應） | |
| PUB/SUB（發布-訂閱） | |
EC Proxy巧妙地將REQ/REP用于RPC調用，PUB/SUB用于硬件事件廣播，兩種模式協同工作，構成了完整的雙向通信體系。
在EC Proxy所屬的M5Stack生態中，ZeroMQ被封裝在名為 pzmq 的C++類中。pzmq提供了兩個核心方法：
register_rpc_action() —— 服務端注冊一個可被遠程調用的函數call_rpc_action() —— 客戶端調用遠端注冊的函數為了區分不同的ZeroMQ套接字類型，pzmq定義了兩個自定義標志：
ZMQ_RPC_FUN （ZMQ_REP | 0x80）—— 服務端套接字，用于暴露RPC函數ZMQ_RPC_CALL （ZMQ_REQ | 0x80）—— 客戶端套接字，用于發起遠程調用注意到EC Proxy的RPC套接字地址是 ipc:///tmp/rpc.ec_prox，這是一種Unix域套接字（IPC，Inter-Process Communication），而非TCP網絡端口。
這種設計有兩大優勢：
這也意味著：EC Proxy的CLI工具和代理服務必須運行在同一臺設備上。如果需要遠程控制，可以在上層再封裝一層網絡服務。
EC Proxy通過兩種ZeroMQ套接字實現不同職責的分離：
ipc:///tmp/rpc.ec_prox | 同步RPC調用 | |
ipc:///tmp/llm/ec_prox.event.socket | 異步事件廣播 |
這種“請求-響應”+“發布-訂閱”的雙通道設計，讓EC Proxy既能高效處理控制指令，又能實時感知硬件狀態變化，兼顧了同步控制的準確性和異步通知的實時性。
EC Proxy的價值不僅在于“能用”，更在于設計思想的優雅——它用橋接模式將復雜的硬件細節封裝在底層，向上層提供統一、簡潔的抽象接口。這種分層架構讓嵌入式開發從“面向寄存器編程”進化為“面向接口編程”，大幅降低了硬件控制的門檻。
------------ END ------------
做嵌入式項目，選RTOS要考慮哪些問題？
AI會取代電子工程師嗎？工程師用一年時間給出了這樣的答案
Linux 24小時爆出440個漏洞：提權、逃逸、越界讀取全都有
