前言說句實(shí)話做嵌入式C開發(fā)的人不少但真正把C用出味道來的不多。很多人寫STM32項(xiàng)目就是換了一副馬甲的C語(yǔ)言——類不會(huì)寫、RAII不用、模板不敢碰最后代碼跟早期的寄存器版C代碼沒什么區(qū)別。我這個(gè)系列一路寫到第6篇前5篇分別聊了環(huán)境搭建、GPIO的基礎(chǔ)封裝、狀態(tài)機(jī)思路、定時(shí)器與PWM、中斷與事件驅(qū)動(dòng)核心器件和基礎(chǔ)框架都齊了。這篇標(biāo)題叫“喲喲喲咱們還差活滴”說白了就是在收尾——一個(gè)正經(jīng)的嵌入式項(xiàng)目光有點(diǎn)燈、按鍵、定時(shí)器這些基本功還不夠還差幾塊真正能“干活”的東西。本篇文章我準(zhǔn)備把項(xiàng)目最后的三塊硬骨頭啃掉第一是OLED屏幕顯示模塊讓設(shè)備長(zhǎng)眼睛第二是片內(nèi)Flash的數(shù)據(jù)持久化存儲(chǔ)讓設(shè)備長(zhǎng)記憶第三是串口通信協(xié)議讓設(shè)備能跟外部對(duì)話。這三塊做完我們這個(gè)基于STM32的C小型環(huán)境監(jiān)測(cè)站才算真正能拉到現(xiàn)場(chǎng)跑起來。適合正在學(xué)STM32和嵌入式C的朋友參考也適合那些已經(jīng)用C寫過一遍、想看看C怎么做嵌入式的人對(duì)比著看。如果你連工程都還沒建起來可以先翻翻這個(gè)系列前面的文章把基礎(chǔ)框架搭好再回來看這篇效果會(huì)好很多。1. 先盤一盤這個(gè)項(xiàng)目還差哪些活1.1 從點(diǎn)燈到產(chǎn)品的距離前幾篇文章搭好了一套能響應(yīng)的框架GPIO的C封裝、按鍵狀態(tài)機(jī)、定時(shí)器PWM輸出頂多算是一塊會(huì)眨眼的開發(fā)板?？梢粋€(gè)真正能拉到現(xiàn)場(chǎng)跑的設(shè)備至少要滿足三個(gè)條件有交互界面、掉電不丟數(shù)據(jù)、能和外部通信。這三個(gè)條件分別對(duì)應(yīng)顯示、存儲(chǔ)和通信接口。我見過很多新手寫STM32項(xiàng)目功能一大堆但一斷電全沒現(xiàn)場(chǎng)要改參數(shù)只能重新燒固件這在實(shí)際工程里是完全不可接受的。所以我們這個(gè)系列的項(xiàng)目實(shí)際是一個(gè)小型環(huán)境監(jiān)測(cè)站。它做什么事情呢用ADC讀取溫濕度傳感器的輸出電壓把結(jié)果換算成實(shí)際溫度用PWM控制一個(gè)小風(fēng)扇根據(jù)溫度自動(dòng)調(diào)速然后把這些數(shù)據(jù)實(shí)時(shí)顯示在OLED屏幕上同時(shí)每隔一段時(shí)間把最新的一批記錄寫入片內(nèi)Flash防止斷電丟失?，F(xiàn)場(chǎng)如果想查看歷史數(shù)據(jù)或者修改報(bào)警閾值就通過串口發(fā)指令給設(shè)備。到這一步它才勉強(qiáng)算一個(gè)“產(chǎn)品原型”而不只是“開發(fā)板代碼”。1.2 三塊“活”的核心難點(diǎn)這三塊活各自都有坑。OLED屏幕最坑的地方是時(shí)序和初始化序列網(wǎng)上抄來的驅(qū)動(dòng)代碼往往是C風(fēng)格的全局變量滿天飛你想把它整合進(jìn)C工程就得做真正的面向?qū)ο笾貥?gòu)。Flash存儲(chǔ)最坑的地方是擦寫壽命和寫保護(hù)機(jī)制不知道原理就很容易把芯片寫廢或者寫完讀出來全是0xFF。串口通信最坑的地方是粘包、丟包和幀格式解析新手最容易犯的錯(cuò)誤就是直接按字節(jié)讀一個(gè)處理一個(gè)結(jié)果數(shù)據(jù)稍微一多就亂套。這篇文章我會(huì)把每一塊的類設(shè)計(jì)思路、關(guān)鍵代碼、背后原理全部講透。不用MDK那種圖形化配置工具代碼全部手寫寄存器加HAL庫(kù)混合方式重點(diǎn)展示C的封裝能力和資源管理思想。編譯器還是沿用前幾篇用的arm-none-eabi-gcc加CMake這套環(huán)境搭建方法在系列第1篇里寫過這里不再重復(fù)。2. OLED顯示模塊的C類封裝方案2.1 為什么選用IIC接口的OLED市面上的0.96寸OLED屏有兩種主流接口SPI版本刷新快但占引腳多IIC版本只需要兩根線。我們這個(gè)環(huán)境監(jiān)測(cè)站數(shù)據(jù)更新頻率其實(shí)很低——溫度傳感器本身一秒也采不了幾次屏幕顯示內(nèi)容也不是動(dòng)態(tài)視頻IIC的帶寬綽綽有余省下來的引腳正好給其他外設(shè)用。我當(dāng)時(shí)選型的時(shí)候其實(shí)還糾結(jié)過要不要上SPI后來算了一筆賬寫一幀屏幕大約需要1024字節(jié)128x64分辨率的SSD1306控制器頁(yè)模式下每頁(yè)8像素IIC標(biāo)準(zhǔn)模式下傳輸速度約100kbps也就是一幀數(shù)據(jù)要約90msSPI接口下這個(gè)時(shí)間能壓到10毫秒以內(nèi)。但我們的刷新頻率只有每秒1次90ms完全夠用換成SPI純屬浪費(fèi)引腳。如果你的項(xiàng)目需要高頻刷新動(dòng)圖或者做儀表盤指針再考慮SPI版本不遲。2.2 OLED類設(shè)計(jì)從裸函數(shù)到對(duì)象封裝這里直接上代碼看看我是怎么把SSD1306的驅(qū)動(dòng)封裝成C類的。頭文件我命名為ssd1306.hpp類的核心接口是這樣設(shè)計(jì)的#pragma once #include cstdint class SSD1306 { public: enum class Color : uint8_t { Black 0, // 滅 White 1, // 亮 Invert 2 // 反色 }; explicit SSD1306(I2C_HandleTypeDef* hi2c, uint8_t addr 0x78); virtual ~SSD1306() default; // 禁止拷貝屏幕資源不允許復(fù)制 SSD1306(const SSD1306) delete; SSD1306 operator(const SSD1306) delete; bool init(); void display(); // 把顯存刷新到物理屏幕 void clear(Color color Color::Black); void drawPixel(uint8_t x, uint8_t y, Color color); void drawChar(uint8_t x, uint8_t y, char c, Color color Color::White); void drawString(uint8_t x, uint8_t y, const char* str, Color color Color::White); private: bool writeCommand(uint8_t cmd); bool writeData(const uint8_t* data, size_t len); void setAddress(uint8_t page, uint8_t col); I2C_HandleTypeDef* _hi2c; uint8_t _addr; uint8_t _buffer[128 * 64 / 8]; // 1KB顯存 };幾個(gè)設(shè)計(jì)點(diǎn)我要重點(diǎn)解釋一下。第一點(diǎn)是拷貝構(gòu)造和賦值運(yùn)算符顯式delete掉這是RAII思想的體現(xiàn)——一個(gè)OLED設(shè)備對(duì)象對(duì)應(yīng)一個(gè)物理外設(shè)如果允許拷貝兩個(gè)實(shí)例同時(shí)操作同一個(gè)I2C地址很容易出現(xiàn)異常的時(shí)序交叉。第二點(diǎn)是I2C的實(shí)例用指針保存而不是直接對(duì)象嵌入。這么做是為了在構(gòu)造時(shí)不依賴具體IIC初始化順序可以在main函數(shù)中先初始化HAL的I2C外設(shè)再把句柄傳給OLED對(duì)象保持C對(duì)象生命周期和硬件外設(shè)生命周期解耦。2.3 關(guān)鍵實(shí)現(xiàn)與初始化序列詳解初始化序列是SSD1306最折騰人的地方。不同廠家屏幕的初始化命令大同小異但有幾條命令的順序錯(cuò)了屏幕就白屏。下面是我的初始化函數(shù)核心部分bool SSD1306::init() { // 顯示器關(guān)閉穩(wěn)定電源 writeCommand(0xAE); // 設(shè)置顯示時(shí)鐘分頻因子/振蕩器頻率 writeCommand(0xD5); writeCommand(0x80); // 設(shè)置多路復(fù)用比0.96寸的是64行 writeCommand(0xA8); writeCommand(0x3F); // 設(shè)置顯示偏移 writeCommand(0xD3); writeCommand(0x00); // 設(shè)置顯示起始行 writeCommand(0x40); // 設(shè)置電荷泵使能這是關(guān)鍵 writeCommand(0x8D); writeCommand(0x14); // 設(shè)置內(nèi)存尋址模式為頁(yè)模式水平模式也行看需求 writeCommand(0x20); writeCommand(0x00); // 設(shè)置列地址范圍 writeCommand(0x21); writeCommand(0x00); writeCommand(0x7F); // 設(shè)置頁(yè)地址范圍 writeCommand(0x22); writeCommand(0x00); writeCommand(0x07); // 對(duì)比度設(shè)置為最大 writeCommand(0x81); writeCommand(0xCF); // 預(yù)充電周期 writeCommand(0xD9); writeCommand(0xF1); // 設(shè)置COM引腳硬件配置 writeCommand(0xDA); writeCommand(0x02); // 設(shè)置VCOMH取消選擇電平 writeCommand(0xDB); writeCommand(0x40); // 設(shè)置顯示全亮 writeCommand(0xA4); // 設(shè)置顯示模式為正常 writeCommand(0xA6); // 開啟顯示 writeCommand(0xAF); clear(Color::Black); display(); return true; }這里有一個(gè)我踩過的坑必須提一下。電荷泵命令0x8D 0x14如果漏了屏幕是徹底不亮的因?yàn)镾SD1306內(nèi)部升壓電路沒有使能OLED面板根本沒有驅(qū)動(dòng)電壓。另一個(gè)坑是頁(yè)地址模式下的坐標(biāo)換算很多人直接按像素坐標(biāo)算顯存偏移結(jié)果顯示出來的字符東倒西歪。頁(yè)尋址模式下顯存被分成8頁(yè)每頁(yè)是一個(gè)128字節(jié)的行覆蓋8個(gè)像素高度。畫一個(gè)點(diǎn)的時(shí)候需要先算出它屬于第幾頁(yè)、該頁(yè)的第幾位然后對(duì)顯存字節(jié)做按位或操作。我封裝了drawPixel來處理這個(gè)問題void SSD1306::drawPixel(uint8_t x, uint8_t y, Color color) { if (x 128 || y 64) return; uint16_t index (y / 8) * 128 x; uint8_t bit 1 (y % 8); switch (color) { case Color::White: _buffer[index] | bit; break; case Color::Black: _buffer[index] ~bit; break; case Color::Invert: _buffer[index] ^ bit; break; } }這里我把x和y單獨(dú)做了邊界判斷。初學(xué)者很喜歡忽略這種防御性寫法但在C嵌入式里越界訪問是一個(gè)靜默的災(zāi)難——它不會(huì)立刻崩而是悄悄篡改相鄰變量的值查錯(cuò)的時(shí)候能讓你懷疑人生。顯存_buffer是1KB的數(shù)組邊界不檢查坐標(biāo)一跑偏可能把狀態(tài)變量或者中斷標(biāo)志位給改了。2.4 顯示刷新策略局部刷新和整幀刷新怎么選OLED還有一個(gè)和LCD不一樣的地方它不需要持續(xù)掃描刷新。LCD如果時(shí)序不對(duì)會(huì)閃爍OLED只要選通矩陣并保持驅(qū)動(dòng)電壓它會(huì)一直顯示整個(gè)幀緩沖區(qū)的內(nèi)容。這也是為什么我們要維護(hù)一個(gè)1KB的_buffer——你要改哪個(gè)像素直接改緩沖里對(duì)應(yīng)的字節(jié)最后調(diào)display()把整塊緩沖發(fā)過去就行屏幕不會(huì)閃。但在低配IIC上整幀刷新確實(shí)慢。實(shí)測(cè)下來128x64的整屏數(shù)據(jù)加上控制頭總計(jì)約1063字節(jié)標(biāo)準(zhǔn)模式100kbps下全刷一次要95毫秒左右。所以如果你的UI要做一個(gè)進(jìn)度條動(dòng)畫或者數(shù)字頻繁跳動(dòng)建議做一個(gè)“臟矩形”機(jī)制記錄哪些區(qū)域的數(shù)據(jù)變了只更新那幾頁(yè)的字節(jié)。SSD1306支持設(shè)置列地址和頁(yè)地址范圍我們可以只傳輸變化的那部分顯存。我在drawString和drawChar上面沒做這么復(fù)雜的優(yōu)化因?yàn)榄h(huán)境監(jiān)測(cè)站一秒刷一次完全夠用但如果你要做小游戲或者示波器這個(gè)局部刷新就很有必要了。3. Flash數(shù)據(jù)存儲(chǔ)模塊掉電不丟的關(guān)鍵3.1 為什么選擇片內(nèi)Flash而不是外掛EEPROM這個(gè)項(xiàng)目的數(shù)據(jù)量不大每一幀記錄可以壓縮到一個(gè)結(jié)構(gòu)體里大概16字節(jié)。一天存1440條一分鐘一條才23KB左右。STM32F103系列芯片的Flash容量從64KB到512KB不等我們用的中容量芯片有64KB主Flash其中足夠存放固件、字庫(kù)還能剩余將近30KB給我們做數(shù)據(jù)存儲(chǔ)。這就沒必要外掛一塊IIC的AT24C02或者SPI的W25Q64了。但片內(nèi)Flash有一個(gè)致命限制擦寫壽命。STM32F103的Flash擦寫次數(shù)標(biāo)稱1萬次數(shù)據(jù)保留時(shí)間20年。如果每秒鐘寫一次不到3小時(shí)就壽命耗盡。所以直接用片內(nèi)Flash做高速數(shù)據(jù)記錄是絕對(duì)不行的必須做“磨損均衡”——把寫入分散到不同的扇區(qū)讓每個(gè)扇區(qū)的擦寫次數(shù)大致均勻。3.2 小容量平臺(tái)的磨損均衡策略我采用的方案是雙扇區(qū)交替存儲(chǔ)加RAM緩存。STM32F103的Flash扇區(qū)大小不一小容量芯片的扇區(qū)通常1KB但我們選用的中容量芯片每頁(yè)是1KB64KB版本分成64頁(yè)。實(shí)際操作上我把最后8頁(yè)8KB劃分成兩個(gè)邏輯存儲(chǔ)區(qū)每區(qū)4KB分別標(biāo)記為A區(qū)和B區(qū)。每條記錄是一個(gè)固定長(zhǎng)度的結(jié)構(gòu)體帶CRC校驗(yàn)一個(gè)存儲(chǔ)區(qū)可以存大約256條記錄。寫入策略是這樣的數(shù)據(jù)先累積在RAM環(huán)形緩沖里湊滿一批比如32條再一次性寫入當(dāng)前活躍區(qū)?；钴S區(qū)寫滿后把最新數(shù)據(jù)放到另一個(gè)區(qū)并把舊區(qū)整體擦除。下次再寫滿新區(qū)時(shí)再擦除另一個(gè)區(qū)。這樣每個(gè)扇區(qū)實(shí)際擦寫次數(shù)就減少了一半。配合批寫平均下來每天的擦寫次數(shù)大約在60次左右理論上可以用好幾年完全應(yīng)付這個(gè)項(xiàng)目的生命周期。3.3 存儲(chǔ)結(jié)構(gòu)體的C序列化處理C里直接寫結(jié)構(gòu)體到Flash是很爽的事情但有兩個(gè)坑一是對(duì)齊問題二是端序問題。先看代碼struct SensorRecord { uint32_t timestamp; // Unix時(shí)間戳 float temperature; // 溫度 float humidity; // 濕度 uint16_t fanDuty; // 風(fēng)扇占空比百分比 uint8_t state; // 設(shè)備狀態(tài)位 uint8_t reserved[3]; // 保留字段對(duì)齊填充 uint32_t crc32; // 校驗(yàn) }; static_assert(sizeof(SensorRecord) 24, 記錄結(jié)構(gòu)體大小必須是24字節(jié));我顯式地把reserved[3]這個(gè)填充字節(jié)加進(jìn)去然后用static_assert在編譯期卡死結(jié)構(gòu)體大小。這是嵌入式C的一個(gè)很實(shí)用的小技巧——編譯期就知道結(jié)構(gòu)體有沒有被編譯器悄悄對(duì)齊不至于燒錄之后才發(fā)現(xiàn)讀出來跟寫進(jìn)去的對(duì)不上。浮點(diǎn)數(shù)存儲(chǔ)在這里沒有做字節(jié)序轉(zhuǎn)換因?yàn)镾TM32是ARM小端自寫自讀不存在端序問題。但如果有一天你要把數(shù)據(jù)導(dǎo)出到PC上解析x86也是小端可以不做轉(zhuǎn)換如果要發(fā)到網(wǎng)絡(luò)或者轉(zhuǎn)成大端平臺(tái)就得寫一個(gè)htonf之類的函數(shù)處理了。3.4 Flash寫入操作的C封裝Flash操作最重要的原則是擦除前必須解鎖寫完必須加鎖且不能在執(zhí)行Flash操作時(shí)響應(yīng)中斷里的Flash讀寫請(qǐng)求?？匆幌麓aclass FlashStorage { public: enum class Status { Ok, WriteError, EraseError, Busy }; FlashStorage(uint32_t baseAddr, size_t sectorSize); Status appendRecord(const SensorRecord rec); Status eraseBank(uint8_t bankId); size_t readRecords(SensorRecord* outBuf, size_t maxCount); uint8_t activeBank() const; private: Status unlock(); Status lock(); bool isBusy() const; uint32_t _baseAddr; size_t _sectorSize; uint8_t _active; uint16_t _recordCount; };關(guān)鍵在unlock和lock兩個(gè)私有方法FlashStorage::Status FlashStorage::unlock() { while (isBusy()) return Status::Busy; FLASH-KEYR 0x45670123; FLASH-KEYR 0xCDEF89AB; return Status::Ok; } FlashStorage::Status FlashStorage::lock() { FLASH-CR | FLASH_CR_LOCK; return Status::Ok; }STM32F103的Flash解鎖序列是固定兩個(gè)密鑰字順序反了或者中間插入其他寫操作都會(huì)導(dǎo)致總線錯(cuò)誤。另一個(gè)必須牢記的是擦除操作不能斷在中間——如果擦除過程中又來了一個(gè)中斷中斷代碼也去做Flash操作那這個(gè)芯片就真的廢了。實(shí)際工程中最簡(jiǎn)單的做法是在擦除和編程期間把對(duì)外設(shè)的中斷標(biāo)志位屏蔽掉或者干脆用一個(gè)全局互斥量攔住所有可能觸發(fā)Flash操作的路徑。3.5 掉電保護(hù)機(jī)制值得做的兩個(gè)細(xì)節(jié)這個(gè)模塊我額外做了兩個(gè)保險(xiǎn)。第一個(gè)是CRC校驗(yàn)每24字節(jié)記錄后面跟著4字節(jié)CRC32讀取的時(shí)候先校驗(yàn)再解析。這在平時(shí)感覺不到用處直到有一次我故意在測(cè)試中讓板子寫數(shù)據(jù)寫到一半直接斷電恢復(fù)供電后讀出來的記錄里有一條CRC錯(cuò)誤被完整跳過其他數(shù)據(jù)全部完好。有了CRC掉電損壞只是丟一條壞記錄而不是讓整個(gè)數(shù)據(jù)庫(kù)不可用。第二個(gè)是存儲(chǔ)區(qū)頭部標(biāo)記。每個(gè)區(qū)前16字節(jié)不存業(yè)務(wù)數(shù)據(jù)而是存一個(gè)魔數(shù)0xA5A5A5A5、區(qū)ID、當(dāng)前記錄條數(shù)、以及最后一次寫入序號(hào)。設(shè)備上電時(shí)通過對(duì)比兩個(gè)區(qū)的寫入序號(hào)來選擇活躍區(qū)序號(hào)大的說明是最新的。如果沒有這個(gè)序號(hào)機(jī)制雙區(qū)交替存儲(chǔ)很容易出現(xiàn)“最新數(shù)據(jù)在哪個(gè)區(qū)”的混淆到時(shí)候恢復(fù)出舊數(shù)據(jù)就麻煩了。4. 串口通信協(xié)議讓設(shè)備開口說話4.1 幀格式設(shè)計(jì)為什么不用裸發(fā)串口通信最忌諱的就是裸發(fā)。你直接printf(temp25.3)PC端看著是挺順眼但是回傳指令怎么處理字符串解析容易出錯(cuò)中文編碼問題、變長(zhǎng)字段問題都是坑。更規(guī)范的做法是設(shè)計(jì)一套二進(jìn)制幀協(xié)議。我用的幀格式很簡(jiǎn)單總共6字節(jié)固定頭加變長(zhǎng)載荷加2字節(jié)CRC16校驗(yàn)| 0xAA | 0x55 | LEN | CMD | DATA[LEN] | CRC16_L | CRC16_H |0xAA 0x55是幀頭用于同步LEN是DATA段的字節(jié)數(shù)最大255CMD是命令碼例如0x01表示讀取當(dāng)前狀態(tài)0x02表示設(shè)置報(bào)警閾值DATA是參數(shù)區(qū)長(zhǎng)度由LEN決定CRC16校驗(yàn)整個(gè)幀含LEN和CMD防止數(shù)據(jù)錯(cuò)誤被當(dāng)成有效指令選0xAA 0x55做幀頭是有講究的——這兩個(gè)字節(jié)的二進(jìn)制模式分別是10101010和01010101在串口空閑線上很容易識(shí)別誤碼撞上的概率低。實(shí)際調(diào)試發(fā)現(xiàn)偶爾數(shù)據(jù)線上有個(gè)毛刺收到的會(huì)是0xAA 0xAA第二個(gè)字節(jié)不匹配直接丟棄容錯(cuò)很好。4.2 環(huán)形緩沖區(qū)加狀態(tài)機(jī)的接收解析串口接收端不能“收一個(gè)字節(jié)處理一個(gè)字節(jié)”否則一個(gè)幀被調(diào)度器分成兩段到達(dá)程序就傻眼了。正確的做法是中斷服務(wù)函數(shù)只把字節(jié)塞進(jìn)一個(gè)環(huán)形緩沖區(qū)主循環(huán)里再跑狀態(tài)機(jī)解析。先看環(huán)形緩沖區(qū)的實(shí)現(xiàn)這個(gè)類很簡(jiǎn)單但是嵌入式串口的基礎(chǔ)設(shè)施template typename T, size_t N class RingBuffer { public: bool push(const T item) { if (isFull()) return false; _buf[_head] item; _head (_head 1) % N; return true; } bool pop(T item) { if (isEmpty()) return false; item _buf[_tail]; _tail (_tail 1) % N; return true; } bool isEmpty() const { return _head _tail; } bool isFull() const { return (_head 1) % N _tail; } private: T _buf[N]; size_t _head 0; size_t _tail 0; };用模板實(shí)現(xiàn)的好處是未來如果要用SPI或者CAN接收緩沖區(qū)可以復(fù)用同一份代碼提高工程復(fù)用率。這里我取的是256字節(jié)的容量串口115200波特率下能緩沖約22毫秒的數(shù)據(jù)完全足夠主循環(huán)空閑時(shí)消化。解析狀態(tài)機(jī)我用了枚舉加switch的模式這樣可讀性比一長(zhǎng)串if-else強(qiáng)很多enum class FrameState : uint8_t { WaitHead1, WaitHead2, WaitLen, WaitCmd, WaitData, WaitCrcLow, WaitCrcHigh }; FrameState _state FrameState::WaitHead1; uint8_t _cmdBuf[256]; uint8_t _lenBuf 0; uint8_t _dataIdx 0; uint8_t _crcRecv[2]; bool FrameParser::parseByte(uint8_t byte) { switch (_state) { case FrameState::WaitHead1: if (byte 0xAA) _state FrameState::WaitHead2; break; case FrameState::WaitHead2: _state (byte 0x55) ? FrameState::WaitLen : FrameState::WaitHead1; break; case FrameState::WaitLen: _lenBuf byte; _dataIdx 0; _state FrameState::WaitCmd; break; case FrameState::WaitCmd: _cmdBuf[_dataIdx] byte; _state (_lenBuf 0) ? FrameState::WaitData : FrameState::WaitCrcLow; break; // ... 數(shù)據(jù)位按_lenBuf逐個(gè)接收然后進(jìn)入CRC校驗(yàn)位 } return false; // 一幀完整接收時(shí)返回true }這個(gè)狀態(tài)機(jī)的優(yōu)勢(shì)在于不會(huì)因?yàn)橹虚g錯(cuò)一個(gè)字節(jié)就全盤崩潰。數(shù)據(jù)段有噪聲CRC校驗(yàn)會(huì)兜底CRC壞了這一幀被丟棄狀態(tài)機(jī)留在WaitHead1繼續(xù)找下一幀的幀頭不需要復(fù)位。4.3 在C里做命令分發(fā)的技巧幀解析出來之后要根據(jù)CMD分發(fā)給不同的處理函數(shù)。這里又是個(gè)體現(xiàn)C優(yōu)勢(shì)的地方。如果用C語(yǔ)言就是一堆switch-case用C我們可以做命令注冊(cè)表類似路由器按指令碼查表調(diào)函數(shù)。using CommandHandler std::functionvoid(const uint8_t* data, uint8_t len); class CommandDispatcher { public: void registerHandler(uint8_t cmd, CommandHandler handler) { _handlers[cmd] std::move(handler); } bool dispatch(uint8_t cmd, const uint8_t* data, uint8_t len) { auto it _handlers.find(cmd); if (it _handlers.end()) return false; it-second(data, len); return true; } private: std::mapuint8_t, CommandHandler _handlers; };使用std::function雖然比裸函數(shù)指針多一些開銷堆分配和類型擦除但換來的是可以用Lambda表達(dá)式注冊(cè)比如這樣cmdDispatcher.registerHandler(0x01, [](const uint8_t* data, uint8_t len) { // 讀取當(dāng)前溫度并返回 float temp sensor.getTemperature(); uint8_t reply[4]; memcpy(reply, temp, 4); uart.sendFrame(0x81, reply, 4); });在STM32F103這種Cortex-M3上std::function容器確實(shí)會(huì)帶來Flash占用增大和棧開銷增加的問題所以我實(shí)際項(xiàng)目里做了一個(gè)取舍只對(duì)命令分發(fā)用std::function環(huán)形緩沖用模板其他地方盡量不用STL容器。整個(gè)工程編譯下來Flash占用約58KBRAM占用約11KB對(duì)這個(gè)64KB Flash的芯片來說已經(jīng)是極限操作了。你要是覺得緊張可以把分發(fā)表改成靜態(tài)函數(shù)指針數(shù)組效果類似但代碼會(huì)更C風(fēng)格一些。4.4 串口狀態(tài)反饋與斷線重連處理串口通信不僅要能收還要能判斷鏈路是否正常。我做了一個(gè)簡(jiǎn)單的雙向心跳機(jī)制設(shè)備每秒發(fā)送一個(gè)0x10心跳幀如果PC端連續(xù)5秒沒有回應(yīng)設(shè)備就把通信狀態(tài)置為離線OLED屏幕上顯示一個(gè)警告圖標(biāo)。如果設(shè)備連續(xù)3秒沒有發(fā)心跳異常復(fù)位或死機(jī)PC端也會(huì)彈出提示。這個(gè)心跳的實(shí)現(xiàn)在代碼里其實(shí)就是定時(shí)器中斷服務(wù)里置一個(gè)標(biāo)志主循環(huán)查標(biāo)志然后發(fā)送幀。不復(fù)雜但我提出來是因?yàn)楹芏喑鯇W(xué)者做完通信模塊就以為萬事大吉沒有考慮鏈路異常狀態(tài)導(dǎo)致現(xiàn)場(chǎng)調(diào)試時(shí)一頭霧水——板子明明燒好了為什么收不到數(shù)據(jù)很可能是串口線斷了或者USB轉(zhuǎn)串口芯片沒裝驅(qū)動(dòng)而設(shè)備悶不吭聲你根本不知道哪里出了問題。有了心跳機(jī)制至少能在UI上直觀看到通信斷沒斷。5. 聯(lián)調(diào)階段的高頻問題與排查實(shí)錄5.1 OLED白屏問題電荷泵和初始化順序我聯(lián)調(diào)第一天就栽在OLED上。斷電重上電后屏幕完全白屏沒有任何顯示。排查過程如下先用邏輯分析儀抓I2C波形確認(rèn)有數(shù)據(jù)在傳輸?shù)刂芬彩?x78說明通信本身是通的。然后對(duì)比我手里的SSD1306 datasheet發(fā)現(xiàn)我初始化時(shí)漏了電荷泵使能。這個(gè)命令必須在顯示開啟0xAF之前發(fā)送且兩條命令之間不能插入其他命令部分芯片手冊(cè)明確要求連續(xù)發(fā)送。修正后屏幕正常點(diǎn)亮。另一個(gè)白屏原因是邏輯電源不穩(wěn)定IIC上拉電阻沒接或者阻值太大。STM32的IIC引腳是開漏輸出必須外部上拉到3.3V才能產(chǎn)生高電平。忘了接上拉電阻時(shí)波形根本抬不起來邏輯分析儀上看到的是亂碼一樣的毛刺。我一次性踩了這兩個(gè)坑在這里啰嗦一遍就是為了讓看文章的朋友少走彎路。5.2 串口亂碼與波特率漂移第二個(gè)高頻問題是串口亂碼。現(xiàn)象很經(jīng)典設(shè)備啟動(dòng)時(shí)打印一堆正常日志過幾分鐘后亂碼重啟又好了。最后查出來是晶振問題——我的板子用了內(nèi)部RC振蕩器HSI頻率漂移在2%左右115200波特率的誤差容忍度大約是±2%一開始湊合能用溫度一上來RC漂移加速直接超過容限串口就亂了。解決辦法是切換到外部8MHz晶振HSE并把串口波特率從115200降到57600留足余量。降低波特率是為了給協(xié)議解析更多時(shí)間但這會(huì)犧牲傳輸速度。實(shí)際項(xiàng)目中測(cè)溫?cái)?shù)據(jù)的傳輸量很小每秒幾幀57600完全夠。如果你也有類似情況建議先量一下實(shí)際波特率再考慮換晶振別一上來就怪代碼。5.3 Flash寫入后讀出來全是0xFF這類問題多半是地址對(duì)齊或者沒有先擦后寫。STM32的Flash只能把1擦成0不能單獨(dú)把0寫成1。你要更新一個(gè)字節(jié)必須先整塊擦除再重新寫入。如果寫之前沒有擦寫入操作執(zhí)行了但實(shí)際沒成功讀出來還是0xFF。另外有些型號(hào)Flash需要半字16位對(duì)齊寫入。我用的是HAL庫(kù)的HAL_FLASH_Program如果傳入的地址偏了1個(gè)字節(jié)它不會(huì)報(bào)錯(cuò)但寫入的數(shù)據(jù)會(huì)落到錯(cuò)誤的地址上讀出來自然不對(duì)。解決方法是所有Flash地址全部對(duì)齊到4字節(jié)結(jié)構(gòu)體大小也設(shè)計(jì)成4的倍數(shù)。我的SensorRecord是24字節(jié)剛好整除。5.4 中斷優(yōu)先級(jí)引發(fā)的數(shù)據(jù)丟失串口丟幀還有一個(gè)隱蔽的殺手——中斷優(yōu)先級(jí)配置。STM32的NVIC中斷優(yōu)先級(jí)分組如果配置不當(dāng)串口中斷可能會(huì)被定時(shí)器中斷長(zhǎng)時(shí)間打斷。我的定時(shí)器每1毫秒觸發(fā)一次中斷服務(wù)里做了不少浮點(diǎn)運(yùn)算溫度換算耗時(shí)接近100微秒。115200波特率下接收一個(gè)字節(jié)的時(shí)間約87微秒如果定時(shí)器中斷剛好在串口字節(jié)到達(dá)時(shí)觸發(fā)且優(yōu)先級(jí)更高串口中斷會(huì)被推遲硬件接收寄存器可能被下一個(gè)字節(jié)覆蓋字節(jié)就丟了。排查過程很痛苦一開始偶爾丟幀我把串口波特率降下來現(xiàn)象減輕但偶爾還會(huì)出現(xiàn)。后來用示波器對(duì)比了串口接收引腳和定時(shí)器觸發(fā)信號(hào)終于看到了中斷搶占的時(shí)間窗口。解決辦法把串口接收中斷的搶占優(yōu)先級(jí)調(diào)到最高0定時(shí)器中斷設(shè)為1確保沒有其他中斷能延遲串口字節(jié)接收。這個(gè)坑特別推薦大家提前規(guī)避用CubeMX配置NVIC時(shí)UART接收中斷優(yōu)先級(jí)的設(shè)置一定要高于一切非關(guān)鍵中斷。5.5 溫濕度傳感器讀取值與手邊儀表對(duì)不上這個(gè)問題其實(shí)不是代碼問題但屬于聯(lián)調(diào)階段必然遇到的。傳感器輸出的電壓和溫濕度的換算曲線芯片手冊(cè)上給的是近似公式實(shí)際每個(gè)傳感器個(gè)體都有偏差。我做了一個(gè)簡(jiǎn)單的軟件校準(zhǔn)用冰水混合物和沸水做兩個(gè)標(biāo)準(zhǔn)溫度點(diǎn)分別讀ADC初始值然后做線性插值。具體做法是在Sensor類里增加兩個(gè)校準(zhǔn)系數(shù)字段通過串口命令在線更新更新后寫入Flash保存。class Sensor { public: void setCalibration(float offset, float scale) { _offset offset; _scale scale; } float readCelsius() { float raw _adc.readVoltage(); return (raw - _offset) * _scale; } private: float _offset; float _scale; };這套方法雖然不是高精度計(jì)量級(jí)的方案但對(duì)環(huán)境監(jiān)測(cè)這種應(yīng)用來說足夠了。校準(zhǔn)系數(shù)存Flash里這樣換板子也不用重新燒固件對(duì)量產(chǎn)和維護(hù)非常友好。6. 從工程角度再聊幾句C嵌入式項(xiàng)目的組織心得6.1 內(nèi)存分配策略只在初始化時(shí)newC的new和delete在嵌入式環(huán)境里是危險(xiǎn)操作。頻繁堆分配會(huì)導(dǎo)致碎片化長(zhǎng)時(shí)間運(yùn)行系統(tǒng)內(nèi)存越來越少最終malloc失敗程序崩潰。我的策略是整個(gè)系統(tǒng)只在啟動(dòng)時(shí)做一次堆分配把傳感器對(duì)象、存儲(chǔ)對(duì)象、通信對(duì)象全部用new創(chuàng)建一次之后永不釋放。本質(zhì)上做的是“啟動(dòng)即定型”的靜態(tài)對(duì)象池思路跟C語(yǔ)言的靜態(tài)變量異曲同工但保留了C的構(gòu)造和析構(gòu)邏輯代碼更清晰。如果你實(shí)在需要?jiǎng)討B(tài)分配強(qiáng)烈建議實(shí)現(xiàn)一個(gè)固定大小的內(nèi)存池或者使用嵌入式C里常用的pmr多態(tài)分配器思想把std::vector的分配器指定成一塊靜態(tài)數(shù)組空間。這樣雖然不能完全避免碎片化但至少可控。6.2 把狀態(tài)機(jī)、回調(diào)、配置分離整個(gè)工程入口函數(shù)現(xiàn)在長(zhǎng)這樣int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_Init(); SSD1306 display(hi2c1); Sensor tempSensor(hadc1); FlashStorage storage(FLASH_DATA_BASE, 4096); UartProtocol proto(huart1); AppConfig config; config.loadFrom(storage); proto.registerHandler(0x02, [](const uint8_t* data, uint8_t len) { config.setThreshold(data[0]); storage.saveConfig(config); }); while (1) { proto.processIncoming(); tempSensor.update(); float t tempSensor.readCelsius(); if (t config.threshold() !config.fanRunning()) { config.fanRunning(true); } display.drawString(0, 0, Temp: ); // ... 省略界面組裝代碼 display.display(); LL_mDelay(100); } }這種組織方式的優(yōu)點(diǎn)是“每一行都知道自己在干嘛”。配置對(duì)象隔離出來業(yè)務(wù)邏輯只跟配置打交道不直接操作Flash和串口。后續(xù)要加個(gè)Wi-Fi模塊或者藍(lán)牙只改UartProtocol和命令分發(fā)部分傳感器、存儲(chǔ)、顯示層完全不用動(dòng)。6.3 編譯選項(xiàng)和警告等級(jí)最后說一下編譯工程設(shè)置。我用CMake管理工程編譯選項(xiàng)如下target_compile_options(${PROJECT_NAME} PRIVATE -mcpucortex-m3 -mthumb -Os -ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -Wconversion -Wunreachable-code -fno-exceptions -fno-rtti )-fno-exceptions和-fno-rtti是嵌入式C的標(biāo)準(zhǔn)操作——異常支持和運(yùn)行時(shí)類型識(shí)別會(huì)顯著增加代碼體積和棧開銷在一個(gè)64KB Flash的芯片上沒必要開。-Wconversion強(qiáng)制檢查隱式類型轉(zhuǎn)換能提前抓出一堆浮點(diǎn)轉(zhuǎn)整數(shù)的溢出問題。-Os優(yōu)化為了代碼體積配合-ffunction-sections讓鏈接器把未使用的函數(shù)剝掉最終固件體積可以壓縮很多。這套組合拳打完之后編譯輸出沒有任何warning這很重要。我見過很多人在嵌入式工程里無視warning結(jié)果一個(gè)隱蔽的符號(hào)截?cái)鄦栴}在生產(chǎn)現(xiàn)場(chǎng)炸了。在資源受限的MCU上每個(gè)warning都值得認(rèn)真對(duì)待因?yàn)樗鼈兺馕吨炊x行為或數(shù)據(jù)溢出。收尾的一點(diǎn)經(jīng)驗(yàn)之談到這里這個(gè)基于STM32的C小型環(huán)境監(jiān)測(cè)站就完整了從傳感器的模擬量采集到數(shù)據(jù)處理和閾值判斷再到OLED顯示、Flash持久化、串口通信整個(gè)鏈路打通設(shè)備已經(jīng)具備基本的現(xiàn)場(chǎng)運(yùn)行能力。實(shí)事求是地說前5篇的框架加上這一篇的三塊功能前后大概花了一個(gè)多月的業(yè)余時(shí)間中間踩的坑數(shù)量比預(yù)期多不少但每一步踩坑都對(duì)應(yīng)一個(gè)真實(shí)的工程經(jīng)驗(yàn)。我個(gè)人操作下來最大的體會(huì)是C在嵌入式里的價(jià)值不是語(yǔ)法花哨而是“邊界清晰”。類的封裝把硬件初始化和業(yè)務(wù)邏輯隔離狀態(tài)機(jī)關(guān)在類內(nèi)部外部根本不需要知道協(xié)議怎么解析RAII把資源所有權(quán)管起來避免了一個(gè)指針到處飛的野路子。這套代碼如果改用C寫大概率會(huì)退回到一堆全局變量加散落各處的中斷處理函數(shù)調(diào)試時(shí)心智負(fù)擔(dān)會(huì)重很多。最后再分享一個(gè)小技巧聯(lián)調(diào)階段務(wù)必用邏輯分析儀或者示波器不要只盯著串口調(diào)試助手里的字符串猜。I2C波形、UART波形、中斷搶占時(shí)序這些用眼睛肉眼確認(rèn)一次比在代碼里加一千行printf都有用。工具到位調(diào)試效率翻倍。后續(xù)如果還想繼續(xù)擴(kuò)展這個(gè)框架可以往LoRa組網(wǎng)方向走傳感器數(shù)據(jù)上云也別急著換Linux板子單片機(jī)加個(gè)4G模塊照樣能干前提是你把存儲(chǔ)和通信這兩層抽象做好。