CMSIS-5源码深度拆解：从Cortex-M内核到DSP与RTOS的架构设计

最近因为一个跨平台嵌入式项目，我把ARM官方的CMSIS-5源码完整拉下来，从头到尾过了一遍。说实话，嵌入式圈里用CMSIS的人不少，但大多数人其实停留在“include一个头文件、调几个寄存器操作宏”的程度，很少有人把它当成一套值得认真研究的架构设计范本。我之前也属于前者，这次为了搞明白一个DSP相关的性能问题，被迫把整套代码翻了个底朝天，结果收获比预想中大得多。于是想着把这套源码的架构全景、模块分层的设计逻辑、以及它在工程治理上的那些看似不起眼却非常关键的小细节，系统地整理一下，顺便聊聊在实际项目里怎么选、怎么落地。

CMSIS-5全称是Cortex Microcontroller Software Interface Standard，ARM在2008年提出并不断迭代的标准软件框架。它解决的并不是“驱动库怎么写得更好用”这种表层问题，而是把Cortex-M系列芯片在软件开发层面最底层、最公共的那部分能力给标准化了：内核寄存器访问、中断控制器、系统节拍、存储器模型、调试接口、DSP计算原语、甚至上层RTOS的统一接口。把这个标准吃透，等于把Cortex-M的“地基”看明白了，后面不管是跑Keil还是GCC、用STM32还是GD32或者其他M内核芯片，逻辑都是通的。

这篇东西我不打算写成ARM官方文档的翻译稿，而是以源码阅读笔记的方式，把CMSIS-5的模块分层、设计思想和工程治理细节拆开讲，最后落到真实项目的选型建议上。正在做或者打算做Cortex-M相关开发的同学，无论你是刚入行的新手还是被外设库束缚了很久的老手，这篇都值得花点时间看下去。

1. CMSIS-5全景视野：它到底在解决什么问题

1.1 先搞清楚CMSIS-5的定位

很多人第一次接触CMSIS是在Keil里建工程的时候，莫名其妙多了一个CMSIS文件夹，里面一堆core_cm开头的头文件，也不知道是谁加的、有什么用。实际上CMSIS不是一个驱动库，也不是一个操作系统，它是一层“标准接口”。

我在做多平台项目时，发现Cortex-M0、M3、M4、M7、M33这些不同内核的寄存器布局、指令集各有差异。如果每一款芯片都让工程师直接操作寄存器的绝对地址，整个开发过程会非常痛苦。CMSIS-Core做的事情就是把这些差异收口：不管底层是M0+还是M4，NVIC_EnableIRQ、SysTick_Config、__enable_irq这些接口长得一摸一样，编译器不同也没关系，内部实现会自己切换。这层抽取带来的直接效果是：上层业务代码基本不用关心你用的是哪个Cortex-M内核。

它的核心价值可以归纳成三点：第一，统一了寄存器访问层，避免每个厂家各自一套；第二，统一了编译器相关语法，让同一份代码可以在GCC、Arm Compiler、IAR之间切换；第三，向上层中间件提供标准接口，比如DSP、RTOS、NN等都有可以依赖的公共API。

1.2 CMSIS-5家族模块一览

CMSIS-5并不是一个单一的库，而是一个家族。简单梳理一下：

越到后面越往上层的“工具链生态”走。日常开发中大家最直接接触的，是CMSIS-Core、CMSIS-DSP、CMSIS-NN、CMSIS-RTOS2这四个。CMSIS-Driver和CMSIS-Pack虽然也很重要，但更多影响的是项目工程治理层面的东西。

提示：CMSIS 6.0已经存在一段时间了，但很多老项目、老SDK、老工具链仍然停留在CMSIS 5.x。目前看，5.x的存量代码量巨大，短期内并不会被完全替代。所以学5.x不亏，理解这个版本的结构和设计意图，对理解6.0也有帮助。

1.3 CMSIS和各家HAL库的本质区别

有个问题经常被问：CMSIS和STM32的HAL库是什么关系？我用过ST的HAL、也用过GD32的标准外设库，它们和CMSIS不是同一个层级。打个比方：CMSIS是芯片内核的“底板”，它管的是NVIC、SysTick、SCB、内核寄存器这些CPU内部结构；而HAL库管的是USART、SPI、I2C、GPIO这类片内外设配置。举个例子，你要开一个串口中断，HAL库负责把USART外设寄存器配置好，但真正让这个IRQ能被CPU响应、能被CPU跳到正确的中断服务函数，靠的是CMSIS定义的NVIC操作接口和中断向量表机制。

平时开发中两者配合使用，但如果你把CMSIS当成又一套HAL库来看，就会迷失方向。它的设计目标是让芯片公司、工具链厂商、软件中间件厂商都依赖同一层接口，而不是把某个外设封装得多好用。理解了这层关系，看源码的时候就不会问“CMSIS为什么没有GPIO_SetMode这种函数”这种问题了。

2. 源码级拆解：CMSIS核心模块的分层设计与设计思路

2.1 CMSIS-Core：从NVIC_EnableIRQ看一套接口适配全家族

CMSIS-Core的源码结构很清晰，按内核系列拆成core_cm0.h、core_cm3.h、core_cm4.h、core_cm7.h、core_cm23.h、core_cm33.h和core_cm35p.h等，同时配合cmsis_gcc.h、cmsis_armcc.h、cmsis_iar.h等编译器适配头文件。这套结构把“内核差异”和“编译器差异”两个维度独立处理了。

我挑一个最常用的函数作为例子，看一下NVIC_EnableIRQ在core_cm4.h里的实现：

__STATIC_INLINE void NVIC_EnableIRQ(IRQn_Type IRQn) { if ((int32_t)(IRQn) >= 0) { NVIC->ISER[(((uint32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)IRQn) & 0x1FUL)); } }

这个函数的逻辑很简洁，但藏着不少细节。IRQn_Type是一个枚举类型，负数代表CPU内核异常（比如非屏蔽中断NMI、HardFault等），正数代表芯片厂商定义的外部中断。所以第一个if判断就是“只有外部中断才需要操作NVIC”。ISER是Interrupt Set-Enable Register的缩写，在M3/M4上有一组，每个寄存器32位，刚好对应32个中断。右移5位相当于除以32，算出当前中断对应第几个ISER寄存器；与运算& 0x1F相当于取模32，算出在寄存器里的哪一位。这种位操作写法在嵌入式源码里非常典型，省了一堆switch-case，性能也高。

类似的封装还包括NVIC_SetPriority、SysTick_Config、__enable_irq、__disable_irq等。它们共同构成了一个完整的“CPU私有外设驱动”。为什么说CMSIS-Core本质上是个驱动？因为它把NVIC、SysTick、SCB这些“核内设备”全部封装成了可调用的函数，跟你用HAL驱动一个UART外设在逻辑上是一样的。

2.2 CMSIS-DSP：性能优化不止是“调用库函数”

CMSIS-DSP是我这次读源码的直接原因。当时在某个M7平台上做音频算法，发现浮点滤波耗时和理论值差得很远，最后排查下来是宏定义没设对，库走了通用分支而不是硬件加速分支。

CMSIS-DSP值得认真研究的,是它对不同内核指令集做的针对性优化。以常见的FIR滤波器为例，arm_fir_f32在不同宏定义下会启用不同的分支：如果定义了ARM_MATH_CM7或者ARM_MATH_M4，编译器会看到针对M4/M7的SIMD指令优化代码路径，回退到普通C实现时性能差距可能接近4到5倍。这里的关键不是“库函数写得好不好”，而是你是否按正确姿势启用了对应的加速路径。

使用CMSIS-DSP时的几个关键宏，我直接列出来：

• ARM_MATH_CM0 / ARM_MATH_CM0PLUS：Cortex-M0/M0+，无硬件浮点无DSP扩展
• ARM_MATH_CM3：Cortex-M3，无硬件浮点
• ARM_MATH_CM4：Cortex-M4，带DSP扩展，可选用FPU
• ARM_MATH_CM7：Cortex-M7，带DSP扩展，双精度/单精度FPU可选
• ARM_MATH_M33 / ARM_MATH_M55：对应ARMv8-M架构的M33和M55

宏定义错误会出现什么情况？编译正常，链接正常，程序也能跑，但速度慢得离谱。因为arm_math.h在不同宏下会选不同的内联函数和预编译分支，宏没定义时默认走最保守的路径。这类问题最难排查，因为它没有任何报错信息。

另外，CMSIS-DSP里的定点格式处理也值得一学。Q15、Q31这些格式，本质上是把小数用整数去表示，用在M0/M3这种没有FPU的平台上特别常见。比如做FFT，定点版本和浮点版本可能性能差好几倍，因为定点运算可以直接用硬件整数乘加指令，而浮点在软解环境下非常耗时。

我在实际项目中会把DSP库的控制块和数据缓冲区按16字节对齐，特别是矩阵运算类函数。CMSIS-DSP内部为了提升cache命中率，对某些数据区域有对齐要求，不对齐轻则性能变差，重则在某些内核上直接HardFault。这不是吓人，我曾经在一个M7项目里因为数组对齐问题，调试了整整一个下午。

2.3 CMSIS-NN：神经网络算子在MCU上的正确落地姿势

CMSIS-NN是CMSIS-5家族里比较“新”的成员，目标很直接：让Cortex-M系列的MCU能跑得动轻量级神经网络模型。和人们在电脑上跑TensorFlow不同，MCU上的神经网络推理极其依赖定点计算，大部分场景下走的是int8路线。

我翻CMSIS-NN源码时最大的收获，是理解了“为什么要在MCU上手工优化卷积计算”。以arm_convolve_s8为例，它的核心思路是把卷积操作转化为矩阵乘，也就是常说的im2col方式，然后再利用M4/M7/M55的DSP扩展指令做乘累加。CMSIS-NN内部还会专门做权重重排、内存复用这些额外处理，目的都是减少MCU上最稀缺的资源和最耗时的内存访问。

如果你在Cortex-M7/M33这类内核上跑模型，CMSIS-NN是值得参考的优化范例。但如果你的目标内核是M0或M0+，CMSIS-NN的意义就不大了。因为这些内核没有DSP扩展指令，int8优化发挥不了优势，反而会花大量内存去存中间展开的数据。我在一个低端MCU项目上跑过一个小模型，最后对比下来直接用普通C写的简化版推理代码比引入CMSIS-NN更轻快。所以这里特别想说一句：别觉得“官方库就是最优解”，还是要看你具体的内核和算法特点。

2.4 CMSIS-RTOS2：一套API跑多种RTOS的设计智慧

CMSIS-RTOS2是我这次看完之后内心点赞最多的模块。它定义了一套统一的RTOS接口API，包括osKernelInitialize、osKernelStart、osThreadNew、osMutexNew、osMessageQueuePut这些，然后各个RTOS自己去做适配。Keil自带的RTX5原生支持这套API，FreeRTOS也有对应的CMSIS-RTOS2适配层，其他RTOS也能比较方便地接进来。

为什么这套抽象值得研究？因为在嵌入式项目里，切换RTOS的成本非常高。业务代码里到处是vTaskDelay、xSemaphoreTake这类FreeRTOS专属函数，真要换成RTX5或者其他RTOS，几乎是重写一遍业务层。如果从一开始就用CMSIS-RTOS2接口来写业务逻辑，底层RTOS只是实现细节，换不换都无所谓。这其实就是软件工程里依赖倒置原则的典型应用，CMSIS-RTOS2扮演的是那个“稳定抽象层”。

我在实际项目里体会到这套设计最大价值的地方，是测试阶段。单元测试和硬件无关的代码可以直接在模拟环境编译，不用在板子上跑，因为CMSIS-RTOS2接口是标准化的，可以手动实现一个mock版本。这个收益很多人没提过，但对我来说真真切切省了很多事。

2.5 CMSIS-Pack：容易被忽略的工程治理关键

很多开发者忽略了CMSIS-Pack。如果你接触过Keil的pack安装界面，或者用过STM32CubeMX生成工程时会自动下载一堆pack，那你其实已经在用CMSIS-Pack这套规范了。

CMSIS-Pack做的事情，是把一个芯片的所有元器件描述、启动文件、头文件、驱动库、Flash算法、调试描述，统一封装成一个.pack文件。IDE安装了pack之后，才能自动识别这个芯片，帮你配置工程、管理依赖、甚至决定怎么烧录。这套机制本质上是嵌入式世界里的“软件包管理器”，虽然比Linux生态的各类包管理工具粗糙不少，但在MCU生态里已经是事实标准。

从工程治理角度看，我特别建议项目组把CMSIS-Pack理解成“可复用的组件边界”。比如你要在多个项目之间复用某个中间件模块，最优雅的方式是把它打包成CMSIS-Pack格式，放到团队内部的私有pack服务器上。这样新项目只要装一次pack，就能像调用标准组件一样引用内部代码，而不是到处拷贝源码副本。

3. 工程治理：CMSIS-5源码教会我的代码组织方式

3.1 编译器差异是怎样被“藏”起来的

CMSIS-5最具价值的工程治理经验之一，就是它处理编译器差异的方式。Cortex-M开发常用Arm Compiler 5、Arm Compiler 6、GCC、IAR这几种工具链，它们对内联函数、弱符号、变量对齐、位段打包等语法的支持各有差异。CMSIS把这层差异用一个名字统一起来了。

随便看几个关键宏：

#if defined(__ICCARM__) #define __STATIC_INLINE static inline #elif defined(__ARMCC_VERSION) #define __STATIC_INLINE static __inline #else #define __STATIC_INLINE static inline #endif

类似的还有__WEAK、__ALIGNED、__PACKED、__NOINLINE、__USED等等。这套宏定义让同一种语法结构在三种编译器下都“长得一样”，上层代码完全不用关心当前用的是哪个工具链。我们在自己的项目里也学着搞了一套小型的编译器抽象头文件，虽然没CMSIS那么全，但已经解决了90%的移植问题。

另一个值得学的细节是启动文件的组织。CMSIS每个内核都配套了标准启动文件，比如startup_ARMCM4.S，里面定义了完整的向量表和默认中断处理函数。以GCC版本为例，它用.section .isr_vector、.weak HardFault_Handler这种写法，确保用户在C文件里定义了自己的HardFault_Handler时，链接器优先使用用户的强符号定义，而不是启动文件里的默认处理器。这种基于弱符号的默认实现机制，是嵌入式工程治理的经典操作。

3.2 中断处理与强符号弱符号机制

嵌入式工程里中断服务函数（ISR）是重名高发区。启动文件把每个中断都预设了一个默认的Handler函数，如果某个中断没用起来，程序会停在一个空循环或者跳转到一个公共错误处理函数。但关键问题是：用户在自己的业务代码里也定义了一个同名函数SysTick_Handler，链接器不会报“重复定义”错误，因为启动文件里的定义被标记为了weak符号。

我在一个项目里亲眼看到过有人把这个问题搞反了，顺着实现跟踪了很久，最后发现是因为自己写的函数名拼写错误，和启动文件里的弱符号不匹配，导致中断触发后跳进了默认的死循环。这个排查过程非常辛苦，所以我强烈建议工程团队对“所有中断函数名”建立一份清单，在新建工程时就让IDE帮你检索一遍。这个看似简单的弱符号机制，如果不能理解透彻，出问题时真的会让人绝望。

从源码设计角度看，CMSIS在GCC版本的头文件里大量使用__attribute__((used))、__attribute__((weak))这些属性，配合retain等链接选项，保证向量表段不被优化掉、弱定义可以被覆盖。这套做法在工程上至少有二两拨千斤的效果：既保证了“默认行为可用”，又给了开发者充分的自定义空间。

3.3 头文件分层组织的艺术

CMSIS-5的头文件组织方式我也非常喜欢。它没有把所有东西塞到一个大而全的头文件里，而是分成清晰层级：

• core_cm4.h：包含内核寄存器定义、NVIC/SysTick/SCB等操作方法
• system_ARMCM4.h：包含SystemInit和SystemCoreClock声明
• device.h：同芯片相关的寄存器定义和中断编号枚举
• arm_math.h：DSP相关API和数据结构

这个分层最大的好处是依赖可控。应用层代码如果只操作外设寄存器，只需要包含芯片设备头文件；如果要用内核功能，才需要包含CMSIS-Core的头文件；而DSP数学库又是独立的。不同模块之间没有无意义的互相依赖，编译速度也不会因为改了一个小结构体而全工程重编。

有一次我在实际项目中尝试把CMSIS-Core概成一个模块来做单元测试，发现因为头文件分层清晰，只需要提供一块模拟的寄存器地址空间，就能在PC上跑通绝大多数CMSIS-Core函数。这让我们的代码覆盖率测试轻松了不少。

4. 嵌入式项目选型：什么时候引入CMSIS，什么时候别硬上

4.1 先回答“我要不要用CMSIS”

很多人在选型时容易陷入“Cortex-M就一定得用CMSIS”的误区。CMSIS虽然好，但它也有自己的前提假设：需要你使用的工具链支持对应的启动文件和链接脚本，需要你把系统初始化方式统一到它的框架下。

我的判断维度一般有三个。

第一，多平台需求。如果你的产品生命周期很长，未来可能换芯片平台（比如从STM32F103换到GD32或AT32），CMSIS-Core和CMSIS-RTOS2这种标准接口就是你的保险单。因为寄存器操作、中断调用、RTOS API这些都统一了，换平台时你主要改的是外设驱动那一层。

第二，是否依赖DSP/NN算法。做音频、振动分析、传感器融合、轻量级AI检测这类项目的，CMSIS-DSP和CMSIS-NN基本是当前Cortex-M平台上性能和兼容性最平衡的方案。这时候你不用纠结，直接用。

第三，你的团队对标准框架的接受度。CMSIS的架构设计很优秀，但它是一套完整体系，不是库文件拷贝就能解决问题的。如果团队里缺乏对这套标准的理解，强行引入会带来额外的学习成本。我建议从CMSIS-Core开始，一点一点往工程里渗，而不是一步到位换全套。

4.2 裁剪与集成：推荐一个精简工程模板

真正常见的落地方式不是“全部引入”，而是“按需裁剪”。CMSIS本身设计得相对模块化，允许你只拿自己需要的那部分。以我的经验，一个实用工程的CMSIS相关目录结构可以是这样：

project/ ├── cmsis_core/ │ ├── include/ // core_cm4.h, cmsis_gcc.h, cmsis_compiler.h │ ├── system/ // system_ARMCM4.c, system_ARMCM4.h │ └── startup/ // startup_ARMCM4.S ├── cmsis_dsp/ │ ├── include/ // arm_math.h │ └── source/ // 按需裁剪的源文件 ├── cmsis_rtos2/ │ ├── include/ // cmsis_os2.h │ └── source/ // RTX5或者FreeRTOS适配层的源文件 ├── bsp/ │ ├── uart_driver.c │ ├── gpio_driver.c │ └── board_init.c ├── app/ │ ├── main.c │ ├── task_xxx.c │ └── algorithm_xxx.c └── Makefile / CMakeLists.txt

我再强调一遍：CMSIS-DSP和CMSIS-NN的源码尽量做裁剪，不要一股脑全部编译进来。很多新手在MDK里把整个DSP全加进去，结果编译时间暴涨，flash空间也紧张。正确的做法是先看你用到哪些函数，再从arm_math.h里找到对应的实现文件，只加入那一个源文件。这在CMSIS里非常成熟，兼容性没任何问题。

4.3 配合主流IDE与工具链的落地方式

不同工具链使用CMSIS的路子略有区别。

Keil MDK中，从包管理器安装Device Family Pack之后，CMSIS-Core、启动文件、系统初始化文件都会自动配置好，基本不需要手动处理。

STM32CubeIDE这类基于GCC的IDE，用STM32CubeMX生成工程时也会自动带上CMSIS，但要注意GCC版本的启动文件和MDK的启动文件不是同一个语法，不能相互替代。CMSIS官方源码里专门有GNU目录，对应的就是GCC版本的启动文件和链接脚本。

IAR环境虽然小众，但它对CMSIS的支持同样很完整，关键的区别在于编译器内置关键字不同，CMSIS在对应头文件里做了兼容。这里我在三个工具链之间移植时踩过一个坑，就是因为把IAR的启动文件直接拿到GCC工程里编译，报了几十个错误。CMSIS在这块处理得很人性化，它不要求你的启动文件是统一的，它按工具链分目录。

还有一点，我自己在GCC环境下强烈建议用CMake来组织CMSIS相关文件，因为CMake对文件依赖和宏定义有非常好的管理方式，可以很自然地声明ARM_MATH_CM4这类编译宏，而不是每个文件里手动加。团队协作时，CMake加上CMSIS，让换工具链的成本降到了最低。

5. 常见坑与排障记录实录

5.1 一调DSP库就HardFault，寄存器现场全乱

这是CMSIS-DSP最经典的问题。症状是：代码编译、链接全通过，程序跑起来也不一定秒挂，但一执行到arm_cfft_f32这类函数就触发HardFault，调试器一看PC指针飞到莫名其妙的地方。

排查顺序一般是这样：先确定是否定义了对应的ARM_MATH宏。如果是M4/M7内核却没有定义ARM_MATH_CM4/ARM_MATH_CM7，DSP库可能走了默认路径，虽然没有HardFault，但性能极差；而如果宏定义错误，比如M0+内核定义了ARM_MATH_CM4，一旦启用使用DSP指令或浮点单元的分支，那就是非法指令，直接HardFault。然后检查缓冲区对齐，CMSIS-DSP的矩阵、FFT相关结构体一般都需要16字节对齐，否则触发bus fault。最后检查中断优先级分组和BASEPRI是否有冲突。

5.2 换了工具链就编译不过，报错全是晦涩的汇编

这种情况多半是启动文件、链接脚本、CMSIS编译器适配头文件三者来源不一致。比如你用GCC工具链编译MDK工程，但工程里的startup文件还是armclang版本；或者直接用了错误的system_xxx.c文件。CMSIS对多工具链做了非常好的隔离，但前提是你要用对目录。

处理方式非常明确：直接去CMSIS官方仓库的对应设备支持目录里找正式发布的启动文件和system文件，不要在网上随便下载“看起来差不多”的版本。我自己的经验是，把CMSIS整个仓库版本固定下来，在工程里记录当前CMSIS的commit号，否则几年后回来看，某些函数行为对不上，排查起来让人崩溃。

5.3 中断不触发，或者误触发

中断问题最隐蔽。有一次同事跟我反馈某个外设中断不工作，我怀疑是中断服务函数名写错。因为CMSIS启动文件定义了弱符号的默认Handler，即使你函数名拼写错误，链接也不会报错，程序会跳进默认Handler里的死循环，从现象上看就像中断根本没发生一样。排查方法很简单：在默认Handler里打一个断点，看程序是否跳进来了。如果跳进来，说明中断确实触发了，只是你的服务函数名字没对上。

另一个容易踩的坑是中断优先级配置。M0/M0+内核的外设中断优先级只有一种可配置方式，而M3/M4/M7的NVIC支持优先级分组。CMSIS的NVIC_SetPriorityGrouping函数只能在M3及以上内核使用，如果用了M0+内核却调了这个函数，就会触发断言失败或者行为异常。写跨内核代码时一定要加编译条件判断，这是CMSIS使用中最容易被忽略的细节之一。

我把平时工作中常见的问题整理成一个速查表，方便大家直接对照：

5.4 调试CMSIS代码的几个小技巧

最后分享几个调试CMSIS相关的排障技巧。

第一，善用寄存器查看窗口。Core寄存器里LR寄存器非常重要，它保存了返回地址。看HardFault时先看LR，如果LR是0xFFFFFFF9，说明中断是在线程模式+主栈指针下发生的；如果是0xFFFFFFFD，说明是线程模式+进程栈指针。这个信息能极大缩小排查范围。

第二，把编译器优化等级暂时降到O0。CMSIS本身的宏和inline函数非常多，O2/O3优化后有些变量会被优化掉，调试时看到的寄存器状态可能跟源码对不上。先降优化，能大幅提升可读性。

第三，使用SCB->CFSR寄存器。Cortex-M的CFSR里有详细的故障状态位，比如非对齐访问、溢出状态等。这些状态位被置位后，即使CPU已经理不清当时的上下文了，这个寄存器仍然能告诉你大概是什么类型的错误。我在调试CMSIS-DSP非对齐问题时就是靠这个寄存器快速定位的。

结尾

这次深读CMSIS-5源码，我的心得体会是：它确实不是一套“必须全部用上”的库，但它是一套“值得认真研究”的架构范本。CMSIS-5把嵌入式开发中大量隐性约定给显性化了，统一了中断、系统节拍、编译器语法、DSP原语、RTOS接口、甚至软件打包规范。我在实际项目中已经把CMSIS-RTOS2的接口思维用到了自研的裸机调度器上，把DSP库的编译宏管理方式用到了自己的算法仓库里，甚至在CMake脚本里复刻了CMSIS的多工具链编译策略。

如果你也要在自己的项目里做CMSIS相关的选型和落地，我的建议是：先把CMSIS-Core完整吃透，因为它影响面最广；再按需引入DSP和RTOS2，不要贪多；最后用CMSIS-Pack的思想去治理你团队内部的代码复用。这套东西一旦理解到位，你不仅会写Cortex-M程序，还会把工程组织得有层次。真正有价值的东西，从来不是那几个宏调用，而是背后那一整套解决复杂问题的思路。