[经验] 玩过ARM的应该了解一下 CMSIS 是什么？

CMSIS的更进一步就是MBed了。它在CMSIS基础上，将各种功能、外设封装起来，可以不用过多关心底层，不但使用更加方便，还可以兼顾运行效率，而且让程序在不同厂家芯片之间也容易移植。不过虽然看起来mbed有很多优点，但现在各厂家对mbed不太积极，支持不够。

很高深的一般接触不到，对于cortex-M的普通开发人员来说，感觉CMSIS的好处有：

1、统一的DSP库提供了内核级优化的高效浮点运算能力，提高涉及dsp运算的业务代码在不同cortex-M的可移植性。

2、CMSIS让不同厂商cortex-M MCU的启动流程和中断程序处理套路、底层程序文件结构趋于一致，减少开发人员学习成本。

如：NXP Kinetis和Stm32 CMSIS统一的地方举例：

1）相似的文件结构：startup_MKL25Z4.s + system_MKL25Z4.c/h  + MKL25Z4.h 《-》startup_stm32f4xx.s + system_stm32f4xx.c/h + stm32f4xx.h  ,startup_xxx*.s文件中描述相似的启动代码和中断向量表定义

2）统一的接口：SystemInit() 配置系统时钟， SystemCoreClockUpdate (void)获取系统时钟，

不过感觉CMSIS 的统一RTOS接口的想法不错，这个搞统一了，以后直接换rtos系统不改代码。

1. //CMSIS_OS创建队列API--------------------------------------------
2. osMessageQId osMessageCreate (osMessageQDef_t *queue_def, osThreadId thread_id)
3. {
4.   (void) thread_id;
5.   
6.   return xQueueCreate(queue_def->queue_sz, (uint32_t) sizeof(queue_def->item_sz));
7. }
8. typedef const struct os_messageQ_def  {
9.   uint32_t                queue_sz;    /*  number of elements in the queue 队列中包含项目数量 */
10.   uint32_t                 item_sz;    /*  size of an item 队列中每个项目所需的字节数 */
11.   //void                       *pool;    /*  memory array for messages */
12. } osMessageQDef_t;
13. //FreeRTOS创建队列API--------------------------------------------
14. xQueueHandle xQueueCreate (
15. unsigned portBASE_TYPE uxQueueLength, 队列中包含最大项目数量
16. unsigned portBASE_TYPE uxItemSize 队列中每个项目所需的字节数
17. );

那天还想尝试mbed，毕竟是ARM主推的RTOS，貌似还支持C++，个人感觉应该良好，网上搜了，说是构建还有不少坑，然后就搁置了

是的的确有很多好处，个人对驼峰命名法不是很友善。

然后虽然是不同的内核，比如KL25是M0+，还有后面的M4内核，基本上对于不同的编译器，启动文件基本也统一起来，包括中断向量表，中断服务程序的命名，看了代码，基本针对不同内核会封装到cm0 cm4 等等文件，从而也利于芯片厂商的开发，太深入的也还没有看到，对于这些内核的架构还不熟悉

小坑不少，大坑还算好，正常绕开问题也不大。其实ST的坑也很多啊

用C艹还是很酸爽的，加入体验计划里，届时届时，大佬求带带

标准化的能用就用，不能用就不用。
用之前先评估"标准化"的东西能不能满足项目中非标需求。
cmsis的dsp部分确实很好做标准化，cmsis-dsp只和cortex的指令集与算法相关，与具体chip的特定功能部件没有关系，这一点很像cortex的0xE0000000之上的那些功能部件，很容易基于cortex的构架统一起来。cmsis-svd其实就是个xml的布局描述文件规范，编译后产生的头文件和寄存器布局，也就是xxxx.h和system_xxxx.s等等现在也算是最简化的标配，iar和keil都提供svd编译器，基于eclipse的各家ide也差不多都能加载svd。cmsis-nn毕竟也是纯算法，构建于cmsis dsp之上比如一些matrix的处理，最大的问题是需要一个外部工具能导入pytorch，tensorflow等产生的参数模型，这个东西目前各个厂商看样子挺积极的，毕竟AI是当前最有价值的风口。cmsis-rtos与cmsis-driver最大的问题还是标准化与特化的问题，毕竟每个rtos提供的特性不一样，每个chip提供的功能部件不一样，抽象必然牺牲rtos和chip的个性，所以这两个的东西应用期望并不强烈。pack没啥太多具体内容，以上东西和文档,代码的打包文件，用winrar可以直接打开，项目中的资源应该会有自己的管理结构，不太会用到这个东西。

举个不恰当的类推，c++的对象系统提供的抽象是父类，但它同时提供了可以特化的子类，c++的模板系统提供了抽象模板，可也提供了模板特化。c标准够标准的但也提供"实现相关"这种特化机制给每个编译器厂，而cmsisrtos并没有特化机制所以，实际应用中压制很大。如果评估不充分，很可能就混合了标准cmsisrtos接口和非标部分的原生rtos接口，这又带来不可移植的移植性问题，麻烦就更大了。

举个例子，cmsis rtos的mutex在freertos上是建立在semaphore上的，但是cmsisrtos里的mutex不支持isr里面release，可是freertos的semaphore确有这个功能，然而cmsis rtos的semaphore又可以在isr里release，很奇异的实现。所以，为了在isr里面用mutex这个东西，我不得不抛弃cmsis rtos的mutex而用了cmsis rtos semaphore的01信号量来模拟。这很丑，也失去了语义，但是没办法，不用cmsis rtos semaphore，我就只能混合freertos的mutex（虽然它下面也是01信号量做的实现），代码的写法上也就是引入两套接口了。
软件工业的标准化不像电子工业的标准化，很多时候理想是办不到的。

天天搞cortex-m cmsisi感觉就是个最底层的IT苦工。

嗯嗯，IT谈不上，摆正心态才对

据我所知CSMIS是ARM推得一种硬件无关的抽象接口，方便应用开发更加的快速把

以前搞开发，总是很关心CMSIS，花了很多时间理解。

不过最近st的arm使用了hal库编程，hal库更抽象，关注cmsis就少了很多。

我觉得hal是编程的未来，可以提高编程的效率。让我们把关注点放在真正的编程上面。

对，您说的是没错的，CMSIS实际是arm提供给厂商的，当然开发者也可以遵守这个接口规范，就像 10楼free叔说的一样，HAL当然又是另一回事了，是ST厂商又封装了一层，开发者只需要关注接口即可，不知道这样理解对不对，