群里剛有人問了句CLion 里重定向 printf為什么都在寫 _writefputc 不才是標(biāo)準(zhǔn)做法嗎這一下把我拉回第一次在 CLion 里調(diào)串口日志的夜晚。當(dāng)時(shí)我照著網(wǎng)上老教程往工程里塞了個(gè)重寫 fputc 的函數(shù)信誓旦旦地確認(rèn)了三次寄存器配置結(jié)果串口助手就是一片寂靜。折騰到深夜最后把 fputc 換成 _write立馬就好了。這個(gè)現(xiàn)象不是個(gè)例。很多從 Keil、IAR 轉(zhuǎn)過來的朋友第一次在 CLion 里做嵌入式開發(fā)都會(huì)在這里卡一下。這篇文章就把這個(gè)“為什么”徹底講明白C 標(biāo)準(zhǔn)庫的 printf 到底怎么把數(shù)據(jù)送出去fputc 和 _write 分別在哪個(gè)環(huán)節(jié)干活CLion 的嵌入式工具鏈又有什么特殊之處以及碰到亂碼、報(bào)錯(cuò)、卡死時(shí)應(yīng)該往哪個(gè)方向排查。1. 問題現(xiàn)象重寫 fputc 明明是標(biāo)準(zhǔn)做法為什么在 CLion 里不生效1.1 一個(gè)非常典型的開發(fā)場(chǎng)景先描述一下我這個(gè)項(xiàng)目當(dāng)時(shí)的狀態(tài)芯片是 STM32F103IDE 是 CLion工具鏈?zhǔn)?ARM GCC工程用 STM32CubeMX 生成通過 CLion 的 Embedded Development 插件加載。我要做的事情非常簡(jiǎn)單就是把 printf 的輸出重定向到 USART1方便看調(diào)試信息。按照網(wǎng)上八成教程里的寫法我先加了這么一段int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, HAL_MAX_DELAY); return ch; }這段代碼在 Keil 的工程里、在 IAR 的工程里幾乎是標(biāo)準(zhǔn)答案。邏輯也很直觀printf 最終會(huì)逐個(gè)字符調(diào)用 fputc我只要把 fputc 指向串口發(fā)送數(shù)據(jù)就能出來。所以我當(dāng)時(shí)的判斷是問題只可能出在別處比如串口沒初始化、時(shí)鐘沒配好、杜邦線松了。1.2 現(xiàn)象記錄編譯通過串口沒有輸出我把 HAL_UART_Transmit 的返回值打出來也看不到任何報(bào)錯(cuò)因?yàn)檎麄€(gè)發(fā)送鏈路根本沒被觸發(fā)。詭異的是我用調(diào)試器在 fputc 里下斷點(diǎn)printf 執(zhí)行到一半斷點(diǎn)壓根沒進(jìn)來。后來我意識(shí)到一個(gè)關(guān)鍵線索printf 是庫函數(shù)它內(nèi)部不一定調(diào)用我這個(gè) fputc。不同的 C 庫對(duì) printf 的實(shí)現(xiàn)方式不同有的庫里 fputs、fwrite、fputc 是一套完整的緩沖機(jī)制有的庫為了省空間干脆讓 printf 直接往底層 write 接口塞數(shù)據(jù)繞過了 stdio 的字符級(jí)接口。我的 fputc 等于寫了一個(gè)沒人調(diào)用的空函數(shù)編譯不報(bào)錯(cuò)運(yùn)行沒效果純屬自我安慰。更麻煩的是在某些庫里printf 被編譯成了半主機(jī)模式semihosting版本代碼會(huì)嘗試往調(diào)試器的“虛擬終端”輸出數(shù)據(jù)。聽起來很美好問題是開發(fā)板上的調(diào)試器沒接 RTT、沒開 semihosting 支持于是 printf 調(diào)用直接進(jìn)入一個(gè)死循環(huán)或者空跑表現(xiàn)就是“程序沒崩但不輸出”。這種問題排查起來特別坑因?yàn)樗幌裼布e(cuò)誤那么明顯。1.3 排查思路先弄清 printf 身后到底是誰我用一個(gè)很笨的辦法定位了問題反匯編看 printf 內(nèi)部調(diào)用。在 arm-none-eabi-objdump 里拉起工程生成的 .elf 文件搜索 printf 的實(shí)現(xiàn)段發(fā)現(xiàn)它確實(shí)沒有調(diào)用我的 fputc而是跳到 _write 這個(gè)符號(hào)?？吹侥切写a的瞬間我基本就明白了這版的 C 運(yùn)行庫里stdio 往上走的是系統(tǒng)調(diào)用抽象層而不是老的字符設(shè)備層。做一個(gè)小類比。fputc 就像一個(gè)門店的前臺(tái)專門接待“單個(gè)字符”這種小請(qǐng)求_write 則是后臺(tái)倉庫處理“一段字節(jié)”這種批量請(qǐng)求。printf 在有些體系里會(huì)老老實(shí)實(shí)把每個(gè)字符遞給前臺(tái)在另一些體系里它直接把一整塊數(shù)據(jù)甩給倉庫省得前臺(tái)一個(gè)個(gè)搬。你重寫 fputc就是把前臺(tái)換成了自己人但倉庫那邊壓根不認(rèn)識(shí)你貨自然發(fā)不出去。這個(gè)類比其實(shí)也解釋了為什么兩種做法都對(duì)但適用的“庫版本”和“編譯環(huán)境”完全不同。搞清楚當(dāng)前工具鏈里 printf 到底跟誰對(duì)接才是解決問題真正的鑰匙。2. 核心原理_write 和 fputc 在標(biāo)準(zhǔn)庫里究竟差在哪一層2.1 C 標(biāo)準(zhǔn)庫的分層架構(gòu)要把這個(gè)問題說透得先捋一遍 C 標(biāo)準(zhǔn)庫的層級(jí)結(jié)構(gòu)。我們平時(shí)寫 printf調(diào)用的是標(biāo)準(zhǔn)庫提供的“格式化輸出”接口。這個(gè)接口內(nèi)部大致分三層第一層是格式解析層負(fù)責(zé)把 %d、%s、%f 這些占位符替換成實(shí)際字符串這一層在庫里已經(jīng)實(shí)現(xiàn)好了用戶碰不到。第二層是字符/流輸出層對(duì)應(yīng) fputc、fputs、fwrite 這類函數(shù)它們管理緩沖、維護(hù) FILE 結(jié)構(gòu)體的狀態(tài)。第三層是系統(tǒng)調(diào)用抽象層對(duì)應(yīng) read、write、open 這類 POSIX 風(fēng)格函數(shù)標(biāo)準(zhǔn)庫不實(shí)現(xiàn)它們的實(shí)際功能而是留給你或者運(yùn)行環(huán)境去實(shí)現(xiàn)。在桌面 Linux 上第三層最終由內(nèi)核實(shí)現(xiàn)write 就是真的寫文件、寫終端。在嵌入式裸機(jī)環(huán)境里沒有內(nèi)核write 就需要你手動(dòng)“對(duì)接”硬件。所以嵌入式里的重定向本質(zhì)上就是補(bǔ)齊第三層缺失的那部分系統(tǒng)調(diào)用。理解了這層關(guān)系就不難明白fputc 只是第二層的接口_write 才是第三層的地基。printf 的實(shí)現(xiàn)者可以選擇只依賴第三層也可以選擇結(jié)合第二層不同庫選擇不同表現(xiàn)自然不同。2.2 ARM GCC 生態(tài)里 printf 的調(diào)用鏈細(xì)節(jié)具體到 CLion 常用的 ARM GCC 工具鏈它默認(rèn)攜帶的 C 庫是 newlib 或者體積更小的 newlib-nano。這兩個(gè)庫里printf 的實(shí)現(xiàn)最終指向 _write 這個(gè)底層函數(shù)。也就是說不管你是不是只輸出一個(gè)字符在最終落地的路徑上printf 都會(huì)把數(shù)據(jù)組織成緩沖區(qū)然后交給 _write 統(tǒng)一發(fā)送。那 fputc 去哪了在某些配置下fputc 也會(huì)被鏈接進(jìn)去但它的角色變成了類似“中間代理”標(biāo)準(zhǔn)庫內(nèi)部會(huì)默認(rèn)提供一個(gè) fputc 實(shí)現(xiàn)它調(diào)用 _write 來真正的輸出。如果你重寫了 fputc但沒有重寫 _write那 printf 走 _write 這條路時(shí)用的還是庫自帶的 _write它要么是空實(shí)現(xiàn)要么是半主機(jī)模式反正是不會(huì)把數(shù)據(jù)送到你的串口里。這里還有個(gè)編譯選項(xiàng)可以佐證。newlib-nano 在編譯時(shí)有個(gè)配置叫--specsnano.specs它主要影響的是 printf/scanf 的功能裁剪對(duì)底層 _write 的調(diào)用關(guān)系影響不大。真正決定走 _write 而不是 fputc 的是庫對(duì) stdio 整個(gè)管線的設(shè)計(jì)而不是某一個(gè)裁剪選項(xiàng)。所以哪怕你開著 nano.specs也沒法靠重寫 fputc 繞過這個(gè)調(diào)用鏈。2.3 為什么很多老教程都是重寫 fputc它錯(cuò)了嗎老教程寫 fputc不能簡(jiǎn)單說錯(cuò)只能說它們描述的是另一種環(huán)境下的行為。比如老的 Keil MDK 自帶的 ARM C 庫對(duì) printf 的實(shí)現(xiàn)就更貼近“逐字符輸出”的模式fputc 正是出口。IAR 的庫也有類似設(shè)計(jì)所以用戶把 fputc 一重寫printf 就跟著走了。這也是很多人在不同工具鏈間遷移時(shí)機(jī)翻車的原因教程本身沒變變的是庫的實(shí)現(xiàn)策略。你把 Keil 里的經(jīng)驗(yàn)原封不動(dòng)搬到 CLion等于拿著前任公司的門禁卡去刷現(xiàn)任公司的門刷卡姿勢(shì)再標(biāo)準(zhǔn)也進(jìn)不去。還有一點(diǎn)要提醒即便在同一個(gè)工具鏈里換了一個(gè)庫版本調(diào)用鏈也可能變化。所以最穩(wěn)妥的做法不是“背一個(gè)可以重寫的函數(shù)名”而是學(xué)會(huì)自己查工具鏈的文檔和反匯編確認(rèn)。我后來習(xí)慣性地在 switch 到新工具鏈時(shí)先看一眼庫里 printf 的實(shí)現(xiàn)這比在網(wǎng)上試各種舊模板高效得多。實(shí)際做項(xiàng)目時(shí)尤其是團(tuán)隊(duì)協(xié)作統(tǒng)一工具鏈版本非常重要有一個(gè)成員用了不同版本的新庫重定向代碼的表現(xiàn)就可能不一致。提示在 Clion 里做 printf 重定向前先確認(rèn)兩件事工具鏈用的哪個(gè) C 庫默認(rèn)多為 newlib-nanoprintf 對(duì)應(yīng)的是哪個(gè)底層 write 接口。這兩點(diǎn)確定了寫出來的重定向代碼才具備可移植性。3. 實(shí)操方案在 CLion 里正確重定向 printf 串口輸出3.1 推薦做法重寫 _write 的標(biāo)準(zhǔn)模板既然調(diào)用鏈已經(jīng)清楚直接看標(biāo)準(zhǔn)做法。以 STM32 HAL 庫為例在 C 文件里加上這一段就能把 printf 的輸出送到 USART1#include stdio.h #include stdarg.h #include main.h extern UART_HandleTypeDef huart1; int _write(int file, char *ptr, int len) { HAL_UART_Transmit(huart1, (uint8_t *)ptr, len, HAL_MAX_DELAY); return len; }這段代碼的核心就三件事聲明好串口句柄、把 ptr 指向的緩沖區(qū)原樣發(fā)出去、返回實(shí)際發(fā)送長度。需要注意返回 len 不能隨便寫 0 或者省略返回值printf 內(nèi)部會(huì)通過返回值判斷是否發(fā)送成功返回值和傳入長度不一致可能導(dǎo)致 printf 認(rèn)為發(fā)送失敗做重試或丟棄處理。對(duì)于字符輸出也就是原來想用 fputc 的場(chǎng)景可以額外加一個(gè)小函數(shù)讓字符最終也走 _write既不破壞原有語義也不影響鏈路int fputc(int ch, FILE *f) { return _write(0, (char *)ch, 1) 1 ? ch : EOF; }這樣寫的好處是假如你項(xiàng)目里加了某些日志庫它內(nèi)部調(diào)用了 fputc也能正確輸出到串口。兩個(gè)口子都堵上了后面不會(huì)再出現(xiàn)“為什么 printf 正常但 putchar 沒反應(yīng)”這種問題。3.2 關(guān)于 fputc 的補(bǔ)充處理之前提到過有些庫里 fputc 默認(rèn)會(huì)作為 _write 的“上層”被調(diào)用但有些庫不一定。我自己習(xí)慣是 _write 和 fputc 都寫上原因很簡(jiǎn)單在混合使用標(biāo)準(zhǔn)庫和第三方庫的時(shí)候不能保證每個(gè)庫都走同一條輸出鏈路。比如某個(gè)日志組件把數(shù)據(jù)通過 fwrite 寫到一個(gè)文件流而文件流底層又依賴 fputc如果我只重寫 _write日志組件的數(shù)據(jù)還是會(huì)丟。反過來如果只重寫 fputcprintf 鏈路又?jǐn)嗔恕蓚€(gè)都寫覆蓋的場(chǎng)景更全。不過雙寫也有個(gè)隱患如果庫的內(nèi)部實(shí)現(xiàn)里 fputc 調(diào)用了 _write而我又在 _write 里什么事都沒做那么 fputc 發(fā)送的數(shù)據(jù)會(huì)在 _write 層被截獲并處理沒問題。但如果你在 fputc 和 _write 里都做了 HAL_UART_Transmit 調(diào)用又恰好庫內(nèi)部把同一個(gè)數(shù)據(jù)傳了兩遍就可能出現(xiàn)一個(gè)字符發(fā)兩次的現(xiàn)象。所以雙寫時(shí)一定要確認(rèn)庫的實(shí)現(xiàn)關(guān)系不要盲目疊加。3.3 參數(shù)計(jì)算與配置配合 CubeMX 串口初始化寫好重定向函數(shù)還得保證串口本身沒問題。很多人只盯著 _write 的寫法忘了檢查 CubeMX 生成的串口初始化。最典型的問題有三個(gè)。第一個(gè)是波特率對(duì)不上。比如 GPIO 初始化時(shí)把串口設(shè)為 115200但終端或串口助手卻開的是 9600輸出必定是亂碼。這種問題排查很快看 CubeMX 的 USART 配置頁把波特率記下來再去串口助手里選同一檔基本就對(duì)了。第二個(gè)是時(shí)鐘樹導(dǎo)致的波特率誤差。CubeMX 有時(shí)候根據(jù)用戶在 Clock Configuration 里的輸入自動(dòng)計(jì)算分頻系數(shù)填的值不同實(shí)際波特率會(huì)有偏差。偏差超過百分之二長一點(diǎn)的日志就會(huì)出現(xiàn)零星亂碼。檢查方法很簡(jiǎn)單把波特率調(diào)成整數(shù)對(duì)應(yīng)的分頻值讓 USARTDIV 算出來不含小數(shù)或者開啟 oversampling by 8容錯(cuò)更高實(shí)測(cè)下來穩(wěn)定性會(huì)明顯提升。第三個(gè)是 DMA 和中斷配置。HAL_UART_Transmit 是阻塞式發(fā)送在簡(jiǎn)單的日志場(chǎng)景下沒什么問題。但如果你開了中斷或者 DMA又同時(shí)調(diào)用了同一個(gè)串口可能發(fā)生發(fā)送沖突。穩(wěn)妥的做法是給 _write 里的發(fā)送加一點(diǎn)簡(jiǎn)單的狀態(tài)判斷比如用__HAL_UART_GET_FLAG(huart1, UART_FLAG_TXE)確保上一次發(fā)送完成再繼續(xù)否則可能出現(xiàn)第一個(gè)字節(jié)被覆蓋這種詭異現(xiàn)象。我遇到過一次特別難查的問題就是在 _write 里調(diào)用 HAL_UART_Transmit但串口助手收到的前兩個(gè)字節(jié)老是丟。排查很久發(fā)現(xiàn)是主循環(huán)里一個(gè)高頻中斷也在用同一個(gè)串口發(fā)送調(diào)試信息兩者沒有互斥導(dǎo)致緩沖區(qū)被覆蓋。后來我在 _write 里加了一個(gè)簡(jiǎn)單的信號(hào)量保護(hù)問題立刻消失。這種細(xì)節(jié)不踩坑真的想不到。4. 常見問題與排查技巧實(shí)錄4.1 典型問題與解決方案速查表我整理了在 CLion 社區(qū)和實(shí)際項(xiàng)目中遇到頻率最高的幾個(gè)問題按現(xiàn)象、原因、解決思路列個(gè)表方便快速對(duì)照。現(xiàn)象可能原因解決思路printf 無輸出程序正常運(yùn)行printf 走了半主機(jī)模式或底層 write 沒重寫重寫 _write并關(guān)閉 semihosting輸出亂碼波特率不匹配或時(shí)鐘分頻誤差大核對(duì) CubeMX 和終端波特率調(diào)整時(shí)鐘樹輸出丟失前幾個(gè)字符發(fā)送未等待上一位完成被下一位覆蓋在 _write 里加發(fā)送完成判斷或互斥程序進(jìn)入 HardFaultprintf 內(nèi)部使用堆堆?？臻g不足增大 Heap Size檢查啟動(dòng)文件輸出重復(fù)一次或回顯異常fputc 和 _write 同時(shí)被調(diào)用只保留 _write確認(rèn)庫內(nèi)部調(diào)用關(guān)系中文輸出亂碼英文正常源文件編碼非 UTF-8終端不支持對(duì)應(yīng)編碼源文件轉(zhuǎn) UTF-8串口助手選 UTF-8write to location 0x20 caused an access violation重定向函數(shù)操作了非法地址檢查指針是否為 NULL確認(rèn)串口句柄正確初始化表格里這幾個(gè)問題基本覆蓋了我在 CLion 開發(fā)過程中遇到的大部分坑。剩下幾個(gè)需要展開說因?yàn)樗鼈儽澈蟮脑聿皇且痪鋬删湓捘苤v透的。4.2 亂碼問題不只是波特率的鍋很多人一看到串口輸出亂碼習(xí)慣性懷疑波特率。實(shí)際上一旦波特率差了通常整段輸出都會(huì)亂而不是只亂一部分。如果你看到的是一半正常一半亂碼大概率是時(shí)鐘樹配置帶來的分頻誤差。STM32 的 USART 波特率寄存器是 16 位整數(shù)加 4 位小數(shù)不同主頻下某些波特率不能精確分頻誤差積累以后長字符串末尾就容易亂。另一個(gè)不太容易想到的原因是源碼編碼。CLion 默認(rèn)使用 UTF-8而很多老工程是 GBK 編碼。編譯器把源碼里的中文字符串按 GBK 解釋printf 把它原樣發(fā)給串口助手串口助手又按 UTF-8 解碼兩邊不對(duì)齊中文就成亂碼了。英文不受影響因?yàn)?ASCII 在兩個(gè)編碼里是一致的。排查方法最簡(jiǎn)單用十六進(jìn)制顯示串口數(shù)據(jù)如果看到的字節(jié)序列是 GBK 編碼的漢字字節(jié)基本就是編碼問題。解決辦法是統(tǒng)一成 UTF-8并在串口助手里也選 UTF-8雙端對(duì)齊亂碼自然消失。4.3 重寫 _write 之后程序崩了怎么定位崩的問題比亂碼嚴(yán)重。我見過比較多的場(chǎng)景是printf 放在一個(gè)很深的函數(shù)嵌套里局部變量特別多庫內(nèi)部實(shí)現(xiàn) printf 時(shí)需要一定?？臻g而嵌入式工程默認(rèn)的棧很小只有 1KB 左右疊加上重定向函數(shù)的調(diào)用直接越界進(jìn)入 HardFault。定位方式很簡(jiǎn)單在調(diào)試器里打開 Fault Analyzer 或者查看棧回溯看程序最后停在哪一行。如果停在 printf 或 _write 附近基本可以斷定是棧空間不足。解決方式是在鏈接腳本里把 Stack Size 調(diào)大比如從 0x400 改到 0x1000。有的項(xiàng)目還開了 FreeRTOS每個(gè)任務(wù)單獨(dú)分配棧printf 任務(wù)的棧要額外留足因?yàn)?printf 是出了名的“棧吃掉大戶”格式化浮點(diǎn)數(shù)時(shí)尤其明顯。另外如果你重寫 _write 后程序一開始運(yùn)行就報(bào)write to location 0000000000000020 caused an access violation這類錯(cuò)誤十有八九是 HAL_UART_Transmit 的參數(shù)有問題。比如指針用錯(cuò)了、句柄是 NULL或者是芯片上電后時(shí)鐘沒穩(wěn)定就調(diào)用了 printf。我建議在 main 函數(shù)最開始加個(gè)簡(jiǎn)單的延時(shí)或者確保 SystemClock_Config 先于第一個(gè) printf 執(zhí)行很多初始化順序?qū)е碌囊呻y雜癥都能避免。注意重寫 _write 時(shí)不要順手把返回值改成 len 以外的值。我見過有人圖省事直接return 0結(jié)果 printf 的緩沖區(qū)永遠(yuǎn)認(rèn)為寫入失敗頻繁重試程序速度被拖慢好幾倍。返回 len 是最符合語義的做法既高效又不容易出錯(cuò)。4.4 多 main 文件場(chǎng)景下的輸出管理CLion 有個(gè)特點(diǎn)它不像一些 IDE 那樣靠文件后綴或者文件名識(shí)別入口而是通過 CMake 的 add_executable 來管理源文件。如果你在同一個(gè)工程里放了多個(gè)帶 main 函數(shù)的文件鏈接時(shí)會(huì)報(bào)重復(fù)定義。這個(gè)和 printf 重定向本身沒直接關(guān)系但很多人搜到《CLion 寫多個(gè) main》時(shí)其實(shí)是因?yàn)橄敫阋粋€(gè)測(cè)試代碼集合里面既有 printf又有串口輸出。我的經(jīng)驗(yàn)是不要硬搞多 mainCLion 的多配置方案很成熟。用 CMake 的 option 控制編譯哪套代碼或者直接用 C 的 namespace 隔開邏輯比復(fù)制粘貼多個(gè) main 文件優(yōu)雅得多。如果你只是想在多個(gè) demo 之間切換最省事的辦法是給每個(gè) demo 建一個(gè)可執(zhí)行目標(biāo)再讓 IDE 只構(gòu)建當(dāng)前選中的 target。這個(gè)操作在 CMakeLists 里就是加一行 add_executable然后在 CLion 的 Target 選擇器里切換比注釋掉整個(gè) main 函數(shù)干凈多了。還有一種情況是你在做 JNI 或者 Android NDK 開發(fā)CLion 會(huì)生成一個(gè) externalNativeBuild 的 target這種情況下 main 函數(shù)屬于 Java 層C 代碼里只有 JNIEXPORT 函數(shù)。此時(shí)你想加一個(gè)自動(dòng)測(cè)試入口通常會(huì)用#ifdef包一個(gè)臨時(shí)的 main只在 debug 構(gòu)建里啟用。這個(gè)思路可以但要注意別讓臨時(shí) main 里的 printf 和 JNI 側(cè)的 HAL 串口初始化沖突否則排查起來比較鬧心。我的建議是讓臨時(shí) main 直接復(fù)用 JNI 代碼的初始化函數(shù)保證兩邊跑的是同一套硬件配置。4.5 一個(gè)容易忽略的“緩沖”陷阱以前在桌面環(huán)境寫 C大家習(xí)慣讓標(biāo)準(zhǔn)庫自動(dòng)緩沖 stdout。在嵌入式里這會(huì)是個(gè)大坑。如果你在 printf 后沒有及時(shí)刷新緩沖區(qū)它可能不會(huì)立刻通過 _write 發(fā)出去。CLion 的嵌入式開發(fā)里有時(shí)調(diào)試時(shí)打印的信息滯后或者在程序跑飛前最后幾條日志消失就是這個(gè)原因。我一般會(huì)在重定向代碼里同時(shí)關(guān)閉標(biāo)準(zhǔn)庫的緩沖區(qū)方法有兩種。一種是在 main 開頭調(diào)用setvbuf(stdout, NULL, _IONBF, 0)關(guān)掉緩沖讓每個(gè) printf 立即觸發(fā) _write另一種是啟動(dòng)文件里已經(jīng)配置了 newlib-nano 的無緩沖模式那基本不用管。實(shí)測(cè)下來setvbuf 的方式最直接也最容易理解。不過 setvbuf 在某些精簡(jiǎn)庫版本里實(shí)現(xiàn)得不完整調(diào)用后沒效果。這時(shí)候退而求其次在關(guān)鍵的調(diào)試節(jié)點(diǎn)手動(dòng)加一個(gè)fflush(stdout)也能保證數(shù)據(jù)及時(shí)發(fā)出。這個(gè)思路對(duì)于產(chǎn)品代碼里的日志系統(tǒng)一樣適用把 fflush 和 _write 的互斥鎖配合好即使后面跑 RTOS 也不會(huì)煩你。4.6 解決“const memory write”類警告的細(xì)節(jié)還有個(gè)小眾但惡心的警告write access to const memory has been detected, the output may be wrong!。這個(gè)警告一般出現(xiàn)在你用一個(gè) const 指針或者字符串字面量作為 _write 的入?yún)r(shí)。編譯器認(rèn)為你傳給 _write 的緩沖區(qū)可能是只讀的而 _write 內(nèi)部如果做寫操作就會(huì)越權(quán)。底層的根源是 printf 內(nèi)部某些格式化實(shí)現(xiàn)里會(huì)嘗試把臨時(shí)結(jié)果寫入一個(gè)內(nèi)部緩沖區(qū)這個(gè)緩沖區(qū)的類型和你傳入的字符串類型不匹配。處理方式不復(fù)雜_write 的函數(shù)簽名保持原樣不要自己額外加 const 限定調(diào)用時(shí)用一個(gè)可修改的 char 數(shù)組去接收而不是直接傳字符串字面量。如果你在 HAL_UART_Transmit 的第二個(gè)參數(shù)看到了 const uint8_t *而你的 _write 是 int _write(int file, char *ptr, int len)那就在 _write 內(nèi)部做一次顯式轉(zhuǎn)換。這樣既消除了警告也避免了在運(yùn)行時(shí)訪問非法地址的風(fēng)險(xiǎn)。5. 后續(xù)擴(kuò)展從串口重定向到更完整的調(diào)試體系5.1 用 CLion 的 Debug 模式配合串口日志把 printf 重定向搞定之后開發(fā)體驗(yàn)會(huì)提升一大截但別停在這里。CLion 的調(diào)試器可視化、內(nèi)存查看等功能和串口日志配合在一起才是完整的嵌入式調(diào)試體系。我通常的做法是代碼里保留面向業(yè)務(wù)功能的調(diào)試日志通過 _write 輸出到串口同時(shí)利用 CLion 的斷點(diǎn)和變量窗口跟蹤運(yùn)行時(shí)數(shù)據(jù)。兩者互補(bǔ)串口日志回答“程序走到哪了”“數(shù)據(jù)大概是什么”斷點(diǎn)回答“當(dāng)前狀態(tài)的精確細(xì)節(jié)”。這種組合在三方庫封裝很深、調(diào)用棧很長的時(shí)候特別有用。你要是只靠串口打日志一個(gè)問題可能要加十幾條打印才能定位配合斷點(diǎn)通常兩步就找到了。5.2 從單串口輸出升級(jí)到多通道日志工程復(fù)雜度上來以后一個(gè)串口往往不夠用。比如主邏輯日志和底層驅(qū)動(dòng)日志要分開看或者串口被別的外設(shè)占用了。我后來把重定向函數(shù)改成了可以通過宏或者全局變量切換目標(biāo)通道的形式底層調(diào)用 HAL_UART_Transmit 時(shí)選擇不同句柄。這樣同一個(gè) printf 的輸出可以被輕松導(dǎo)向不同串口、不同調(diào)試終端。如果你用的是 FreeRTOS還可以把 _write 里的發(fā)送放到一個(gè)專門的中斷優(yōu)先級(jí)的隊(duì)列里讓調(diào)試日志不阻塞主任務(wù)。但這里有個(gè)度的問題調(diào)試代碼太復(fù)雜反而會(huì)破壞時(shí)序引入了新的 bug。我的取舍原則是正式版本把重定向函數(shù)替換成空實(shí)現(xiàn)或者關(guān)掉調(diào)試日志開關(guān)只在 debug 構(gòu)建里保留完整輸出。量產(chǎn)的板子跑起來以后你絕不會(huì)希望 printf 在那邊影響實(shí)時(shí)性。5.3 把重定向代碼做成模板資產(chǎn)踩過這次坑之后我把這套重定向代碼整理成了一個(gè)模板文件包含 _write、fputc、setvbuf 以及一個(gè)簡(jiǎn)易的日志宏后續(xù)開新工程直接復(fù)制。模板里還寫了注釋標(biāo)注哪些地方需要根據(jù)芯片型號(hào)和串口句柄調(diào)整。這樣團(tuán)隊(duì)里其他人用 CLion 開發(fā)時(shí)也不會(huì)再遇到同樣的“為什么沒輸出”問題。做模板的時(shí)候有一點(diǎn)要記住不同芯片的 HAL 庫發(fā)送函數(shù)不完全一樣。STM32 是 HAL_UART_Transmit某些國產(chǎn)芯片或者舊版標(biāo)準(zhǔn)外設(shè)庫可能是 USART_SendData。所以模板里最好把發(fā)送函數(shù)單獨(dú)包裝一層比如static void uart_send_byte(uint8_t ch)以后換平臺(tái)只需要改這一個(gè)函數(shù)。這個(gè)封裝一開始不顯眼項(xiàng)目多了以后你就知道有多香了。提示模板里建議順手加一個(gè)掉線保護(hù)比如發(fā)送返回值檢測(cè)失敗時(shí)連續(xù) N 次失敗就停止輸出避免卡死主循環(huán)。這個(gè)在長時(shí)間無人值守的設(shè)備上特別重要否則一次串口異常就能把整個(gè)系統(tǒng)拖住。6. 寫到最后的一點(diǎn)經(jīng)驗(yàn)文章寫到這里該講的原理和操作都講完了。我從個(gè)人體會(huì)的角度再說幾句?？酥频恼{(diào)試輸出對(duì)嵌入式開發(fā)非常重要打印不是越多越好。重定向做對(duì)了只是萬里長征第一步真正決定開發(fā)效率的是你拿這些日志能快速定位問題還是被日志淹沒。串口重定向遇到問題時(shí)優(yōu)先確認(rèn)調(diào)用鏈再動(dòng)手改代碼。與其在 fputc 上反復(fù)嘗試不如花幾分鐘查一下工具鏈用的 C 庫和 printf 的實(shí)現(xiàn)方式。這個(gè)檢查習(xí)慣養(yǎng)成以后你在任何 IDE、任何工具鏈里做重定向都不會(huì)慌。CLion 只是其中一個(gè)環(huán)境它的漂亮界面和調(diào)試體驗(yàn)解決的是操作層問題底層的庫原理才是所有環(huán)境通用的硬核知識(shí)。