2. ARM Cortex-M架构基础
各位同学，欢迎来到第二章。上一章我们聊了ARM Cortex-M的架构基础，今天我们把目光转向具体的硬件平台——STM32。
说实话，我第一次接触STM32是在2010年左右，那时候还是STM32F1的天下。十几年过去了，ST的产品线已经铺得密密麻麻。很多初学者一上来就懵了：这么多型号，我该选哪个？
别急，这一章我带你捋清楚。
2.1 STM32系列产品线全景
STM32目前主要分为以下几个系列，每个系列都有明确的定位。我习惯把它们分成三档：
- 入门级：F0、G0、L0——适合简单控制、低功耗场景
- 主流级：F1、F3、G4、L4——覆盖大部分工业应用
- 高性能级：F2、F4、F7、H7——需要算力、DSP、图形处理
下面这张图是我自己整理的STM32产品线定位图，你一看就明白：
我的建议：初学者从F1或F4入手最稳妥。F1资料最多，F4性能够用且性价比高。别一上来就追H7，除非你真的需要双核和800MHz主频。
2.2 各系列核心差异速览
我把几个常用系列的关键参数整理成了一张表，方便你对比：
| 系列 | 内核 | 最高主频 | Flash | SRAM | 典型应用 |
|---|---|---|---|---|---|
| STM32F0 | Cortex-M0 | 48 MHz | 16-256 KB | 4-32 KB | 简单控制、替代8位机 |
| STM32F1 | Cortex-M3 | 72 MHz | 32-512 KB | 6-64 KB | 工业控制、电机驱动 |
| STM32F4 | Cortex-M4F | 168-180 MHz | 64-2048 KB | 32-384 KB | DSP、音频、图形 |
| STM32F7 | Cortex-M7 | 216 MHz | 256-2048 KB | 256-512 KB | 高性能计算、HMI |
| STM32H7 | Cortex-M7+M4 | 480+240 MHz | 512-2048 KB | 512-1024 KB | AI、视觉、双核应用 |
| STM32L4 | Cortex-M4F | 80 MHz | 64-512 KB | 32-256 KB | 低功耗、电池供电 |
看到这个表，你可能会问：F4和F7都是M4/M7内核，到底差在哪？
说白了，F7的M7内核有6级流水线和双精度浮点，F4的M4F只有3级流水线和单精度浮点。我在做音频处理项目时，同样的FFT算法，F7比F4快了将近一倍。但代价是功耗也上去了。
2.3 选型方法论：别盲目追高
选型这件事，我踩过不少坑。有一次给客户做手持设备，我选了F4，结果功耗压不下去，最后换成L4才搞定。所以选型一定要有方法。
我总结了一个四步选型法：
- 先定功耗预算——电池供电还是插电？电池供电优先L系列或U系列。
- 再算算力需求——有没有DSP运算？要不要浮点？有没有图形显示？
- 然后看外设接口——需要几个UART？要不要USB OTG？CAN接口够不够？
- 最后看封装和成本——板子空间大不大？BOM成本有没有上限？
选型口诀：功耗优先看L，性能优先看H，F1/F4最均衡，F0/G0省成本。
举个例子：你要做一个智能家居网关，需要Wi-Fi、以太网、本地语音识别。我建议选F4或F7系列，因为需要浮点运算做音频处理，同时外设接口要够多。如果只是做个温湿度传感器，F0或者G0就绰绰有余了。
2.4 STM32Cube生态系统概览
说到STM32开发，就绕不开ST的Cube生态系统。我记得2014年刚推出CubeMX时，很多人还不习惯。现在呢？没有Cube我都不想写代码了。
Cube生态主要由四部分组成：
| 工具 | 功能 | 我的使用频率 |
|---|---|---|
| STM32CubeMX | 图形化配置引脚、时钟、外设，生成初始化代码 | 每天必用 |
| STM32CubeIDE | 集成开发环境，基于Eclipse，内置CubeMX | 主力IDE |
| STM32CubeProgrammer | 烧录、调试、选项字节配置 | 每周用几次 |
| HAL库 | 硬件抽象层，统一API接口 | 项目必用 |
2.4.1 STM32CubeMX——配置神器
CubeMX最大的价值是什么？我告诉你：时钟树配置。
以前用标准库的时候，配时钟全靠看手册算分频系数，一不小心就配错了。现在CubeMX里拉一拉滑块，时钟树自动生成，还能帮你检查合法性。嗯，这个功能救了我无数次。
另外，引脚冲突检测也是亮点。你选了一个外设功能，如果引脚被占用了，它会立刻标红。我在一个多路ADC采集项目里，就是靠这个功能提前发现了引脚冲突，省了一版PCB。
2.4.2 STM32CubeIDE——一站式开发
CubeIDE是ST官方基于Eclipse打造的IDE。说实话，早期版本有点卡，但现在的版本已经相当成熟了。
它最大的优势是：CubeMX直接内嵌在IDE里。你在IDE里改完配置，点一下生成代码，工程自动更新。不用像以前那样，CubeMX生成完再手动导入到Keil或者IAR。
个人习惯：我一般用CubeIDE做新项目起步，配置完外设和时钟后，再根据团队需求导出到Keil或IAR。CubeIDE的调试器也很好用，支持实时变量查看和断点管理。
2.4.3 STM32CubeProgrammer——烧录与调试
这个工具很多人低估了。它不只是烧录固件，还能：
- 读写芯片内部Flash和OTP区域
- 配置选项字节（读保护、看门狗等）
- 通过UART、USB、SWD、JTAG等多种接口连接
- 支持命令行模式，适合自动化产线
我曾经在生产线上遇到过一批芯片读保护没清干净，导致烧录失败。用CubeProgrammer批量清除选项字节，几分钟就搞定了。
2.4.4 HAL库——统一API的利与弊
HAL库是ST主推的硬件抽象层库。它的优点是：API统一。你学会了F4的HAL库，换到F7、H7基本无缝切换。
但HAL库也有缺点：代码量大、效率偏低。比如一个简单的GPIO翻转，HAL库可能要调用好几层函数。如果你做的是对时序要求极高的应用，比如WS2812B灯带驱动，我建议还是用LL库或者直接操作寄存器。
避坑指南：我曾经在一个电机控制项目里用了HAL库的定时器PWM输出，结果发现中断响应延迟太大。后来换成LL库，延迟从3μs降到了0.5μs。所以，HAL库适合做原型和普通应用，高性能场景请用LL库或寄存器操作。
2.5 本章小结
这一章我们走马观花看了STM32的产品线、选型方法和Cube生态。说白了，选型就是做权衡——性能、功耗、成本、外设，四个维度拉满就是H7，省到底就是F0/G0。而Cube生态，就是ST帮你把开发流程标准化了，让你少踩坑。