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