1. Cortex-M家族概览：从M0到M7，选型其实没那么难
大家好，欢迎来到这门课的第一章。
说实话，Cortex-M系列处理器，现在已经成了嵌入式开发者的“标配”。不管你是做智能家居、工业控制，还是可穿戴设备，几乎都能看到它的影子。我个人最早接触的是ARM7TDMI，那时候还得自己配中断控制器，挺麻烦的。后来Cortex-M3一出来，我第一反应是——嗯，这才对嘛。
1.1 发展历程：从ARM7到Cortex-M的进化
ARM在2004年推出了Cortex-M3，这是第一款专门为微控制器设计的处理器内核。在此之前，ARM7和ARM9虽然也能做MCU，但它们的设计思路更偏向应用处理器，中断响应慢、功耗高、代码密度低。
M3的出现，解决了几个核心痛点：
- 中断延迟大幅降低——硬件自动压栈，不用软件干预
- 位带操作——直接操作单个比特，省指令
- Thumb-2指令集——混合16/32位指令，代码密度提升30%
之后ARM又陆续推出了M0（2009）、M4（2010）、M7（2014）和M33（2016）。每一代都在补齐上一代的短板。比如M0主打超低功耗和低成本，M4加了DSP和浮点，M7把性能拉到接近应用处理器的水平，M33则引入了TrustZone安全扩展。
核心观点：Cortex-M系列不是简单的“性能堆叠”，而是针对不同应用场景做了差异化设计。选型时，不是越贵越好，而是越“匹配”越好。
1.2 产品线对比：M0/M3/M4/M7/M33，到底差在哪？
很多初学者会问：M0和M3差多少？M4比M3多了什么？M7是不是比M4快一倍？
我直接说结论：不是简单的线性关系。下面这张表，是我自己整理的核心差异，你收藏好，以后选型直接翻出来看。
| 特性 | M0 | M3 | M4 | M7 | M33 |
|---|---|---|---|---|---|
| 架构版本 | ARMv6-M | ARMv7-M | ARMv7E-M | ARMv7E-M | ARMv8-M |
| 流水线级数 | 3级 | 3级 | 3级 | 6级（双发射） | 3级 |
| DSP扩展 | 无 | 无 | 有 | 有 | 有 |
| 浮点单元 | 无 | 无 | 单精度 | 单/双精度 | 单精度（可选） |
| 中断延迟 | 16周期 | 12周期 | 12周期 | 12周期 | 12周期 |
| TrustZone | 无 | 无 | 无 | 无 | 有 |
| 典型主频 | 48MHz | 120MHz | 180MHz | 400MHz+ | 200MHz |
| DMIPS/MHz | 0.84 | 1.25 | 1.25 | 2.14 | 1.25 |
我的建议：如果项目对成本敏感、功能简单，选M0；需要复杂控制逻辑和中断处理，M3是性价比之王；要做音频处理或电机控制，M4的DSP和FPU能省你大量开发时间；M7适合高性能计算，比如无人机飞控；M33适合需要安全隔离的IoT设备。
1.3 内核架构总览：一张图看懂Cortex-M内部
不管哪个型号，Cortex-M的内核架构都有一些共性。我画了一张结构图，帮你快速建立整体认知。
从上图可以看出，Cortex-M的内核由几个关键模块组成：
- 处理器核心：负责指令的取指、译码和执行，是大脑
- NVIC：中断控制的核心，支持嵌套中断和优先级管理
- 总线接口：连接Flash、SRAM、外设等，M3以上支持AHB-Lite
- 调试系统：通过SWD或JTAG接口进行调试和跟踪
- MPU：可选，用于内存访问权限控制，RTOS常用
- FPU：M4/M7/M33可选，加速浮点运算
- SysTick：24位系统定时器，RTOS的心跳
我曾经踩过的坑：刚开始用M4时，我以为FPU是默认开启的。结果跑浮点运算时发现速度奇慢，查了半天才发现FPU的寄存器没使能。记住，FPU默认是关闭的，需要在代码里手动打开协处理器访问权限。
1.4 选型指南：别只看主频，这些参数更重要
很多工程师选型时，第一反应就是看主频。其实这是个误区。我见过不少项目，主频很高，但实际性能反而上不去。为什么？因为瓶颈往往在内存带宽和中断响应上。
我个人总结了一套选型流程，分享给你：
- 先看中断需求——需要多少个中断源？优先级够不够？M0只有32个中断，M3以上有240个
- 再看计算需求——有没有DSP算法？要不要浮点？有的话直接上M4或M7
- 然后看功耗预算——电池供电？M0的功耗可以做到uA级别
- 最后看成本——M0芯片可以做到1美元以下，M7可能要5美元以上
一句话总结：M0做控制，M3做逻辑，M4做运算，M7做高性能，M33做安全。选型不是选最强的，而是选最合适的。
1.5 寄存器编程的底层逻辑
这门课的核心是寄存器编程。你可能会问：现在HAL库这么成熟，为什么还要学寄存器？
我的回答是：HAL库是别人帮你封装的，寄存器才是硬件的真实面目。遇到Bug时，不懂寄存器你连问题在哪都找不到。我在项目中遇到过好几次，HAL库的某个函数在特定条件下会死锁，最后都是靠直接操作寄存器绕过去的。
寄存器编程的本质，就是通过读写特定地址的内存来配置硬件。比如：
// 使能GPIOA时钟（STM32F4为例）
// RCC_AHB1ENR寄存器的地址是0x40023830
// 第0位置1表示使能GPIOA时钟
*(volatile uint32_t *)0x40023830 |= (1 << 0);
// 配置PA5为输出模式
// GPIOA_MODER寄存器的地址是0x40020000
// 第10-11位控制PA5，设为01表示输出
*(volatile uint32_t *)0x40020000 |= (1 << 10);
*(volatile uint32_t *)0x40020000 &= ~(1 << 11);
// 设置PA5输出高电平
// GPIOA_ODR寄存器的地址是0x40020014
// 第5位置1
*(volatile uint32_t *)0x40020014 |= (1 << 5);
这段代码看起来简单，但背后涉及的知识点不少：
- 为什么地址是0x40023830？——这是芯片厂商定义的寄存器映射
- 为什么用volatile？——防止编译器优化掉对硬件寄存器的访问
- 为什么用位操作？——只修改目标位，不影响其他位
我的习惯：写寄存器代码时，我会先查芯片参考手册，确认寄存器地址和位定义。然后写一个头文件，把所有寄存器地址用宏定义好。这样代码可读性高，也方便移植。