我一直覺得嵌入式圈子里最不缺的就是爭論而“C 還是 C”大概是被翻來覆去炒得最多的一道菜。上個(gè)月我在某通信模塊的固件里調(diào)試一段 C 寫的老狀態(tài)機(jī)兩百多行嵌套的 switch-case看得眼睛發(fā)花同事后來用 C 的枚舉類和模板重構(gòu)了同樣的邏輯代碼量砍掉一半編譯期還多了一堆類型檢查。那一刻我確實(shí)意識到兩邊都沒打算退場但它們的交鋒方式正在悄悄改變。這篇文章我不想站隊(duì)“C 永遠(yuǎn)天下第一”或者“C 全面取代 C”而是把兩邊的真實(shí)家底都擺出來對比C 靠什么守住統(tǒng)治地位C 又從哪些維度真正構(gòu)成了降維打擊最后落到實(shí)際工程里我們到底該怎么選、怎么混、怎么避坑。適合所有在裸機(jī)、RTOS、甚至復(fù)雜 SoC 上寫過程序的人不管你現(xiàn)在用哪門語言看完應(yīng)該都能對自己的棧有一個(gè)更清醒的判斷。1. C 語言統(tǒng)治嵌入式世界的根基到底在哪兒很多人剛接觸嵌入式時(shí)第一個(gè)接觸的語言基本就是 C。這不是偶然而是整個(gè)行業(yè)在過去幾十年里沉淀出的一套默認(rèn)規(guī)則。1.1 從寄存器到鏈接器整個(gè)工具鏈都帶有“C 慣性”嵌入式開發(fā)的起點(diǎn)是寄存器操作而 Cortex-M、AVR、PIC 這類芯片的頭文件、啟動(dòng)代碼、HAL 庫幾乎清一色用 C 寫成。我們最常用的編譯器工具鏈像 GCC 的 arm-none-eabi 分支調(diào)試器、靜態(tài)分析工具、RTOS 內(nèi)核封裝第一語言也都是 C。這套生態(tài)已經(jīng)運(yùn)轉(zhuǎn)了很多年所有文檔、示例工程、FAE 支持話術(shù)、高校教學(xué)體系都默認(rèn)你用 C換語言的隱性成本遠(yuǎn)不止改語法那么簡單。另一個(gè)很容易被忽略的是 ABI 穩(wěn)定性。C 的符號命名規(guī)則、結(jié)構(gòu)體內(nèi)存布局、函數(shù)調(diào)用約定幾十年來幾乎沒有變化早期的庫和現(xiàn)在的代碼可以無縫鏈接。而 C 因?yàn)橛兄剌d、命名空間、模板符號會被修飾manglingABI 更容易受編譯器版本影響。對于很多芯片廠商和中間件供應(yīng)商來說提供一個(gè) C 接口是保險(xiǎn)的做法這直接導(dǎo)致我們在工程里看到的第三方庫大多是純 C 或帶 C 封裝層的。1.2 “能用 C 就夠用”的硬件現(xiàn)實(shí)在我調(diào)試過的不少項(xiàng)目里真正吃掉資源的功能其實(shí)并不復(fù)雜采集傳感器數(shù)據(jù)、跑一個(gè)簡單的控制環(huán)路、發(fā)送協(xié)議報(bào)文、處理幾個(gè)按鍵中斷。這些任務(wù)用 C 寫清晰度完全夠。存孚空間往往只有幾十 KBRAM 幾 KB 到幾十 KB在這種資源約束下C 的超薄抽象反而是優(yōu)勢——你打開反匯編一眼能看穿每一條指令在干什么。更重要的是C 和硬件的對應(yīng)關(guān)系足夠直接。指針就是地址結(jié)構(gòu)體就是內(nèi)存布局位運(yùn)算就是寄存器操作。學(xué)習(xí) C 的過程實(shí)際上就是學(xué)習(xí)計(jì)算機(jī)組成原理的過程。這給了 C 一種“底層的正當(dāng)性”它讓你離硅片更近也讓你在排查問題時(shí)擁有一種掌控感。1.3 實(shí)時(shí)性與確定性C 的天然“免檢”資質(zhì)實(shí)時(shí)系統(tǒng)最怕行為不確定。new 會在哪里分配內(nèi)存、模板會展開多少代碼、異常會走什么路徑這些問題在 C 時(shí)代根本不存在因?yàn)?C 幾乎沒有運(yùn)行時(shí)魔法。編譯器生成的指令和源碼之間的對應(yīng)關(guān)系非常穩(wěn)定這也讓 C 在航空、汽車、醫(yī)療這些對安全認(rèn)證有苛刻要求的領(lǐng)域仍然是首選。比如很多功能安全標(biāo)準(zhǔn)中對工具鏈的 qualification 本身就偏向成熟穩(wěn)定的 C 編譯器C 的復(fù)雜特性要讓認(rèn)證機(jī)構(gòu)認(rèn)可成本要高出不少。2. C 憑什么在嵌入式里講“降維打擊”如果只看傳統(tǒng)小型裸機(jī)項(xiàng)目C 的統(tǒng)治地位確實(shí)難以撼動(dòng)。但當(dāng)項(xiàng)目規(guī)模上升到一定程度——比如帶網(wǎng)絡(luò)協(xié)議棧、文件系統(tǒng)、復(fù)雜狀態(tài)機(jī)、多任務(wù)調(diào)度的物聯(lián)網(wǎng)網(wǎng)關(guān)或車載控制器時(shí)C 的原始抽象能力就開始吃力了而這恰恰是 C 的主場。2.1 模板和 constexpr把“手寫重復(fù)”交給編譯器C 語言寫外設(shè)驅(qū)動(dòng)常常要面對成堆的重復(fù)代碼。一個(gè) SPI 控制器有 8 個(gè)相同通道那就得寫 8 份幾乎一樣的初始化結(jié)構(gòu)體或者用宏去生成但宏的危害大家都懂——它不遵循作用域規(guī)則調(diào)試時(shí)看到的是展開后的中間結(jié)果而不是你的源碼。C 的模板可以把這類“類型級參數(shù)化”做到干凈利落。同樣是寄存器映射用一個(gè)模板類來表示外設(shè)基地址和寄存器布局編譯器在編譯期就能生成針對不同實(shí)例的代碼本質(zhì)上是零成本抽象。constexpr 更進(jìn)一步它能把大量查表運(yùn)算、參數(shù)校驗(yàn)、CRC/CRC 表生成等邏輯放到編譯期完成運(yùn)行時(shí)只剩下讀取結(jié)果。我見過一個(gè)用 C 重寫的校驗(yàn)算法原本 C 版運(yùn)行時(shí)算了一百多個(gè)周期改寫后用 constexpr 在編譯期把表算好運(yùn)行時(shí)就是一條查表指令。2.2 RAII 讓資源管理有了“確定性”嵌入式最不缺的就是資源管理的細(xì)節(jié)問題用到的外設(shè)要初始化用完了要不要關(guān)閉申請的 DMA 緩沖什么時(shí)候釋放mutex 鎖住之后如果中途 return誰來解鎖這些在 C 語言里全靠程序員記憶和紀(jì)律而人的紀(jì)律在加班和需求變更面前是最靠不住的東西。RAII資源獲取即初始化把資源的生命周期綁定到對象的作用域。局部對象離開作用域時(shí)析構(gòu)函數(shù)一定被執(zhí)行不管你是正常返回還是中途提前退出。一個(gè) C 的鎖對象構(gòu)造時(shí)拿鎖析構(gòu)時(shí)釋放鎖天然避免了“忘記解鎖”這類低級事故。對嵌入式工程師來說這種確定性不是奢華的語法糖而是降低缺陷率的關(guān)鍵武器。2.3 enum class、強(qiáng)類型與更少的人類失誤C 語言的枚舉本質(zhì)上還是整數(shù)類型檢查等于沒有。今天用一個(gè)參數(shù)傳錯(cuò)順序只要類型是 int編譯器一聲不吭地放行問題留到運(yùn)行時(shí)才爆炸而排查一個(gè)參數(shù)順序錯(cuò)誤常常要花掉半天時(shí)間。C 的 enum class 是真正的強(qiáng)類型不同枚舉之間不能隱式轉(zhuǎn)換傳錯(cuò)參數(shù)編譯期直接報(bào)錯(cuò)。配合函數(shù)重載、命名空間、const 引用C 讓大量“只有運(yùn)行時(shí)才知道我才錯(cuò)”的錯(cuò)誤前移到編譯期。這種把錯(cuò)誤攔截在構(gòu)建階段的能力在多人協(xié)作的中大型工程里價(jià)值巨大也是我認(rèn)為它“降維打擊”最實(shí)在的一點(diǎn)。2.4 現(xiàn)代 C 在低功耗與實(shí)時(shí)性上的真實(shí)表現(xiàn)很多人一聽說 C 就想到 STL、想到堆分配、想到巨大的鏡像體積其實(shí)這是把“C”和“特定的寫 C 的方式”混為一談了。關(guān)閉異常和 RTTI、禁用動(dòng)態(tài)堆分配、只用模板和 RAII再加上諸如-fno-exceptions -fno-rtti -fno-threadsafe-statics這類編譯選項(xiàng)C 的代碼性能和資源開銷完全可以和 C 拉到同一水平線。我用 Cortex-M4 做過對比測試純手工 C 和現(xiàn)代 C 寫的 GPIO 翻轉(zhuǎn)循環(huán)反匯編出來后幾乎沒有區(qū)別。真正讓 C 顯得“重”的往往不是語言本身而是庫和運(yùn)行時(shí)。寫嵌入式 C 的核心原則就是“盡可能少依賴運(yùn)行時(shí)盡可能多依賴編譯期”用模板、constexpr、RAII 而不是異常、虛函數(shù)、標(biāo)準(zhǔn)容器。遵循這個(gè)原則的 C在運(yùn)行效率上并不虛 C在工程組織能力上卻強(qiáng)出一個(gè)身位。3. 一個(gè)狀態(tài)機(jī)重構(gòu)案例同樣的任務(wù)C 和 C 代碼差在哪理論說得再多不如看一個(gè)具體的例子。這里我拿一個(gè)典型的通信協(xié)議解析狀態(tài)機(jī)來對比場景是一個(gè)串口數(shù)據(jù)幀的接收處理幀頭、長度、負(fù)載、校驗(yàn)、幀尾中間有各種錯(cuò)誤重傳。3.1 傳統(tǒng) C 實(shí)現(xiàn)函數(shù)指針表加 switch-caseC 的經(jīng)典寫法是把每個(gè)狀態(tài)定義成枚舉用一個(gè)大的 switch-case 分發(fā)事件。核心代碼大概長這樣typedef enum { ST_IDLE, ST_HEADER, ST_LENGTH, ST_PAYLOAD, ST_CHECKSUM, ST_ERROR } state_t; typedef uint8_t event_t; state_t state ST_IDLE; void handle_event(event_t ev, uint8_t data) { switch (state) { case ST_IDLE: if (ev EV_RX_BYTE) { if (data FRAME_HEADER) state ST_HEADER; else state ST_ERROR; } break; case ST_HEADER: if (ev EV_RX_BYTE) { frame.len data; state ST_LENGTH; } break; // ... 后面每個(gè)狀態(tài)繼續(xù)一個(gè) case default: state ST_ERROR; break; } }狀態(tài)一多這個(gè) switch 就開始膨脹。每個(gè) case 里還要嵌套各種 if-else邏輯糾纏在一起后期加一個(gè)新狀態(tài)得仔細(xì)瀏覽每個(gè)舊 case確認(rèn)有沒有沖突。更麻煩的是狀態(tài)機(jī)一旦需要保存上下文就得加一個(gè)龐大的 struct把這個(gè)狀態(tài)機(jī)相關(guān)的所有變量都塞進(jìn)去函數(shù)參數(shù)也會越來越長。3.2 C 重構(gòu)枚舉類加狀態(tài)對象加事件分發(fā)在 C 版本里我會用一個(gè)狀態(tài)基類把每個(gè)狀態(tài)封裝成獨(dú)立對象事件處理通過虛函數(shù)分發(fā)enum class Event { RxByte, Timeout, FrameDone }; struct Context { uint8_t buf[64]; uint16_t len; uint8_t checksum; }; struct State { virtual State* handle_event(Context ctx, Event ev, uint8_t data) 0; }; struct IdleState : State { State* handle_event(Context ctx, Event ev, uint8_t data) override { if (ev Event::RxByte data FRAME_HEADER) return new HeaderState(); return new ErrorState(); } }; // 其他狀態(tài)類似每個(gè)狀態(tài)只關(guān)心自己的進(jìn)入條件每個(gè)狀態(tài)類只處理自己那一份邏輯新加狀態(tài)只需要繼承 State不會影響已有狀態(tài)。事件分發(fā)變成了一個(gè)真正的面向?qū)ο蟮恼{(diào)用而不是一個(gè)巨大的條件分支。測試也變簡單了直接構(gòu)造一個(gè)狀態(tài)對象手動(dòng)喂事件斷言返回的下一個(gè)狀態(tài)即可。3.3 對比結(jié)果與代價(jià)我用這個(gè)案例做過一次量化對比效果非常直觀對比項(xiàng)C 函數(shù)指針開關(guān)C 狀態(tài)對象狀態(tài)邏輯代碼行數(shù)約 220 行約 120 行新增一個(gè)狀態(tài)的工作量修改 switch檢查所有舊 case新增一個(gè)派生類注冊即可編譯后代碼體積約 2.1 KB約 2.4 KB測試難度需要構(gòu)造各種 ev/state 組合直接測試獨(dú)立對象代價(jià)也有C 版本因?yàn)橐肓颂摵瘮?shù)表每個(gè)狀態(tài)多了一點(diǎn)點(diǎn)靜態(tài)數(shù)據(jù)對象是棧上分配的沒有額外堆開銷代碼體積多了約 300 字節(jié)。但對于絕大多數(shù)嵌入式系統(tǒng)這點(diǎn)增量換取的可維護(hù)性完全值。當(dāng)然如果項(xiàng)目真的是一個(gè) 4KB Flash 的單片機(jī)跑一個(gè)超簡單傳感器邏輯那我不會推薦用虛函數(shù)那種場景 C 的 switch 反而是最優(yōu)解。4. 現(xiàn)實(shí)工程里的分工哪層繼續(xù)用 C、哪層值得切 C說句實(shí)話工程上很少會出現(xiàn)“整個(gè)項(xiàng)目從第一行到最后一行全用 C”的激進(jìn)方案。更常見的是分而治之底層硬件抽象用 C 保持簡單可靠上層應(yīng)用邏輯、協(xié)議棧、業(yè)務(wù)建模用 C 提升效率。4.1 硬件抽象層與啟動(dòng)代碼C 的絕對主場寄存器定義、時(shí)鐘樹配置、啟動(dòng)文件、鏈接腳本這些最貼近芯片的部分我?guī)缀醪粫?C 去改寫。原因很簡單硬件廠商的參考代碼、勘誤文檔、調(diào)試手段全都建立在 C 之上這里改寫 C 不僅沒有業(yè)務(wù)價(jià)值反而會增加和芯片原廠溝通時(shí)的理解成本。另一類是庫函數(shù)、bootloader、中斷向量表附近的高實(shí)時(shí)路徑這些代碼要求極端的透明和可控C 是更穩(wěn)妥的選擇。4.2 應(yīng)用邏輯與協(xié)議棧C 最能體現(xiàn)價(jià)值的地方一旦脫離了貼芯片的層次C 的優(yōu)勢就全面釋放。比如設(shè)備端的藍(lán)牙協(xié)議棧適配層、命令解析器、狀態(tài)機(jī)、日志系統(tǒng)、傳感器算法框架、OTA 流程管理——這些邏輯往往涉及大量狀態(tài)、超時(shí)、重試、數(shù)據(jù)校驗(yàn)恰好是 C 代碼最容易變成“面條”的地方。用 C 的類、命名空間、RAII 和強(qiáng)枚舉來組織模塊邊界清晰單人維護(hù)和多人協(xié)作都舒服很多。我在某工業(yè)采集項(xiàng)目里把設(shè)備配置管理和命令解析層從純 C 切換到 C 后一個(gè)明顯的改善是新增一條命令不再需要往一個(gè)巨型函數(shù)里插 case只要新增一個(gè)命令類系統(tǒng)框架自動(dòng)完成注冊和分發(fā)。功能測試用例的覆蓋率也明顯提升了因?yàn)槊總€(gè)命令類可以單獨(dú)構(gòu)造、單獨(dú)斷言。4.3 三類項(xiàng)目的選型參考小資源裸機(jī)項(xiàng)目F103 級別或更小Flash 在 64KB 以下功能單一直接用 C別折騰 C收益撐不起成本中型 RTOS 項(xiàng)目跑 IoT 協(xié)議棧、傳感器融合、多任務(wù)管理Flash 128KB 以上推薦 C 打底加 C 應(yīng)用層這套組合能最大限度兼顧兩層優(yōu)勢復(fù)雜 SoC 平臺跑 Linux 級別的系統(tǒng)、嵌入式 GUI、多媒體框架這個(gè)層面 C 已經(jīng)是事實(shí)主流QT/WebKit/ML 框架大量使用 C再用純 C 反而寸步難行。5. C 與 C 混編容易踩的坑我一個(gè)個(gè)踩給你看真正把 C 和 C 放在同一個(gè)工程里考驗(yàn)才剛開始。我在多個(gè)項(xiàng)目里踩過的坑基本集中在頭文件、鏈接、啟動(dòng)、內(nèi)存這四類。5.1 頭文件里的 extern “C” 封裝C 和 C 混編的第一個(gè)坑就是符號鏈接。C 編譯器生成的符號名就是函數(shù)名本身而 C 編譯器會做名字修飾。如果 C 代碼直接調(diào)用一個(gè) C 函數(shù)而沒有正確聲明鏈接階段就會拿到一個(gè) mangled 后的符號然后報(bào)“undefined reference”。解決辦法是在所有 C 頭文件里加上 extern C#ifdef __cplusplus extern C { #endif void hal_spi_init(SPI_TypeDef* spi, uint32_t speed); #ifdef __cplusplus } #endif這段宏判斷只會在 C 編譯單元里生效C 編譯單元不會多出任何東西。很多芯片廠商已經(jīng)在新版 HAL 庫里加了這層封裝但老代碼不一定有我們自己寫的公共頭文件最好從一開始就統(tǒng)一加上省得后患無窮。5.2 全局構(gòu)造與析構(gòu)別讓 C 的隱藏代碼攪亂啟動(dòng)流程C 里有全局對象時(shí)會在 main 之前執(zhí)行構(gòu)造函數(shù)。啟動(dòng)代碼如果只盯著Reset_Handler - SystemInit - main這條路徑可能根本沒給全局構(gòu)造留執(zhí)行入口。大部分 GCC 工具鏈通過__libc_init_array來處理.init_array段如果你的啟動(dòng)代碼是自己寫的一定要確認(rèn)它調(diào)用了這段初始化邏輯。另一個(gè)隱蔽問題是全局對象在 main 之前構(gòu)造這意味著它不能依賴任何尚未初始化的外設(shè)或系統(tǒng)堆。我有一個(gè)經(jīng)驗(yàn)法則盡量不用全局對象保持嵌入式 C 風(fēng)格的純粹性。如果確實(shí)需要直接使用局部 static 對象配合 C11 的 Magic Static 機(jī)制在首次訪問時(shí)才構(gòu)造很多啟動(dòng)階段的問題就自動(dòng)消失了。5.3 RTOS 任務(wù)函數(shù)、中斷回調(diào)和 C 的交接RTOS 的任務(wù)函數(shù)簽名通常是void task(void* arg)是 C 風(fēng)格的回調(diào)。你要把 C 成員函數(shù)傳給這個(gè)回調(diào)不能直接傳MyClass::run得通過一個(gè)靜態(tài)包裝函數(shù)或 lambda 做橋接void task_entry(void* arg) { static_castMyClass*(arg)-run(); }中斷里調(diào)用 C 代碼要更謹(jǐn)慎。中斷是異步的它可能在你正訪問某個(gè)對象的成員變量時(shí)打斷你造成數(shù)據(jù)競爭。更別提如果在中斷里觸碰了可能分配內(nèi)存的容器或異常機(jī)制后果幾乎不可預(yù)測。我在中斷回調(diào)里只做一件事把事件記錄到無鎖隊(duì)列把實(shí)際處理邏輯放到任務(wù)上下文里C 的復(fù)雜對象也只保留給任務(wù)側(cè)使用。5.4 控制代碼體積鏈接裁減與特性屏蔽混合使用 C 后最容易被吐槽的就是鏡像變大實(shí)操上可以通過鏈接器和編譯器約束把它控制住。GCC 的-ffunction-sections配合鏈接腳本里的--gc-sections能裁掉沒被引用的函數(shù)C 模板和虛函數(shù)表也需要這個(gè)機(jī)制才能有效收縮。此外-fno-exceptions、-fno-rtti、-fno-threadsafe-statics三個(gè)開關(guān)能去掉異常、RTTI 和靜態(tài)局部變量初始化的額外運(yùn)行時(shí)開銷對嵌入式項(xiàng)目幾乎是標(biāo)配。我還在 linker script 里添加過自定義 section把不同模塊的初始化函數(shù)放到特定段里統(tǒng)一調(diào)用這樣既能保留模塊化設(shè)計(jì)又不會引入大量全局對象的構(gòu)造需求。6. 關(guān)于 C 嵌入式的幾個(gè)經(jīng)典爭議我為什么選擇這樣理解從事嵌入式的人對 C 的質(zhì)疑往往根深蒂固有些質(zhì)疑來自踩坑有些則來自過時(shí)的信息。6.1 “嵌入式不能用 STL” 這句話還成立嗎嚴(yán)格說標(biāo)準(zhǔn)容器和算法庫在現(xiàn)代嵌入式工程里并非完全不可用但要分場景。裸機(jī)上我基本不用 STL 容器因?yàn)樗鼈兊姆峙湫袨椴荒敲赐该髟趦?nèi)存碎片和實(shí)時(shí)性要求高的場景里可能埋雷。但在帶 MMU、跑 Linux 的嵌入式平臺上STL 是正常武器隨便用只要注意避免頻繁小對象分配就行。真正讓很多裸機(jī)工程對 STL 敬而遠(yuǎn)之的原因其實(shí)不是庫本身而是實(shí)現(xiàn)版本、堆策略和異常機(jī)制的耦合關(guān)系你完全可以用-fno-exceptions配合定制分配器來規(guī)避。6.2 關(guān)掉異常和 RTTI我們到底失去了什么-fno-exceptions一開try/catch就不能用了但換來的是代碼體積和棧行為的確定性。嵌入式 C 領(lǐng)域絕大多數(shù)項(xiàng)目選擇關(guān)閉這兩個(gè)特性是合理的因?yàn)楫惓Ｂ窂降臈Ｕ归_在裸機(jī)上很難保證確定性。但你要想清楚替代方案錯(cuò)誤碼、optional 模式、狀態(tài)標(biāo)志位都是成熟的替代手段。RTTI 一關(guān)dynamic_cast和typeid不可用但可以用虛函數(shù)、靜態(tài)多態(tài)、手動(dòng)類型標(biāo)記解決 99% 的需求。6.3 new/delete 在裸機(jī)上真的完全不可用嗎我把話分成兩部分說。在中斷里 new/delete基本是災(zāi)難絕對不要碰但在任務(wù)上下文里只要配置了一個(gè)確定性的內(nèi)存池分配器甚至可以用placement new在靜態(tài)緩沖區(qū)上構(gòu)造對象完全避免堆碎片問題。對于生命周期固定、數(shù)量固定的資源我更推薦用模板和數(shù)組實(shí)現(xiàn)“靜態(tài)對象池”這樣可以做到構(gòu)造析構(gòu)的完全可預(yù)測還保留了 RAII 的便利。6.4 “零開銷抽象”是營銷話術(shù)還是真實(shí)約束現(xiàn)代 C 的設(shè)計(jì)原則就是這樣不用的特性不收費(fèi)用到的特性按編譯期或靜態(tài)方式展開。模板、constexpr、RAII 這類抽象在優(yōu)化開 O2 之后生成代碼和手寫 C 幾乎沒有差別。真正的開銷來自虛函數(shù)需要 vtable 查表、異常展開和堆分配而這些在嵌入式里是可以主動(dòng)避開的。所以“零開銷”不是神話前提是你不去觸碰那些有開銷的特性。我也必須承認(rèn)C 的學(xué)習(xí)曲線、編譯時(shí)間、代碼審查難度都比 C 要高團(tuán)隊(duì)如果沒有幾個(gè)能用好“現(xiàn)代 C 風(fēng)格”的人寧可穩(wěn)一點(diǎn)繼續(xù)用 C也別硬轉(zhuǎn)。7. 我經(jīng)歷過的幾個(gè)實(shí)際場景這里做個(gè)總結(jié)說了這么多還是分享幾個(gè)我自己做過的決策或許比抽象論述更有參考性。一個(gè) 8 位 MCU 溫濕度采集項(xiàng)目Flash 只有 8KB我毫不猶豫選了純 C。那套代碼簡單到不需要任何抽象C 的直白就是最好的表達(dá)方式。另一個(gè)帶 Wi-Fi、MQTT、OTA、文件系統(tǒng)的網(wǎng)關(guān)設(shè)備主控是 Cortex-A 雙核項(xiàng)目一開始就定了 C 寫應(yīng)用層、C 寫驅(qū)動(dòng)層整個(gè)開發(fā)節(jié)奏非常舒服。中間還有一個(gè)比較糾結(jié)的中型項(xiàng)目Cortex-M7 控制器要跑 CAN 網(wǎng)關(guān)、Bootloader、日志存儲、遠(yuǎn)程升級資源不算緊張但也談不上富余。最后我采用了“C 殼加 C 核”的方案外部回調(diào)、中斷入口、啟動(dòng)流程都用 C內(nèi)部業(yè)務(wù)邏輯用 C。這種方式兼顧了團(tuán)隊(duì)現(xiàn)有技術(shù)棧的延續(xù)性也讓狀態(tài)機(jī)和協(xié)議解析避免變成一鍋粥。如果你正在糾結(jié)自家項(xiàng)目要不要引入 C我給這么幾條建議都是實(shí)操里驗(yàn)證過的先從小范圍內(nèi)嵌模塊開始試比如一個(gè)協(xié)議解析器或一個(gè)命令分發(fā)器全程關(guān)閉異常和 RTTI寫好 RAII 風(fēng)格資源管理不碰全局對象頭文件統(tǒng)一加 extern “C” 封裝在 main 之后完成所有對象實(shí)例化。這樣試過一兩個(gè)模塊之后你對 C 在自家平臺上的表現(xiàn)會有一個(gè)非常真實(shí)的認(rèn)識比看任何爭論都靠譜。C 和 C 的“戰(zhàn)爭”在嵌入式領(lǐng)域短期內(nèi)不會結(jié)束。C 的基礎(chǔ)地位和生態(tài)慣性足夠它繼續(xù)統(tǒng)治底層很多年而 C 的邏輯組織和代碼生成能力也確實(shí)在悄悄重塑上層應(yīng)用開發(fā)的效率。我不覺得這是一場你死我活的替代更像兩種思維模式在分工越是貼近硬件的地方C 的透明度越難以替代越是貼近業(yè)務(wù)的地方C 的抽象能力越能幫我們壓住復(fù)雜性。作為嵌入式開發(fā)者最好的姿態(tài)不是忠誠于某一種語言而是清楚每一層的真實(shí)需求然后在兩種語言之間走一條最務(wù)實(shí)的路。