目录
（3）为什么ST不直接在CMSIS-Driver上封装HAL库，而是反过来？
二、为什么STM32采用哈弗架构，而PC却采用冯诺依曼架构呢？
（2）STM32的存储器映象：统一编址的小缺点与常见地址分段
一、CMSIS与HAL库
在STM32的学习中，我们常常会在目录中看到CMSIS的字眼，但它表达了什么意思，与ARM、ST又有什么样的关系？
（1）CMSIS标准与历史遗留问题：标准库的诞生
CMSIS的全称是：Cortex‑Microcontroller Software Interface Standard ，即**Cortex‑M 微控制器软件接口标准。**是ARM公式推出的一套软件规范，目的是将自己的CortexM内核方便的交给ST等MCU厂商使用、并让各MCU具备一定跨厂商平台的能力。
CMSIS在现在分为CMSIS-Core和CMSIS-Device+CMSIS-Driver，分别规范着内核CPU、MCU板载外设的定义与操作。
其中CMSIS-Core是ARM写好的关于内核CPU的描述信息+操作函数集合，MCU厂商只能调用接口，而不允许修改。而ARM并不知道厂商拿到自己的CPU后会做成什么结构的MCU，所以CMSIS-Device是由ARM规范，ST等公司维护的MCU板载外设的描述信息。最后，CMSIS-Driver同样是ARM规范接口，MCU厂商维护的一套寄存器操作函数。
这里的Core既包含了信息与接口定义，也包含了实现。因为全部都由ARM自己实现，所以打包成一个文件夹CMSIS-Core了。
但是由于历史发展问题，ARM在早期并没有提供对于MCU的CMSIS，而仅仅只提供了CPU内核的CMSIS，于是各个厂商（如ST、NXP）不得不写出自己的外设库函数，比如ST公司就在这个背景下写出了标准库SPL，成为一代经典。
（2）HAL库的发展背景
随着时间发展，ST公司推出的MCU越来越多，产线越来越大，标准库各自为战的维护成本较高，毕竟每一款MCU的寄存器都不同，标准库内部的寄存器操作也需要有所改变。更重要的是：标准库使得不同系列（F1、F4、F7等）的MCU函数接口也不同，用户更改起来太繁琐了。
于是ST开始转向HAL库，HAL 库最大的特点就是统一了不同 STM32 系列的 API 接口 。（让让ST公司的所有基于CortexM开发的MCU只有一套库函数）同样是 GPIO 初始化、串口发送，F1、F4、H7 等不同芯片的函数名、参数形式基本保持一致。开发者在更换芯片型号时，只需要修改底层硬件配置，上层业务代码可以大量复用，极大降低了跨系列移植的成本。
最终，HAL库就发展成了如下状态，其中还提出了两个问题，下面我们逐一解答。
（3）为什么ST不直接在CMSIS-Driver上封装HAL库，而是反过来？
同样是历史原因，CMSIS-Driver的提出时间甚至比HAL还晚，当它提出时，ST公司已经将HAL库写好了。
不过我个人觉得，假设CMSIS-Driver先被推出，ST公司还是有很大概率绕过它自己写一套HAL库的，毕竟CMSIS-Driver为了兼容市面上各种MCU，做出了不小的牺牲：
函数接口设计十分复杂，多处使用回调函数、状态机等高级语法，函数调用层级极为复杂，不利于裸机场景追求极致性能。
而 HAL 库面向 ST 自家芯片，内部可以更贴近寄存器操作，减少多层抽象跳转，兼顾易用性与执行效率。
（4）胶水层有什么用？
因为在ARM提出CMSIS-Driver后，很多ARM官方组件（中间件，如USB协议等）都是基于该标准写的，但是各厂商都已经实现了自己的HAL库，所以只能在自己的HAL库加一层外壳，在函数内部将参数、返回值等修改成符合CMSIS-Driver标准的，用于适配。
- 普通裸机开发：几乎用不到胶水层，我们写
HAL_GPIO_WritePin、HAL_UART_Transmit，直接调用 HAL 库，不经过胶水层。- 当使用 RTOS、第三方中间件时：这些软件只识别 CMSIS‑Driver 这套标准化接口，此时胶水层就起到桥梁作用，把 HAL 库的硬件能力包装成标准接口供中间件调用。
所以胶水层不是给我们写业务代码用的，是给软件组件做适配用的。
关于CMSIS各种文件的层级结构，可以参考我之前在学习标准库时候创建keil工程所写的笔记，更为详细：keil如何创建一个工程_keil新建工程-CSDN博客
https://blog.csdn.net/2303_79336820/article/details/147227353
二、为什么STM32采用哈弗架构，而PC却采用冯诺依曼架构呢？
（1）哈弗架构、冯诺依曼架构基本定义
在这里我们先给出结论：哈弗架构中I/D线分离，能够降低流水线气泡，从而提高运行实时性（这里的实时性强调的是确定性，而不是足够快）
冯・诺依曼架构：
指令、数据共用同一套总线、同一个存储器地址空间。CPU 取指令和读写数据，要争抢同一条总线，无法并行访问。
哈佛架构：
指令、数据拥有互相独立的两套总线，指令通路、数据通路物理分开，可以同时取指令 + 读写数据。
（2）从指令流水线角度分析性能差异
由于计算机组成原理的设计，一条指令运行需要按照以下周期顺序：
即取指周期--->间指周期--->执行周期--->中断周期。
在冯诺依曼架构中，指令和数据是通过一条线传输的，如果你的执行周期刚好是拷贝数据，那么本应该流水线同步进行的取指会受到一定推迟，产生气泡。然后等到该拷贝执行周期结束后，才能取指，执行其余操作。这意味着：冯诺依曼架构在面临大量数据修改、拷贝的场景，很容易产生流水线气泡，降低整体的运行效率。
而哈弗架构中，指令和数据是分开的两条路径，即使当前的执行周期是数据拷贝相关的工作，指令仍然能正常加入到CPU中，从而流水线的执行CPU中没有使用到的硬件单元，如ALU等。从而减少流水线气泡出现的可能，提高整体运行效率。
而这一点点的提升，在电机控制FOC等场景中极为关键，能大大提高实时性，所以STM32这种强调实时的MCU就会采用哈弗架构了。
不过在现代计算机中，通常会结合二者的优势，即在靠近CPU设计缓存，使用哈弗架构分为两条路径，减少气泡；而在远离CPU的内存处使用冯诺依曼架构，让操作系统等复杂软件工作在同一地址空间内，更加方便修改。
（3）ST官方参考手册中的结构图
这一点，对于我们上面分析流水线气泡，有了更深入的理解：
哈弗架构中对于气泡的提升，仅仅限于常量，而变量仍然会存在于内存中，从system-bus路径走，容易与其他外设访存冲突，形成冯诺依曼中同样的气泡问题。不过单片机场景通常是固定的代码，Flash更为频繁。所以哈弗架构已经一定程度上提高了实时性。
三、统一编址：CPU只看得到存储空间，无需分辨外设
（1）统一编址与独立编址
刚刚我们讨论的是哈弗架构中数据、指令流转过程中的性能问题，但各个外设、内存的数据是怎么被CPU访问到的呢？难道CPU需要有识别不同外设的能力吗？
其实CPU才不管这些，在CPU的视角看：所有的外设、内存都只是一个存储空间。我CPU只是发送指令，告诉总线去哪个地址访问数据，至于区分动作则是总线矩阵来实现的。
上面这种编址方式称为存储器统一编址（存储器映射 I/O）；另一种叫做独立编址（I/O 映射 I/O），典型为 X86 架构。CPU 拥有两套完全隔离的地址空间，访问内存、访问外设端口，需要使用两套不同的访问指令。
（2）STM32的存储器映象：统一编址的小缺点与常见地址分段
STM32采用的就是统一编址模式，在数据手册中会有如下图片：
很明显的看到，ST将外设、内存、Flash等不同的硬件组件分别映射到了不同的地址范围内。完美的将32位CPU的4GB空间划分成block了。
但统一编址也带来了一个缺点：
外设的地址空间会占用一部分地址空间，会挤占可供内存使用的地址范围。不过单片机场景内存需求不大，这个影响可以忽略。 独立编址最早诞生于古老的 16 位 x86 处理器，当时 CPU 总内存地址仅有 1MB，地址资源十分宝贵，所以把外设放到完全独立的 IO 端口空间，避免抢占有限的内存地址。
到 32 位 PC 时代，X86 变成独立编址 + MMIO 统一编址两套机制共存。逐渐延续至今。