1. 把CMSIS-4當(dāng)成一個(gè)“待收購(gòu)標(biāo)的”來拆解的出發(fā)點(diǎn)最近好幾個(gè)項(xiàng)目陸續(xù)碰到同一個(gè)問題手里的老產(chǎn)品還在用幾年前的CMSIS-4工程新來的同事一編譯就報(bào)一堆莫名其妙的警告廠家SDK更新之后鏈接又炸問題是代碼明明一行沒改過。連著處理了幾次這種現(xiàn)場(chǎng)之后我決定不再繼續(xù)“頭痛醫(yī)頭”直接把CMSIS-4這套經(jīng)典的Cortex-M軟件標(biāo)準(zhǔn)庫(kù)當(dāng)成一個(gè)“待收購(gòu)標(biāo)的”做一次徹底的靜態(tài)工程評(píng)測(cè)搞清楚這套遺產(chǎn)庫(kù)里到底埋了什么雷、哪些代碼還能用、哪些必須動(dòng)。先說清楚這次評(píng)測(cè)的對(duì)象。CMSIS-4是ARM為Cortex-M系列處理器定義的一套軟件接口標(biāo)準(zhǔn)覆蓋內(nèi)核訪問、系統(tǒng)初始化、DSP計(jì)算、RTOS接口和設(shè)備描述等多個(gè)層次。雖然ARM早在2018年就把主版本推到了CMSIS-5后續(xù)又陸續(xù)演進(jìn)到CMSIS-6但CMSIS-4作為覆蓋Cortex-M0/M0/M3/M4/M7的最成熟版本至今仍大量存在于存量產(chǎn)品的工程代碼里。很多芯片原廠的SDK在很長(zhǎng)一段時(shí)間內(nèi)繼續(xù)沿用CMSIS-4的組織方式甚至有些老款MCU的官方支持包只在CMSIS-4的框架下維護(hù)。這不是一個(gè)已經(jīng)死掉的標(biāo)準(zhǔn)而是一個(gè)還在生產(chǎn)環(huán)境里跑著的遺產(chǎn)系統(tǒng)所以對(duì)它的“盡調(diào)”必須按工程標(biāo)準(zhǔn)來不能當(dāng)成考古。所謂“靜態(tài)工程評(píng)測(cè)”在我這次操作里指兩層意思。第一層是對(duì)源代碼本身做靜態(tài)審查不燒板子、不跑仿真全程依賴對(duì)源碼結(jié)構(gòu)、宏定義、編譯預(yù)處理結(jié)果、頭文件依賴關(guān)系和目標(biāo)文件構(gòu)成的分析第二層是從工程管理角度做靜態(tài)評(píng)估把這些源代碼放進(jìn)不同工具鏈、不同優(yōu)化等級(jí)、不同芯片型號(hào)的工程環(huán)境里做交叉驗(yàn)證看它在遷移過程中會(huì)暴露什么問題。這種做法特別適合評(píng)估一類代碼的“可遷移性”因?yàn)榇蟛糠诌w移障礙不是運(yùn)行期才暴露的而是在編譯、鏈接、啟動(dòng)初始化這幾個(gè)靜態(tài)階段就已經(jīng)決定了。整個(gè)評(píng)測(cè)過程中我建立了一份比較詳細(xì)的檢查清單后面幾節(jié)會(huì)把它拆開講CMSIS-4組件盤點(diǎn)、源碼層遺產(chǎn)痕跡、編譯器適配層差異、RTOS接口遷移風(fēng)險(xiǎn)、鏈接腳本與啟動(dòng)文件約束、以及最終遷移策略。如果你手上也有基于CMSIS-4的老工程正在猶豫要不要升級(jí)這篇文章能幫你省掉很多試錯(cuò)時(shí)間。2. CMSIS-4到底裝了什么版本、目錄和四類組件2.1 鎖定版本基線CMSIS 4.5.0是真正的主角評(píng)測(cè)CMSIS-4的第一步是先把版本基線釘死。CMSIS-4這個(gè)系列從4.0一路走到4.5中間跨了差不多三年每個(gè)小版本的API細(xì)節(jié)都有差異。我現(xiàn)在能接觸到的存量工程里絕大多數(shù)使用的是4.3.0到4.5.0這個(gè)區(qū)間其中4.5.0是CMSIS-4的最終版本也是這個(gè)分支下最成熟、最完整的形態(tài)。建議任何人在做源碼審查前先確認(rèn)當(dāng)前工程里的CMSIS版本號(hào)。在Keil MDK里CMSIS版本一般藏在Pack安裝目錄下不同芯片廠商的SDK又會(huì)把自己改過的CMSIS核心文件復(fù)制到工程目錄里導(dǎo)致版本信息更難追蹤。最直接的辦法是打開core_cm4.h之類的內(nèi)核頭文件看文件頭注釋里的版本號(hào)另一個(gè)途徑是檢查cmsis_version.h里的__CM_CMSIS_VERSION宏這個(gè)宏從CMSIS 4.4.0開始固定存在數(shù)值編碼規(guī)則是高16位為主版本、低16位為次版本比如0x00050000代表CMSIS 5.0.0。如果工程里找不到這個(gè)文件基本可以斷定CMSIS版本在4.4.0之前那后續(xù)的API差異會(huì)更大。2.2 四個(gè)組件四條相互獨(dú)立的代碼線CMSIS-4的源碼包解壓之后主要包含四個(gè)相對(duì)獨(dú)立的組件域我在評(píng)測(cè)中把它們稱為四條代碼線組件目錄/標(biāo)識(shí)作用范圍與硬件的耦合度CMSIS-CoreCMSIS/Include/內(nèi)核寄存器定義、系統(tǒng)初始化、NVIC/SysTick/PendSV等內(nèi)核外設(shè)訪問極高直接封裝Cortex-M內(nèi)核寄存器CMSIS-DSPCMSIS/DSP_Lib/數(shù)學(xué)運(yùn)算庫(kù)包括基礎(chǔ)運(yùn)算、矩陣運(yùn)算、濾波、變換等中等部分實(shí)現(xiàn)依賴DSP指令/SIMDCMSIS-RTOS APICMSIS/RTOS/定義RTOS內(nèi)核的標(biāo)準(zhǔn)API接口中低是接口規(guī)范而非具體實(shí)現(xiàn)CMSIS-SVDCMSIS/SVD/設(shè)備外設(shè)描述文件用于調(diào)試器外設(shè)視圖低主要供調(diào)試工具解析這四條線的演進(jìn)節(jié)奏完全不同遷移時(shí)不能一刀切。CMSIS-Core的更新最頻繁因?yàn)樗苯痈鴥?nèi)核版本和編譯器特性走幾乎每個(gè)小版本都會(huì)改頭文件的宏定義CMSIS-DSP包的更新則集中在算法實(shí)現(xiàn)優(yōu)化上尤其是針對(duì)M4/M7的SIMD和FPU指令CMSIS-RTOS API在4.5.0之前同時(shí)維護(hù)v1和v2兩套接口這是個(gè)非常大的遷移隱患CMSIS-SVD則基本穩(wěn)定除了描述格式微調(diào)之外幾乎沒有破壞性變更。2.3 一個(gè)頭文件家族如何撐起所有Cortex-M型號(hào)CMSIS-Core是這套遺產(chǎn)庫(kù)的基石它的核心組織形式是一族以core_cmX.h命名的內(nèi)核頭文件針對(duì)不同Cortex-M內(nèi)核提供寄存器定義和訪問函數(shù)。CMSIS-4時(shí)代支持的內(nèi)核包括core_cm0.h、core_cm0plus.h、core_cm3.h、core_cm4.h、core_cm7.h外加一個(gè)針對(duì)Secure擴(kuò)展的core_cm23.h和core_cm33.h是在CMSIS-4后期加入的。這套設(shè)計(jì)思路本質(zhì)上是用預(yù)處理器條件編譯實(shí)現(xiàn)“一次包含多種內(nèi)核適配”。每個(gè)頭文件內(nèi)部都有大量的#if defined判斷根據(jù)__CM4_REV、__FPU_PRESENT、__MPU_PRESENT這類宏決定是否展開對(duì)應(yīng)寄存器定義。這樣做的好處是應(yīng)用層代碼幾乎不用關(guān)心內(nèi)核差異壞處是宏定義體系極度脆弱任何一個(gè)宏漏定義或定義沖突都能產(chǎn)生讓人摸不著頭腦的編譯錯(cuò)誤。我實(shí)際審查過的工程里最常見的宏問題出在__FPU_PRESENT上。老工程總是忘記定義這個(gè)宏導(dǎo)致core_cm4.h里整個(gè)FPU相關(guān)寄存器組被條件編譯排除而應(yīng)用代碼里只要牽涉到SCB-CPACR這類FPU使能寄存器就會(huì)編譯失敗。就算編譯通過了浮點(diǎn)運(yùn)算也會(huì)走軟件模擬路徑性能慘不忍睹。這個(gè)問題在CMSIS-5/6里已經(jīng)通過強(qiáng)制定義機(jī)制大幅緩解但在CMSIS-4里只能靠人工保證這也是“遺產(chǎn)痕跡”的典型代表。2.4 不要忽略啟動(dòng)文件和系統(tǒng)文件的“隱性版本”除了CMSIS/Include/目錄下的標(biāo)準(zhǔn)頭文件CMSIS-4源碼包里還有兩個(gè)容易被人忽略的隱藏組件一個(gè)是Device/目錄下每個(gè)芯片廠商提供的system_xxx.c系統(tǒng)初始化文件和啟動(dòng)匯編文件另一個(gè)是分散在CMSIS/DSP_Lib/Source/下的各類DSP源碼文件。嚴(yán)格來說系統(tǒng)文件和啟動(dòng)文件不屬于CMSIS標(biāo)準(zhǔn)本身而是CMSIS框架下芯片廠商必須實(shí)現(xiàn)的部分但它們與CMSIS頭文件的耦合程度極高遷移CMSIS版本時(shí)如果只換頭文件不換系統(tǒng)文件經(jīng)常會(huì)因?yàn)镾ystemCoreClock變量的類型或初始化邏輯不一致產(chǎn)生隱蔽的時(shí)序問題。我這里要給一個(gè)很實(shí)用的排查建議靜態(tài)審查時(shí)用腳本把所有#include的頭文件路徑全部列出來檢查是否存在同一個(gè)頭文件被從多個(gè)目錄引入的情況。CMSIS版本混亂絕大多數(shù)根因是工程里既保留了廠商SDK自帶的舊CMSIS頭文件又新增了從ARM官方包解壓的新CMSIS頭文件兩個(gè)core_cm4.h同時(shí)在include path序列里編譯行為由路徑順序決定。這種問題編譯時(shí)不一定會(huì)報(bào)錯(cuò)但生成的代碼時(shí)而好時(shí)而壞最讓人頭疼。3. 靜態(tài)審查落到源碼層面看到了哪些“遺產(chǎn)痕跡”3.1 編譯器適配層一份為了armcc v5而生的補(bǔ)丁式代碼把CMSIS-4的源碼平鋪開看最直觀的感受是它對(duì)編譯器適配的處理方式非?！把a(bǔ)丁化”。我統(tǒng)計(jì)了core_cm4.h和一些周邊頭文件里與編譯器相關(guān)的條件編譯分支至少覆蓋了ARMCC v4/v5、GCC、IAR、Clang四類編譯器每一類編譯器還細(xì)分了不同版本和不同語(yǔ)言標(biāo)準(zhǔn)。在這個(gè)適配層里最典型的是__ASM、__INLINE、__STATIC_INLINE、__PACKED這一組編譯器抽象宏。以__STATIC_INLINE為例CMSIS-4早期版本針對(duì)ARMCC定義的是static __inline而__inline在armcc v5里只是一個(gè)建議性關(guān)鍵字編譯器可以自行決定是否內(nèi)聯(lián)到了GCC環(huán)境下它又變成static inline語(yǔ)義基本一致但也存在細(xì)微差異。CMSIS-5之后這套宏被改成__STATIC_INLINE統(tǒng)一命名并且針對(duì)每個(gè)編譯器單獨(dú)定義成static inline。表面上看只是一個(gè)宏名變化實(shí)際影響的是所有內(nèi)核訪問函數(shù)的內(nèi)聯(lián)行為進(jìn)而影響中斷延遲和臨界區(qū)保護(hù)的代碼尺寸。在靜態(tài)評(píng)測(cè)中我用armclang和gcc分別做了同一份CMSIS-4源碼的交叉編譯對(duì)照結(jié)果非常有意思同樣的NVIC_EnableIRQ函數(shù)在armcc v5下生成的指令序列可能比armclang下短一條指令。原因不是編譯器優(yōu)化能力差異而是CMSIS-4為armcc v5專門寫的內(nèi)聯(lián)匯編路徑在armclang下根本不生效編譯器退回到了通用C實(shí)現(xiàn)路徑。這就是典型的編譯器適配層帶來的隱性性能差異靜態(tài)分析不仔細(xì)看根本發(fā)現(xiàn)不了。3.2 __STATIC_INLINE宏家族一段不該被低估的歷史包袱繼續(xù)深挖__STATIC_INLINE這組宏會(huì)發(fā)現(xiàn)更多問題。CMSIS-4源碼里大量使用#if defined ( __CC_ARM )、#elif defined ( __ICCARM__ )、#elif defined ( __GNUC__ )這樣的三段式條件編譯。這套寫法在2015年前后是合理的選擇因?yàn)楫?dāng)時(shí)armcc v5是整個(gè)嵌入式工具鏈的事實(shí)標(biāo)準(zhǔn)GCC則是開源陣營(yíng)的主流IAR有自己的私有關(guān)鍵字系統(tǒng)。但到了今天面對(duì)CMSIS-4做新的工程開發(fā)情況已經(jīng)完全不同。Arm Compiler 6即armclang已經(jīng)成為ARM官方主推的編譯器它在預(yù)定義宏上和GCC高度一致卻在很多CMSIS-4代碼的__GNUC__分支下表現(xiàn)不佳因?yàn)镃MSIS-4對(duì)GCC分支的適配主要針對(duì)的是arm-none-eabi-gcc的行為而不是armclang的LLVM后端行為。舉個(gè)具體的坑CMSIS-4中某些GCC分支的代碼使用__attribute__((always_inline))指導(dǎo)內(nèi)聯(lián)armclang也支持這個(gè)屬性但對(duì)于內(nèi)聯(lián)匯編中的寄存器約束armclang與GCC存在語(yǔ)法差異導(dǎo)致部分DSP庫(kù)源碼在armclang下直接編譯失敗。這個(gè)問題的本質(zhì)是CMSIS-4把“編譯器差異”和“架構(gòu)差異”混在同一套頭文件里處理沒有做到關(guān)注點(diǎn)分離。所以靜態(tài)評(píng)測(cè)時(shí)我建議工程人員對(duì)每個(gè)編譯器分支進(jìn)行單獨(dú)的可編譯性和指令序列對(duì)照不要默認(rèn)“GCC能過armclang就一定沒問題”。3.3 DSP庫(kù)里的SIMD和FPU靜態(tài)能看到的最深一層硬核CMSIS-DSP在CMSIS-4時(shí)代是一套C語(yǔ)言和匯編混合編寫的數(shù)學(xué)運(yùn)算庫(kù)其中M4/M7內(nèi)核下的很多核心函數(shù)比如arm_mat_mult_f32、arm_fir_f32、arm_cfft_f32都針對(duì)ARMv7E-M架構(gòu)的SIMD指令如SMLAD、SMLALD、PKHBT做了手寫匯編優(yōu)化。對(duì)這些匯編實(shí)現(xiàn)進(jìn)行靜態(tài)審查時(shí)要注意一個(gè)關(guān)鍵技術(shù)約束CMSIS-4的DSP庫(kù)是為ARMv7E-M架構(gòu)即Cortex-M4/M7設(shè)計(jì)的它的SIMD指令最佳化完全基于這個(gè)架構(gòu)的指令集特性。如果你現(xiàn)在要把代碼遷移到Cortex-M33這類基于ARMv8-M架構(gòu)的內(nèi)核上CMSIS-4 DSP庫(kù)的很多優(yōu)化路徑無法直接使用因?yàn)锳RMv8-M的SIMD支持和ARMv7E-M并不完全一致。ARM官方在CMSIS-5的DSP庫(kù)中才對(duì)這個(gè)問題做了系統(tǒng)性修補(bǔ)新增了針對(duì)ARMv8-M的優(yōu)化分支。另一個(gè)值得說的點(diǎn)是CMSIS-4 DSP庫(kù)里對(duì)FPU編譯選項(xiàng)的依賴。__FPU_USED、__FPU_PRESENT這兩個(gè)宏的組合決定FPU相關(guān)代碼是否被編譯。我在靜態(tài)審查中經(jīng)常發(fā)現(xiàn)老工程的__FPU_PRESENT設(shè)置為1但編譯選項(xiàng)里沒加-mfloat-abihard結(jié)果編譯器按軟浮點(diǎn)ABI生成調(diào)用約定而庫(kù)里的硬浮點(diǎn)匯編函數(shù)按硬浮點(diǎn)ABI聲明接口鏈接階段不報(bào)錯(cuò)運(yùn)行階段參數(shù)傳遞錯(cuò)位浮點(diǎn)計(jì)算結(jié)果莫名其妙地偏差。這種問題用靜態(tài)分析工具很難抓必須結(jié)合預(yù)處理輸出的宏定義和編譯命令行參數(shù)一起看才能定位。3.4 頭文件依賴關(guān)系的“一切皆可include”問題還有一個(gè)在靜態(tài)評(píng)測(cè)中暴露得非常明顯的問題CMSIS-4源碼里core_cm4.h等內(nèi)核頭文件對(duì)標(biāo)準(zhǔn)庫(kù)頭文件的依賴較少這本來是好事但它自身內(nèi)部依賴關(guān)系卻非?；靵y。比如某些版本的頭文件在使用assert_param宏時(shí)默認(rèn)指向一個(gè)未定義的assert_param需要用戶在工程中自行定義否則編譯直接失敗。這種設(shè)計(jì)在CMSIS-4中是有意為之它讓用戶能自定義斷言行為但代價(jià)是每個(gè)工程都要額外加一行宏定義。更麻煩的是CMSIS目錄下的頭文件名與芯片廠商SDK中的同名頭文件之間沒有強(qiáng)制的一致性校驗(yàn)機(jī)制。在同一個(gè)工程里同時(shí)出現(xiàn)兩個(gè)core_cm4.h文件時(shí)編譯器不會(huì)報(bào)警鏈接器更不會(huì)察覺。我在排查一個(gè)量產(chǎn)產(chǎn)品的疑難問題時(shí)發(fā)現(xiàn)一個(gè)函數(shù)在頭文件A中的內(nèi)聯(lián)實(shí)現(xiàn)指向SysTick_Config的舊版寄存器操作而頭文件B中已經(jīng)有針對(duì)新硅片修訂的勘誤處理代碼結(jié)果編譯器優(yōu)先包含了舊的A版本導(dǎo)致定時(shí)器始終無法按預(yù)期觸發(fā)中斷。這個(gè)案例對(duì)我的啟示是任何對(duì)CMSIS-4的靜態(tài)評(píng)測(cè)都必須先做頭文件溯源用腳本打印每個(gè)核心頭文件的實(shí)際物理路徑再判斷它到底屬于哪個(gè)CMSIS版本。4. 從CMSIS-4走出來的四條遷移護(hù)欄4.1 編譯器工具鏈遷移armcc v5到armclang的斷層對(duì)還在CMSIS-4上的老工程遷移時(shí)最先撞上的不是CMSIS本身而是工具鏈的換代。Keil MDK從5.x后期版本開始默認(rèn)編譯器從armcc v5切換到Arm Compiler 6也就是armclang。這不是一個(gè)簡(jiǎn)單的編譯器版本升級(jí)而是一次從C89/C99工具鏈到C11/基于LLVM的工具鏈的范式切換。CMSIS-4在armcc v5下編譯是無縫的因?yàn)閮烧弑緛砭褪峭谠O(shè)計(jì)、同步發(fā)布的但換到armclang后CMSIS-4里大量依賴ARMCC特定擴(kuò)展語(yǔ)法的地方會(huì)暴露問題。最常見的是內(nèi)聯(lián)匯編格式差異、__forceinline關(guān)鍵字的支持差異、以及對(duì)#pragma的語(yǔ)義差異。我在評(píng)測(cè)中用一個(gè)原生CMSIS-4.5工程做armclang編譯測(cè)試頭文件里的內(nèi)核訪問函數(shù)大部門能過但DSP庫(kù)的匯編文件基本全軍覆沒必須額外引入CMSIS-5版本的DSP庫(kù)才能編過。遷移時(shí)的實(shí)際建議是不要嘗試讓CMSIS-4源碼“適應(yīng)”armclang這條路走不通。正確做法是把CMSIS Core頭文件升級(jí)到CMSIS-5或CMSIS-6的Include目錄因?yàn)檫@部分實(shí)現(xiàn)了對(duì)armclang的完整適配同時(shí)保留應(yīng)用層代碼。如果芯片廠商已經(jīng)把設(shè)備支持包升級(jí)到CMSIS-5框架那就直接用新版如果廠商沒有升級(jí)那就需要手動(dòng)混合搭配這時(shí)候要格外注意版本兼容矩陣不能只看單個(gè)頭文件的版本號(hào)。4.2 CMSIS-RTOS接口從v1到v2的API斷層CMSIS-4雙軌維護(hù)的RTOS接口可能是整個(gè)遷移過程中最敏感的部分。CMSIS-RTOS v1的API設(shè)計(jì)較為樸素核心對(duì)象只有osThreadId、osMessageQId這類以ID句柄為主的數(shù)據(jù)類型整個(gè)API風(fēng)格偏向函數(shù)式調(diào)用v2則引入了指針型對(duì)象句柄、更強(qiáng)大的事件標(biāo)志、信號(hào)量、互斥量、內(nèi)存池等機(jī)制API數(shù)量幾乎翻倍。靜態(tài)評(píng)測(cè)老工程時(shí)我習(xí)慣先全局搜索osThreadCreate、osMessagePut、osSemaphoreWait等典型v1 API調(diào)用快速確定工程對(duì)RTOS接口版本的依賴程度。一般存量工程里要么是早期基于CMSIS-RTOS v1封裝了業(yè)務(wù)代碼要么是通過Keil的RTX5中間層自動(dòng)映射到v2。前者在升級(jí)CMSIS版本時(shí)編譯錯(cuò)誤會(huì)像洪水一樣涌出來因?yàn)関1和v2的頭文件不能同時(shí)存在而應(yīng)用代碼調(diào)用的多半是v1風(fēng)格API。這里要給一個(gè)保守建議如果你沒有重構(gòu)業(yè)務(wù)代碼的預(yù)算就不要貿(mào)然把cmsis_os.h從v1切到v2。CMSIS-4分支下最后一個(gè)同時(shí)支持v1和v2的版本是4.5.0雖然在CMSIS-5中放棄了v1但對(duì)于短期內(nèi)不打算改代碼的存量工程停留在CMSIS-4.5.0反而是一個(gè)穩(wěn)定選項(xiàng)。只有當(dāng)你有計(jì)劃地重構(gòu)整個(gè)RTOS應(yīng)用層時(shí)再考慮一次性跳到v2。4.3 芯片設(shè)備和啟動(dòng)文件約束廠商SDK的綁定比想象中更緊很多人忽略了CMSIS-4遷移的另一條硬約束芯片廠商的設(shè)備支持包。CMSIS標(biāo)準(zhǔn)本身的遷移是“換頭文件”的問題但嵌入式工程的編譯鏈接還依賴startup_xxx.s啟動(dòng)文件和system_xxx.c系統(tǒng)文件這些文件由芯片廠商維護(hù)字段和函數(shù)簽名很可能與CMSIS-4綁定。我做過一個(gè)實(shí)驗(yàn)把一個(gè)Cortex-M4芯片的廠商SDK中CMSIS Core頭文件單獨(dú)升級(jí)到CMSIS-5結(jié)果系統(tǒng)初始化文件system_stm32f4xx.c里的SystemCoreClock變量類型和新的CMSIS-5頭文件中的外部聲明不一致編譯時(shí)雖然沒報(bào)錯(cuò)但通過map文件檢查發(fā)現(xiàn)同一個(gè)變量在不同編譯單元中被分配到了不同地址——這種問題在靜態(tài)分析階段極難發(fā)現(xiàn)只能通過對(duì)比預(yù)處理宏定義和符號(hào)表來定位。更隱蔽的是啟動(dòng)文件中的向量表定義。CMSIS-4時(shí)代向量表的弱默認(rèn)處理方式與CMSIS-5/6有些差異尤其涉及__initial_sp和Reset_Handler的符號(hào)導(dǎo)出方式。如果你的工程使用新libc或microLIB這些符號(hào)的交互方式也會(huì)不同。對(duì)這條約束的應(yīng)對(duì)策略是評(píng)估階段先列出工程里所有屬于芯片廠商SDK的文件逐文件檢查它們與CMSIS版本的相對(duì)關(guān)系。廠商SDK里有很大一部分代碼是圍繞CMSIS封裝的外設(shè)驅(qū)動(dòng)庫(kù)這部分不依賴CMSIS版本真正需要鎖定版本的只有system文件和startup文件評(píng)估后決定是跟隨遷移還是鎖定不升級(jí)。4.4 鏈接腳本與內(nèi)存布局老規(guī)劃不一定適配新代碼CMSIS遷移帶來的另一個(gè)隱性風(fēng)險(xiǎn)是代碼尺寸和內(nèi)存布局的變化。CMSIS-5之后的頭文件雖然API接口相似但內(nèi)聯(lián)函數(shù)的實(shí)現(xiàn)方式更緊湊編譯器從armcc切到armclang后浮點(diǎn)運(yùn)算的代碼尺寸也可能明顯改變。這些變化會(huì)導(dǎo)致原本“剛好夠用”的鏈接腳本出現(xiàn)Flash溢出或RAM越界。做靜態(tài)評(píng)測(cè)時(shí)我特別關(guān)注兩個(gè)數(shù)據(jù)一個(gè)是map文件里各個(gè)段的大小分布一個(gè)是啟動(dòng)文件里Stack和Heap的定義值。老工程在CMSIS-4時(shí)代設(shè)置的堆棧大小往往是基于當(dāng)時(shí)編譯器行為手動(dòng)調(diào)整出來的“經(jīng)驗(yàn)值”換成armclang之后函數(shù)調(diào)用棧的消耗可能完全不同。有一個(gè)非常典型的癥狀升級(jí)工具鏈后程序跑一段時(shí)間后隨機(jī)進(jìn)入HardFault回溯棧卻發(fā)現(xiàn)指針已經(jīng)被破壞這就是典型的棧溢出。靜態(tài)評(píng)測(cè)階段沒法直接驗(yàn)證棧深度但可以通過編譯期加-fstack-usage讓編譯器為每個(gè)函數(shù)生成棧使用報(bào)告再用腳本統(tǒng)計(jì)最大調(diào)用路徑推斷是否超限。還有一個(gè)更容易被忽略的內(nèi)存布局問題CMSIS-4時(shí)代的DSP庫(kù)自帶了一套中斷向量重映射的配置方式部分工程會(huì)在鏈接腳本里為DSP庫(kù)預(yù)留專用RAM區(qū)域。如果DSP庫(kù)升級(jí)到CMSIS-5版本這些專用區(qū)域的起始地址對(duì)齊要求可能改變導(dǎo)致緩存或MPU配置失效。5. 遷移決策的最終態(tài)度什么時(shí)候該走什么時(shí)候該留5.1 先用一張決策表決定方向而不是先動(dòng)手改CMSIS-4的老工程是否要遷移這不是一個(gè)純技術(shù)問題而是一個(gè)工程決策問題。我在評(píng)測(cè)結(jié)束后梳理了一張決策表可以幫助團(tuán)隊(duì)快速判斷方向決策因素建議留在CMSIS-4建議遷移到CMSIS-5/6工具鏈仍使用armcc v5無更換計(jì)劃已切換到armclang或GCC最新版產(chǎn)品生命周期產(chǎn)品即將退市或凍結(jié)產(chǎn)品還有3年以上維護(hù)期新功能需求只有bug修復(fù)無新功能需要新增連接、安全、機(jī)器學(xué)習(xí)等功能RTOS使用重度依賴CMSIS-RTOS v1并難以短期重構(gòu)已使用RTX5/FreeRTOS或愿意重構(gòu)外設(shè)驅(qū)動(dòng)依賴廠商SDK僅支持CMSIS-4框架廠商SDK已發(fā)布CMSIS-5/6版支持包團(tuán)隊(duì)技能團(tuán)隊(duì)熟悉armcc v5排錯(cuò)方式團(tuán)隊(duì)已掌握armclang/GCC調(diào)試技巧列這張表的用意是提醒大家遷移的成本不只是代碼編譯一遍還包括重新驗(yàn)證所有外設(shè)行為、時(shí)序特性和低功耗路徑。如果產(chǎn)品線已經(jīng)進(jìn)入維護(hù)模式CMSIS-4.5.0配合armcc v5反而是穩(wěn)定性最高的組合強(qiáng)行升級(jí)只會(huì)引入無謂的回歸風(fēng)險(xiǎn)。5.2 漸進(jìn)遷移的正確姿勢(shì)用CMSIS-5頭文件替代CMSIS-4而不是推倒重來如果決策結(jié)果是遷移我的經(jīng)驗(yàn)是不要一上來就大動(dòng)干戈。最平滑的路徑是分四步走第一步只替換CMSIS Core頭文件。把工程里core_cm4.h、core_cmFunc.h、core_cmInstr.h等核心頭文件換成CMSIS-5版本保留應(yīng)用代碼不變。這一步的目標(biāo)是先把編譯器適配問題解決干凈確保在armclang或新版GCC下能順利編譯鏈接。第二步替換system文件和startup文件。將芯片廠商針對(duì)CMSIS-5發(fā)布的最新系統(tǒng)初始化文件和啟動(dòng)文件合入工程重點(diǎn)驗(yàn)證SystemCoreClock變量定義、SystemInit執(zhí)行時(shí)機(jī)和向量表符號(hào)的兼容性。第三步升級(jí)DSP庫(kù)。這一步工程量較大建議按模塊拆分替換優(yōu)先替換實(shí)際用到的函數(shù)暫時(shí)未使用的可以先不編入。CMSIS-5的DSP庫(kù)源碼組織方式與CMSIS-4差異較大新增了大量以arm_前綴命名的頭文件和源碼需要仔細(xì)核對(duì)函數(shù)別名和數(shù)據(jù)類型定義。第四步最后處理RTOS層。只有當(dāng)應(yīng)用代碼要新增并發(fā)功能或需要用到v2的新特性時(shí)才值得動(dòng)RTOS層。如果只是純粹為升級(jí)而升級(jí)RTOS這個(gè)環(huán)節(jié)可以放一放。這套漸進(jìn)路線的核心邏輯是每一步都能保證工程處于可編譯、可運(yùn)行的狀態(tài)始終有一個(gè)可以回退的穩(wěn)定基線而不是把全部修改堆到一起再統(tǒng)一驗(yàn)證。5.3 遷移完成后應(yīng)有的靜態(tài)保障機(jī)制遷移不是終點(diǎn)真正決定長(zhǎng)期幸福感的是后續(xù)能否持續(xù)控制源碼質(zhì)量。根據(jù)這次評(píng)測(cè)的經(jīng)驗(yàn)我強(qiáng)烈建議在遷移完成后搭三件事第一把CMSIS頭文件版本納入CI檢查。寫一個(gè)腳本在每次編譯前遍歷所有被包含的core_cmX.h輸出每個(gè)文件的絕對(duì)路徑和文件頭聲明的CMSIS版本號(hào)任何一個(gè)路徑下出現(xiàn)版本號(hào)不一致就報(bào)警。這個(gè)機(jī)制能在源頭上杜絕“新舊CMSIS混用”這個(gè)最大的靜態(tài)隱患。第二強(qiáng)制統(tǒng)一宏定義清單。把工程編譯命令中-D傳入的宏整理成一份cmsis_config.h文件集中定義__FPU_PRESENT、__MPU_PRESENT、__VTOR_PRESENT、__ICACHE_PRESENT等關(guān)鍵配置宏并通過#error指令約束沖突組合。CMSIS系列頭文件中很多條件編譯的錯(cuò)誤本質(zhì)上是宏定義分布太散導(dǎo)致的集中管理能顯著降低這類問題概率。第三預(yù)設(shè)一條“編譯干凈基線”。用一個(gè)固定版本的芯片SDK、固定工具鏈、固定優(yōu)化等級(jí)編譯一次生成完整工程把警告和編譯輸出的baseline保存下來。后續(xù)任何代碼變更都基于這個(gè)baseline做增量比對(duì)新出現(xiàn)的警告和錯(cuò)誤能第一時(shí)間被標(biāo)記出來。CMSIS-4的老代碼里本身就有不少歷史遺留的警告如果不設(shè)基線很容易把新引入的問題和舊問題混在一起排查效率極低。這次對(duì)CMSIS-4的靜態(tài)工程評(píng)測(cè)最終得到的結(jié)論用一句話概括就是CMSIS-4不是洪水猛獸但它的“遺產(chǎn)屬性”決定了它只能被理解、被約束、被有計(jì)劃地替換而不能被當(dāng)作新工程的默認(rèn)地基繼續(xù)往上壘。搞清楚它的源碼里藏著哪些宏、哪些匯編分支、哪些RTOS舊API再?zèng)Q定是鎖定老版本穩(wěn)定運(yùn)行還是分批漸進(jìn)遷移這才是務(wù)實(shí)的工程態(tài)度。