1. 為什么這個問題的答案藏在標準庫的分層結(jié)構(gòu)里先說結(jié)論在 CLion 嵌入式開發(fā)環(huán)境下重寫_write而不是fputc是因為printf最終調(diào)用的底層字節(jié)輸出函數(shù)是_writefputc只是 C 標準庫提供給應用層的“流式單字符接口”兩者根本不在同一個層級。你需要重定向的是最底下那一層而不是上面那一層。這個問題的典型場景是這樣的你用 CLion ARM GCC 工具鏈做 STM32 或其它單片機的裸機開發(fā)想在調(diào)試時用printf把數(shù)據(jù)打到 CLion 的調(diào)試終端里看。問題來了——默認情況下printf輸出的內(nèi)容到底是什么如果你在桌面 Linux 上寫程序printf輸出到 stdout操作系統(tǒng)接管一切但在單片機上沒有操作系統(tǒng)C 庫做不了這件事于是所有輸出最終都會落到一個叫做“底層寫函數(shù)”的接口上。ARM GCC 使用的 newlib 庫中這個接口就是_write。很多人上來就在fputc里面加重定向代碼然后在 CLion 里跑發(fā)現(xiàn)有些情況下能工作換了調(diào)試器或者換了輸出方式又不行了一頭霧水。原因很簡單fputc是 ANSI C 標準庫里 FILE 流機制的一部分它管理的對象是FILE *stdout這樣一個不帶緩沖的流對象。在桌面系統(tǒng)的 glibc 里fputc最終通過系統(tǒng)調(diào)用write(2)進入內(nèi)核在 newlib 里fputc最終調(diào)用的則是內(nèi)部函數(shù)_write。但如果你繞過文件流機制直接調(diào)用write(1, buf, len)或者使用某些庫的內(nèi)部路徑fputc那層代碼根本不會被觸發(fā)而_write卻一定會被觸發(fā)。所以在 CLion 里做嵌入式項目的printf重定向標準答案只有一個重寫_write。這篇文章我就把這件事從原理到實操完整拆一遍看完你不僅知道怎么寫還知道為什么必須這么寫。2. 重新認識printf一條從格式化到字節(jié)落地的完整鏈路2.1 格式化輸出只是前半段為了搞清楚_write的地位得先把printf的完整調(diào)用鏈在腦子里過一遍。printf是格式化函數(shù)它負責的是“把變量按照格式串轉(zhuǎn)換成字符流”。比如你寫下printf(temp%d\n, temp)它內(nèi)部會把temp的值轉(zhuǎn)成 ASCII 字符序列然后把這個序列交給它下面的一個函數(shù)去輸出。這個“下面的函數(shù)”在不同平臺上不一樣但結(jié)構(gòu)大致是這樣的printf - vfprintf做格式化結(jié)果放進一個內(nèi)部緩沖 - fputc / fwrite把緩沖中的字符寫入 FILE 流 - _write真正把字節(jié)交給硬件/調(diào)試器/串口表格化一下各層的職責層級 職責 你需要改嗎 printf 格式化參數(shù) 不需要 vfprintf 真正的格式化引擎 不需要 fputc/fwrite 逐字符/逐塊寫入文件流對象 視情況 _write 底層字節(jié)輸出 需要重寫注意最后一列裸機開發(fā)中真正決定“字節(jié)去哪”的是_write。fputc做的事情只是把單個字符搬運到fputc內(nèi)部的那個FILE結(jié)構(gòu)體里它本身并不知道這個字符最終該去串口還是調(diào)試器。這個搬運動作在多數(shù)實現(xiàn)中直接調(diào)用_write來完成。2.2 為什么重寫 fputc 是“打錯了靶子”在 Keil MDK 的早期例程里最常見的是重寫fputc代碼如下int fputc(int ch, FILE *f) { /* 等待發(fā)送完成然后往串口數(shù)據(jù)寄存器寫一個字節(jié) */ while ((USART1-SR USART_SR_TXE) 0); USART1-DR (ch 0xFF); return ch; }這套代碼為什么在 Keil 里能跑起來因為 Keil 的 ARM Compiler 使用 microlib或使用設置了--specsrdimon.specs之類的啟動文件它的printf到fputc之間是直連的。也就是說在你使用的那個特定庫實現(xiàn)里fputc恰好扮演了“底層輸出函數(shù)”的角色。但你把這個代碼原樣搬到 CLion arm-none-eabi-gcc newlib 環(huán)境下可能就失效了。因為 newlib 的printf路徑并不一定會經(jīng)過你定義的fputc或者說fputc只會在某些流操作路徑下被調(diào)用而更底層的_write才是 newlib 面向硬件層的唯一約定。所以問題的本質(zhì)是重定向的目標應該是“當前 C 庫實現(xiàn)中所有輸出路徑最終匯聚的那個函數(shù)”而不是“我手頭例程里正好寫了那個函數(shù)”。在 CLion 標配的 ARM GCC newlib 環(huán)境下這個匯聚點就是_write。2.3 CLion 環(huán)境的特殊性你選的工具鏈已經(jīng)決定了一切CLion 本身并不編譯代碼它只是調(diào)用你配置好的工具鏈。做嵌入式開發(fā)時最常見的組合是工具鏈arm-none-eabi-gccGNU Arm Embedded ToolchainC 庫newlib 或 newlib-nano調(diào)試器后端OpenOCD 或 ST-Link GDB Server構(gòu)建系統(tǒng)CMake這三者疊加起來_write重定向就變成了唯一合理的方案。因為 GCC 的 newlib 在設計上把“字節(jié)輸出到哪里”這件事完全丟給了_write你如果不實現(xiàn)_write鏈接時通常不會報錯因為 newlib 提供了一個默認的弱符號版本——但那個默認版本是什么都不干的。你調(diào)用printf(hello)格式化完成了_write被調(diào)用了然后它什么都不做直接返回。這就是為什么很多人初次在 CLion 里跑printf發(fā)現(xiàn)終端一片空白。3. newlib 的_write到底長什么樣實現(xiàn)細節(jié)與參數(shù)含義3.1 標準簽名和默認行為在 newlib 中_write的聲明是int _write(int file, char *ptr, int len);三個參數(shù)的含義file文件描述符。對于標準輸出是 1標準錯誤是 2標準輸入是 0。打印到調(diào)試終端時你通常只需要關(guān)心 1 和 2。ptr指向要輸出的字節(jié)緩沖區(qū)的指針注意不是單個字符而是一段連續(xù)內(nèi)存。len期望輸出的字節(jié)數(shù)。返回值的約定是返回實際寫出的字節(jié)數(shù)。如果輸出成功應當返回len如果發(fā)生錯誤可以返回 -1 并設置errno不過在裸機調(diào)試場景下基本不需要考慮 errno 的完整語義能返回len就夠了。默認情況下newlib 里有一個_write的弱實現(xiàn)weak symbol它位于庫內(nèi)部未鏈接到你程序時直接返回len假裝“寫入成功”。這正是許多人第一輪調(diào)試時最大的迷惑點printf不報錯程序也不崩潰就是沒有輸出。因為默認_write吞掉了所有數(shù)據(jù)。3.2 一個適用于 CLion 嵌入式調(diào)試的完整實現(xiàn)直接在 CLion 里配合 OpenOCD 的半主機semihosting模式可以這樣實現(xiàn)#include errno.h #include sys/stat.h #include sys/unistd.h int _write(int file, char *ptr, int len) { if (file STDOUT_FILENO || file STDERR_FILENO) { /* 將緩沖區(qū)的字節(jié)逐個發(fā)送到調(diào)試器的半主機通道 */ for (int i 0; i len; i) { ITM_SendChar(ptr[i]); // 或者調(diào)用你調(diào)試器對應的輸出函數(shù) } return len; } errno EBADF; return -1; }注意這里的STDOUT_FILENO來自sys/unistd.h實際上就是常量 1STDERR_FILENO是 2。如果你用的是 ITMInstrumentation Trace Macrocell通過 SWO 引腳輸出核心是ITM_SendChar這個函數(shù)。但在裸機工程里你要么自己實現(xiàn)它要么在調(diào)試器的固件庫里找到對應函數(shù)。常見的做法是直接用 CMSIS 提供的ITM_SendChar它被定義在 core_cm4.h 等文件里static __INLINE uint32_t ITM_SendChar(uint32_t ch) { if (((ITM-TCR ITM_TCR_ITMENA_Msk) ! 0UL) ((ITM-TER (1UL 0)) ! 0UL)) { while (ITM-PORT[0].u32 0UL) { __NOP(); } ITM-PORT[0].u8 (uint8_t)ch; } return (ch); }代碼的邏輯很直白先檢查 ITM 是否使能再檢查端口 0 的通道是否使能對應調(diào)試器端的 SWV 配置如果硬件準備好了就往 PORT 寄存器寫一個字節(jié)。如果你不走 ITM而是走串口那_write里寫的就是串口發(fā)送邏輯把len個字節(jié)挨個送進 UART 的發(fā)送數(shù)據(jù)寄存器注意等待發(fā)送完成。兩種方式的差異只在于_write內(nèi)部的字節(jié)搬運代碼函數(shù)簽名和重定向入口完全一致。3.3 重寫之后還需要做什么鏈接腳本與啟動文件在你的工程里把_write定義好之后還有一個步驟經(jīng)常被忽略確保鏈接時使用的是 newlib 的完整實現(xiàn)并且_write不是被某個啟動文件的匯編代碼繞過去。在 CLion 的 CMakeLists.txt 里I通常要顯式加上--specsnano.specs或者--specsrdimon.specs。區(qū)別在于nano.specs使用 newlib-nano體積小但一些功能被裁剪比如完整版的vfprintf浮點格式支持可能沒有。rdimon.specs使用 rdimon半主機監(jiān)控庫適合死磕調(diào)試器但會引入額外依賴。實測下來在 CLion OpenOCD ST-Link 的組合中我推薦先采用--specsnano.specs然后在鏈接器參數(shù)中排除半主機有關(guān)的功能自己實現(xiàn)_write來做輸出。這樣做的好處是體積可控且不依賴調(diào)試器端是否開啟了 semihosting 服務。你只需要把_write實現(xiàn)成通過串口或 ITM 輸出就能獨立工作。具體在 CMakeLists.txt 中常見配置長這樣set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} --specsnano.specs) set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} --specsnano.specs -u _printf_float)-u _printf_float是讓 newlib-nano 也支持printf打印浮點數(shù)。這個細節(jié)容易踩坑后面我會專門說。4. 為什么 CLion 恰恰是“最容易觸發(fā)這個問題的 IDE”4.1 CLion 的調(diào)試終端與 stdout 處理機制CLion 本身不是一個嵌入式專用 IDE它最初定位是 C/C 跨平臺開發(fā)后來通過插件和外部工具鏈支持了嵌入式。這導致一個非常有意思的局面CLion 的調(diào)試器視圖中沒有像 Keil 那樣內(nèi)置一個“UART 窗口”或“printf 重定向助手”它依賴 GDB 調(diào)試器后端的輸出通道來展示數(shù)據(jù)。當你用arm-none-eabi-gdb配合 OpenOCD 調(diào)試時CLion 會啟動一個 GDB 會話OpenOCD 作為 GDB server 與目標板通信。此時程序里的printf輸出到了哪里取決于_write的實現(xiàn)如果_write通過 ITM/SWO 輸出調(diào)試器端需要打開 SWVSerial Wire Viewer配置CLion 里對應的是 Debug 配置中的 “SWV” 標簽頁勾選 “Enable SWV” 并設置正確的時鐘頻率。如果_write通過半主機semihosting輸出OpenOCD 需要開啟 semihosting 支持在 OpenOCD 配置文件中加入arm semihosting enable。如果_write通過串口輸出CLion 里根本沒有串口終端你得額外裝一個串口監(jiān)視器比如 minicom、PuTTY 或者 CLion 的 “Serial Monitor” 插件。這三種方式中與 CLion 集成體驗最好的是 SWV。因為 SWV 的 ITM 通道 0 可以直接顯示在 Debug 工具的 “ITM/SWO console” 里不需要額外開串口工具。這也是為什么我在示例代碼中選擇了 ITM 輸出。4.2 重寫 fputc 在這些通道下為什么大概率失效現(xiàn)在可以回答標題里的問題了。假設你選擇重寫fputc來把字符輸出到 ITM大概率的實現(xiàn)是這樣int fputc(int ch, FILE *f) { ITM_SendChar(ch); return ch; }然后你調(diào)用printf(abc)期望它經(jīng)過fputc三次輸出三個字符。這在 Keil 的 microlib 里確實成立。但在 CLion 使用的 newlib 中printf-vfprintf-fwrite的路徑是這樣的vfprintf格式化完成后會把結(jié)果塊拷貝到一個內(nèi)部緩沖區(qū)然后調(diào)用fwrite寫入 stdout 文件流。fwrite在 newlib 內(nèi)部可能直接調(diào)用_write來處理整塊數(shù)據(jù)也可能通過fputc逐字符處理具體取決于緩沖區(qū)滿沒滿、是不是行緩沖等狀態(tài)。關(guān)鍵點在于newlib 中 stdout 默認是行緩沖還是全緩沖取決于實現(xiàn)。在裸機環(huán)境下很多移植把 stdout 設置成無緩沖此時fwrite往往繞過fputc直接調(diào)_write。你重寫fputc可能連觸發(fā)的機會都沒有。退一步說即使某些情況下fputc會被調(diào)用它也不是所有輸出路徑的唯一入口。比如你哪天直接調(diào)write(1, buf, len)或者使用fputs輸出路徑就不經(jīng)過fputc了。而所有路徑最終都會匯聚到_write。打個比方fputc是每個樓層走廊里的小信箱每個寫字的人都會把信投進自己樓層的小信箱但郵政系統(tǒng)真正收信的地方是整棟樓底層的收發(fā)室——_write。你只改造某一個樓層的小信箱信件能到的也只是個別樓層一旦有人直接去底層投遞你的小信箱就完全沒用了。與其猜測哪個樓層的人會走哪條路不如直接把底層收發(fā)室改造了一勞永逸。5. 實操演示在 CLion 里從零配置_write重定向ITM 路線5.1 環(huán)境準備和前提條件我用的環(huán)境如下供你參考CLion 2024.1 以上STM32CubeMX 生成的 CMake 工程MCUSTM32F407VET6也可以換成其他 Cortex-M3/M4/M7arm-none-eabi-gcc 版本 12.3 或更新OpenOCD 0.12 或更新ST-Link V2板子 SWD 接口連接 OK硬件上需要特別確認一點ITM 的 SWO 引腳是否連到了調(diào)試器。SWD 調(diào)試接口只需要 SWDIO 和 SWCLK 兩根線但 SWO 是第三根輸出線。如果板子沒有把 SWO 引出來或者調(diào)試器不支持 SWO比如某些免驅(qū) ST-Link V2 clone 可能對 SWO 支持有問題那 ITM 這條路就走不通。此時你只能用半主機或者串口。5.2 在 CMSIS 基礎上加入_write實現(xiàn)文件我在工程里新建了一個文件debug_io.c專門放重定向代碼。這樣做的目的是把硬件相關(guān)的 IO 邏輯集中起來后續(xù)換串口或者換調(diào)試器時只改這一個文件。// debug_io.c #include sys/unistd.h #include errno.h #include stm32f4xx.h int _write(int file, char *ptr, int len) { if (file STDOUT_FILENO || file STDERR_FILENO) { for (int i 0; i len; i) { ITM_SendChar((uint32_t)ptr[i]); } return len; } errno EBADF; return -1; }這里直接調(diào)用了 CMSIS 頭文件里的ITM_SendChar它是內(nèi)聯(lián)函數(shù)不需要額外添加庫。5.3 確保 CMake 鏈接參數(shù)包含正確的 specs在我的 CMakeLists.txt 中鏈接選項出現(xiàn)了多次折騰。第一次我把--specsnano.specs只加到了CMAKE_C_FLAGS結(jié)果編譯正常、鏈接報錯“undefined reference to _write”這其實是 newlib-nano 在沒有我們定義_write時否它是有默認弱實現(xiàn)的不會報未定義。真正的問題是我用了rdimon.specs那個庫里要求你必須實現(xiàn)額外的_sys_*系列函數(shù)。后來我統(tǒng)一換成nano.specs就清爽多了。推薦直接在 CMakeLists.txt 中這樣設置add_compile_options(--specsnano.specs) add_link_options(--specsnano.specs) # 如果需要 printf 支持浮點數(shù): add_link_options(-u _printf_float)注意add_link_options是 CMake 3.13 之后引入的而 CLion 自帶的 CMake 版本通常都滿足要求。如果你的 CMake 版本較老就改用在 target_link_options 里同樣寫法。5.4 CLion 的 Debug 配置與 SWV 界面設置點擊右上角的 Debug Configuration 下拉框編輯你的 Embedded GDB Server 配置找到 “SWV” 一欄做三件事勾選Enable SWV設置 CPU 頻率比如你的 STM32F407 工作在 168MHz就填 168000000設置 SWO 時鐘頻率通常是 2000000020MHz或者根據(jù)調(diào)試器的實際采樣率來填不對可能看不到輸出然后啟動調(diào)試程序會自動停在main入口。這時打開 View - Tool Windows - ITM/SWO Console面板上會顯示 “ITM/SWO console enabled” 之類的字樣。全速運行調(diào)用printf(hello from clion\r\n)你應該能在 ITM 面板看到輸出。如果看到亂碼或者沒輸出優(yōu)先檢查兩件事SWO 引腳是不是真連了SWV 配置里的核心頻率是不是填錯了。我在 STM32F103 的開發(fā)板上遇到過核心頻率填錯導致亂碼的情況改回 72MHz 后一切正常。5.5 另一種更穩(wěn)的輸出路線半主機如果你的調(diào)試器 SWO 支持不好CLion 還有一個很實用的后備方案OpenOCD 半主機。在 OpenOCD 配置文件中加入arm semihosting enable然后在_write中調(diào)用半主機輸出函數(shù)。newlib 其實自帶 semihosting 的_write實現(xiàn)鏈接時加上--specsrdimon.specs就行不需要手動寫。但 rdimon 的引入會連帶要求實現(xiàn)一些系統(tǒng)調(diào)用例如_sbrk、_gettimeofday等如果你的啟動文件沒有提供足夠的堆棧設置可能會踩坑。我的建議是新手優(yōu)先走 ITM 路線邏輯直觀不依賴額外的中間層如果芯片比較老比如 Cortex-M0 不支持 ITM再改串口方案也就是在_write里做 UART 發(fā)送循環(huán)。6. Java/JNI 場景的對照CLion 里配置 JNI 時_write為何同樣重要有一定經(jīng)驗的開發(fā)者可能會發(fā)現(xiàn)這個_write問題在 CLion 的另一個典型場景——JNI 開發(fā)——中也會冒出來。CLion 是 JetBrains 家族里少有的能同時寫 C/C 和調(diào)用 Java JNI 的 IDE很多人用它開發(fā)本地庫。此時如果 JNI 庫中調(diào)用了printf輸出不會自動出現(xiàn)在 IntelliJ IDEA 的終端或 CLion 的 Run 面板里。原因是 Java 進程接管了標準輸出JVM 的輸出重定向機制和 C 運行時庫的_write交互很微妙。解決方案仍然是重寫_write讓 C 庫的 stdout 走自定義通道。比如在 JNI 庫中把_write重定向為通過 Android Logcat 輸出或者通過 socket 發(fā)送回 Java 層。這屬于跨語言調(diào)試的“輸出橋接”問題和嵌入式場景本質(zhì)相同上層永遠不知道底層輸出去哪了只有_write知道。當然如果你在 JNI 庫中只是想打個日志看看最簡單的方法其實是不要用printf而是直接用一個宏把輸出替換成__android_log_print(ANDROID_LOG_DEBUG, your_tag, __VA_ARGS__)。但如果庫代碼已經(jīng)是第三方提供的、內(nèi)部寫死了 printf你就只能從_write入手了。這也是為什么我說_write這個重定向點是通用的不局限于嵌入式。7. 常見問題與排查技巧實錄從“沒輸出”到“亂碼”的完整解決路徑7.1 問題一printf 之后 CLion 終端什么都沒顯示排查步驟確認程序確實執(zhí)行到了 printf 那一行?？梢栽?printf 前后打斷點觀察程序是否卡死在某個 while 循環(huán)。確認_write是否被調(diào)用。在_write入口打斷點如果沒斷住說明你的 printf 路徑根本沒走到_write。這時檢查鏈接參數(shù)是不是用了 rdimon 或者發(fā)生符號沖突。確認_write里的硬件代碼沒有卡死。如果用了 ITM而調(diào)試器沒有開啟 SWVITM_SendChar里等待PORT[0].u32 0那行會一直卡住。這是最常見也最隱蔽的坑程序停在_write里不動表面看起來像沒輸出。確認 stdout 配置沒有被重定向到文件。有些鏈接腳本會把 stdout 關(guān)聯(lián)到一個串口文件描述符導致_write的file參數(shù)不是 1而是 3 或其它值。你可以在_write里把 file 打出來看看。7.2 問題二輸出亂碼亂碼集中在 ITM/SWO 路線上。原因基本是兩個核心頻率HCLK填寫錯誤。ST-Link 的 SWO 采樣率需要知道內(nèi)核運行頻率才能正確解碼。填錯解碼結(jié)果就是亂碼。SWO 頻率設置與調(diào)試器實際采樣頻率不一致。在 OpenOCD 中可能需要配置st-link的速度參數(shù)。解決方法是在 CLion 的 SWV 配置頁核對“Core Clock”和“SWO Clock”兩個值。如果板子上跑的是外部晶振倍頻后的主頻務必搞清楚倍頻系數(shù)不能只看芯片默認的 16MHz。7.3 問題三重寫 fputc 能工作有必要改寫成 _write 嗎如果當前代碼在 CLion 里重寫fputc后能正常輸出而且你只使用printf、putchar這些標準函數(shù)短期不改也能跑。但這不是一個健壯的方案。換一個編譯優(yōu)化級別、換一個芯片型號、換一個 C 庫版本輸出路徑就可能變化。我之前在一個工程里就是這么干的后來把printf改成snprintf又加了fputs輸出結(jié)果fputs沒有走fputc的路徑導致部分日志丟失。排查了半天才發(fā)現(xiàn)是重定向?qū)哟尾粚?。所以建議是就算fputc方案當前能用也最好一次性遷移到_write把根扎對。7.4 問題四鏈接時報 undefined reference to_write或_sbrk等出現(xiàn)這個錯誤通常是因為你用了--specsrdimon.specs而工程里沒有實現(xiàn) rdimon 所依賴的完整系統(tǒng)調(diào)用棧。用rdimon.specs是一種更省事的調(diào)試輸出方案但它要求實現(xiàn)_open、_close、_read、_write、_lseek、_fstat、_kill、_getpid、_sbrk等一整套函數(shù)你用不到也必須給出符號。我遇到這個報錯后直接退回--specsnano.specs然后只實現(xiàn)_write一個函數(shù)整個世界清凈了。如果你必須用 rdimon可以用 newlib 自帶的syscalls.c文件補齊全部函數(shù)GNU ARM 工具鏈的 examples 目錄里就有參考。7.5 問題五調(diào)試時 stdout 輸出會卡住全速運行正常這是典型的“輪詢等待發(fā)送完成”寫法在調(diào)試器單步執(zhí)行時暴露的問題。比如你的_write里是while ((USART1-SR USART_SR_TXE) 0);單步調(diào)試時如果串口發(fā)送保持寄存器是空的這個 while 循環(huán)可能瞬間通過但如果發(fā)送移位寄存器還沒空并且沒有數(shù)據(jù)時鐘推進它就卡在那里。建議改成帶超時機制的寫法for (volatile int i 0; i 0xFFFF; i) { if ((USART1-SR USART_SR_TXE)) break; }這雖然不優(yōu)雅但在調(diào)試場景中能有效避免因為調(diào)試器暫停時鐘導致的外設死鎖。7.6 問題六printf 浮點數(shù)打印不出小數(shù)部分在 newlib-nano 下默認不支持浮點格式化輸出會是空字符串或者“%f”原樣。需要兩個步驟鏈接參數(shù)加-u _printf_float確認你沒有用--specsnano.specs的浮點裁剪變體實測在 STM32F4 上加了-u _printf_float后printf(%.2f, 3.14)能正常顯示 3.14但生成的固件體積會增加大約 10~15KB。對大多數(shù)調(diào)試場景來說完全可接受。8. 一個容易忽略的細節(jié)fputc 也值得保留的原因雖然我一直在說“重寫_write而不是fputc”但嚴謹?shù)刂v這兩個并不互斥。你完全可以同時重寫_write和fputc讓fputc只是_write的一個便捷封裝int fputc(int ch, FILE *f) { int ret _write(STDOUT_FILENO, (char *)ch, 1); return (ret 1) ? ch : EOF; }這樣做的好處是即使某些第三方庫的代碼直接調(diào)用putchar或fputc而沒有走 printf 的格式化路徑也會最終落到你那套輸出硬件上形成“所有出口統(tǒng)一指向_write”的格局。不過要注意如果你的工程里鏈接了某個庫該庫內(nèi)部自帶了一個fputc的強符號實現(xiàn)你就不能重復定義了否則鏈接報 multiple definition。此時優(yōu)先保留_write的實現(xiàn)刪掉自己的fputc。9. 從_write延伸到更底層如何讓重定向適配多種輸出終端9.1 一個可插拔的_write設計思路既然_write是通用出口我建議你在工程里做一個輸出通道的抽象。比如定義一組回調(diào)函數(shù)指針運行時可以切換輸出目標typedef void (*output_func_t)(char c); static output_func_t s_output 0; int _write(int file, char *ptr, int len) { if (file ! STDOUT_FILENO file ! STDERR_FILENO) { errno EBADF; return -1; } if (s_output) { for (int i 0; i len; i) { s_output(ptr[i]); } } return len; } void debug_set_output(output_func_t fn) { s_output fn; }這樣一來在main.c里你可以根據(jù)運行模式?jīng)Q定輸出走 ITM 還是走串口int main(void) { debug_set_output(itm_put_char); // 或 uart_put_char printf(system boot\r\n); while (1); }這個做法的價值在于你的代碼邏輯和硬件輸出通道解耦。后來我從 STM32F4 遷移到 GD32 時只需要把itm_put_char和uart_put_char兩個函數(shù)按新平臺重寫一遍其余業(yè)務邏輯完全不動。9.2 處理 stdout 與 stderr 的差異化輸出_write可以通過file參數(shù)區(qū)分 stdout 和 stderr。調(diào)試時我通常把 stderr 標成紅色方便區(qū)分錯誤日志。如果你用的是 ITM可以把 stderr 發(fā)送到 ITM 的另一個端口比如端口 1然后在 CLion 的 ITM/SWO Console 里分別顯示為不同的流。當然這要求你的調(diào)試器配置里使能了對應的端口。在 CLion 里對應 SWV 配置的“ITM Stimulus Ports”設置項勾選 0 和 1。代碼類似這樣int _write(int file, char *ptr, int len) { if (file STDOUT_FILENO) { for (int i 0; i len; i) ITM_SendChar(ptr[i]); // 端口 0 return len; } else if (file STDERR_FILENO) { for (int i 0; i len; i) ITM_SendChar(ptr[i]); // 實際也發(fā)送到端口0或者改用端口1 return len; } errno EBADF; return -1; }如果你的調(diào)試器支持多端口輸出可以把 stderr 發(fā)到端口 1區(qū)分效果更明顯。不過多數(shù)情況下我圖省事二者都發(fā)到端口 0然后在日志文本中加[ERR]前綴。畢竟在嵌入式調(diào)試里功能正確優(yōu)先于日志美觀。10. 一些值得記錄的調(diào)試器端設置細節(jié)10.1 OpenOCD 配置中的 SWV 使能在 OpenOCD 0.12 中ITM 輸出通常不需要額外配置只要 GDB 連接后CLion 的 SWV 工具會自動向 OpenOCD 發(fā)送相關(guān)命令。但有的時候你會看到 CLion 提示 “SWV not available”這可能是因為 OpenOCD 的接口驅(qū)動不支持 SWO 采集。ST-Link 的 OpenOCD 驅(qū)動在 0.12 之后對 SWO 支持已經(jīng)比較完善如果是 CMSIS-DAP 調(diào)試器需要確認它的實現(xiàn)是否把 SWO 數(shù)據(jù)線上報給 OpenOCD。我在使用某款國產(chǎn) CMSIS-DAP 調(diào)試器時SWO 一直不可用后來換回 ST-Link V2 才順利輸出。如果你也遇到 SWV 面板一直空白可以先懷疑調(diào)試器硬件不必在軟件配置上死磕。10.2 半主機模式下的管道問題如果走半主機OpenOCD 的arm semihosting enable打開之后程序的printf輸出會被 OpenOCD 抓到然后轉(zhuǎn)發(fā)到 GDB 的控制臺。在 CLion 中你可以在 Debug 工具窗口的 “GDB” 標簽頁看到這些輸出。這種方式的好處是不依賴 SWO 引腳壞處是半主機調(diào)用會暫停 CPU 到服務態(tài)對實時性要求高的循環(huán)會產(chǎn)生明顯的影響。我曾經(jīng)在跑 PWM 控制時開了半主機結(jié)果輸出日志越多電機抖動越大。所以如果你做的是實時控制類項目建議輸出通道用 ITM 或者 DMA 串口避免半主機帶來的 CPU 阻塞。11. 從“ printf 重定向”到“嵌入式日志框架”的進階思路11.1 為什么只搞定 printf 還不夠當你的項目越來越大日志輸出不再只是printf幾句調(diào)試信息而需要分級輸出DEBUG/INFO/WARN/ERROR、需要加時間戳、需要按組件過濾時重定向_write只是第一步你還得考慮日志框架層的設計。但框架層無論如何都要依賴最底層的輸出通道這個通道就是_write。你可以在_write之上封裝一個帶鎖的日志輸出接口避免多線程/中斷環(huán)境下的交錯輸出。比如void log_print(const char *level, const char *func, int line, const char *fmt, ...) { char buf[128]; int len snprintf(buf, sizeof(buf), [%s] %s:%d , level, func, line); // 輸出 level 前綴到 _write _write(STDOUT_FILENO, buf, len); va_list args; va_start(args, fmt); len vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); _write(STDOUT_FILENO, buf, len); }這樣日志系統(tǒng)就建立在一個扎實的“字節(jié)輸出出口”之上而不是零散地在代碼各處直接操作寄存器。11.2 緩沖區(qū)與性能的取舍_write是同步輸出每一個字符都要等待硬件發(fā)送完成。在 ITM 輸出時如果 SWO 帶寬有限大量日志會拖慢程序執(zhí)行。此時可以考慮在_write內(nèi)部做一個緩沖區(qū)先填滿一個 64 字節(jié)的 buffer然后一次性通過 DMA 發(fā)送到串口或者批量寫入 ITM 端口。一個經(jīng)驗閾值是日志輸出頻率低于每秒幾百條時同步輸出完全夠用一旦進入高頻率日志比如控制環(huán)路每 100us 打一條必須上緩沖異步刷新。11.3 串口轉(zhuǎn) USB 的輸出與_write的關(guān)系如果你使用 ST-Link 板載的虛擬串口它的底層其實是板載 ST-Link 的 USART 轉(zhuǎn)發(fā)到 USB與芯片的 UART 外設無關(guān)。此時_write里操作的寄存器地址要根據(jù)板子的硬件原理圖來定而不是想當然地用USART2。很多板子的虛擬串口連接在USART2或LPUART1你要查原理圖確認。查錯了printf 靜默失敗因為_write往一個沒人接的串口寄存器里寫數(shù)據(jù)程序不報錯但數(shù)據(jù)在硬件層面就遺失了。這個坑我踩過一次當時在板子上怎么調(diào)都沒輸出最后拿邏輯分析儀去量 TX 引腳才發(fā)現(xiàn)波形根本不存在——因為代碼操作的是USART1而板載虛擬串口接的是USART2。12. 另一種思路直接繞過_write的 ITM 輸出在 Cortex-M3/M4/M7 芯片上除了通過_write你還可以直接在中斷或主循環(huán)里調(diào)用 ITM 端口發(fā)送函數(shù)強行把調(diào)試數(shù)據(jù)塞到 SWO 引腳。這種方式不經(jīng)過 C 庫也沒有任何格式化負擔。但它只適合輸出原始字節(jié)不適合直接打印格式化的日志。如果只是看某個變量是否變化可以這樣ITM_SendChar(A (flag ? 1 : 0));用 CLion 的 ITM/SWO Console 看輸出直觀高效。而且它不依賴printf所以_write是否重定向都無所謂。這種方式在裸機調(diào)試中非常實用特別是當你懷疑某個中斷觸發(fā)了沒有、某個狀態(tài)機是否切換到了預期狀態(tài)時直接在關(guān)鍵路徑上打一個字符比打斷點更不影響實時性。13. 我的一些總結(jié)性經(jīng)驗寫到這里關(guān)于_write和fputc的差異、CLion 中的落地配置、常見坑位基本都覆蓋了。最后分享幾條實操中沉淀下來的經(jīng)驗第一次在一個新芯片上配置 CLion 調(diào)試輸出時先不要急于寫代碼。先確認調(diào)試器連接正常、可以在 main 入口打斷點然后再處理輸出通道。輸出通道排錯時也先用最簡單的putchar單字符測試而不是直接上printf浮點格式化。在一開始就做成_write 函數(shù)指針輸出的結(jié)構(gòu)雖然前期多寫兩行代碼后面切換調(diào)試器、換評估板時會感謝自己。我吃過不少“為了省事直接硬編碼 ITM 到_write里、結(jié)果換板子后整個調(diào)試日志系統(tǒng)重寫”的虧。如果發(fā)現(xiàn)printf在有浮點參數(shù)的場景輸出異常先檢查-u _printf_float是否加上了。這一步最容易忽略表現(xiàn)又最詭異——整數(shù)能打印浮點打印成空串讓人誤以為是_write的問題。最后也是最重要的所有底層重定向代碼盡量集中在一個文件內(nèi)并且加上顯眼的注釋說明“這里是 C 庫輸出重定向點不要隨意刪除”。嵌入式項目團隊成員多了之后經(jīng)常有人看到_write不知道是干嘛的以為是遺留代碼給刪了意外把整個調(diào)試輸出通道給拆了排查起來非常耗時。用_write還是fputc本質(zhì)上不是“哪個函數(shù)好用”的問題而是“你在哪一層做適配”的問題。把重定向畫在正確的層級上后續(xù)的一切都會順理成章。