零硬件入门STM32：基于QEMU的纯软件仿真环境搭建与外设实战

1. 为什么我要把 STM32 入门做成纯软件版本

刚接触 STM32 的人，十有八九会被同一个问题卡住：板子还没到，或者手头预算有限，又或者只是想在通勤路上先熟悉一下外设编程的思路，结果打开教程一看，全是"先烧录到开发板""用串口助手看输出""拿示波器测波形"。这套流程当然没问题，但它有一个隐含前提——你得先有一块能用的板子，还得有下载器、串口模块、若干杜邦线，最好再配个逻辑分析仪。对刚入门的人来说，光是凑齐这套东西就够劝退了。

我当初带过几个刚入门的同学，他们的共同痛点是：理论看懂了，寄存器也背了，但一到"让 LED 闪起来"这一步就卡住，因为板子还在路上。等板子到了，热情已经凉了一半。后来我就想，能不能把整个入门过程做成"纯软件"版本——不买板子，不接任何硬件，只靠一台电脑，把 GPIO、定时器、串口、ADC、SPI、I2C 这些外设一个个跑通，看到真实的运行结果。

这个想法的核心，是用仿真器替代真实硬件。STM32 的仿真方案里，最成熟、最贴近真实运行效果的是基于 QEMU 的仿真环境，配合 GCC 工具链和 GDB 调试器，可以做到：代码编译成真实的 ARM 指令，在仿真 CPU 上执行，外设寄存器按真实行为响应，串口输出能打印到终端，GPIO 电平变化能被观测到。换句话说，除了没有真实的物理引脚和电压，软件层面的行为跟真板子几乎一致。

这套方案能解决什么问题？第一，零成本入门，不需要买任何硬件；第二，随时可复现，环境搭好后，换台电脑也能快速重建；第三，调试更透明，真板子上你只能看现象，仿真里你能直接看寄存器、看内存、单步跟踪每一条指令；第四，适合教学和自学，因为所有外设都能"一个个跑通"，不依赖硬件焊接和接线。

适合谁来参考？如果你是刚学 STM32 的学生、想转嵌入式的软件工程师、预算有限的自学者，或者需要给学生准备实验环境的老师，这套纯软件方案都能直接用。下面我会把整个搭建过程、外设跑通的实操步骤、以及我踩过的坑，完整地讲一遍。

2. 纯软件仿真方案的整体设计与选型思路

2.1 为什么选 QEMU 而不是其他仿真方式

市面上能"模拟"STM32 的方式其实有好几种，我逐一试过，最后锁定 QEMU，理由如下。

第一种是纯软件模拟库，比如某些用 C 写的寄存器级模拟器。这类方案的问题是：它模拟的是"寄存器读写的结果"，而不是真实的 CPU 执行。你写的代码并没有真正编译成 ARM 指令去跑，而是被解释执行。这会导致一个致命问题——中断、时序、流水线相关的行为跟真实芯片差异很大，学到的知识容易"跑偏"。

第二种是厂商提供的在线仿真或图形化配置工具。这类工具通常只能验证配置是否正确，不能真正运行你的完整程序，更没法做 GDB 级别的调试。它适合验证引脚复用，但不适合"跑通外设"。

第三种是基于 QEMU 的仿真。QEMU 本身是一个功能完整的系统级模拟器，它模拟的是真实的 ARM Cortex-M 内核，你的代码被 GCC 编译成真正的 Thumb 指令，在 QEMU 的 CPU 模型上执行。外设方面，QEMU 对 STM32 的 USART、GPIO、定时器、ADC 等都有模型，寄存器行为按参考手册实现。最关键的是，它能配合 GDB 做源码级调试，能打印串口输出，能观测内存和外设寄存器。

我实测下来，QEMU 方案的"真实度"是最高的。你写的启动文件、链接脚本、中断向量表，全都是真实生效的，不是被某个库"假装"处理掉的。这一点对入门者特别重要，因为入门阶段最该建立的就是"代码到硬件"的完整链路认知。

2.2 工具链的组成与各自职责

整套环境由四部分组成，我先把它们的分工讲清楚，后面搭建时就不会迷糊。

这里要特别说明一点：交叉编译工具链和调试器必须是同一套，也就是都用 arm-none-eabi 前缀的版本。我见过有人用系统自带的 gdb 去连 QEMU，结果连不上，因为架构不匹配。这个坑后面会细说。

2.3 目录结构的设计考量

为了让后续扩展外设时不出乱子，我建议一开始就把目录结构定好。我的习惯是这样：

stm32-sim/ ├── src/ # 源代码 │ ├── main.c │ ├── startup.c # 启动文件 │ └── peripheral/ # 各外设驱动 ├── inc/ # 头文件 ├── ld/ # 链接脚本 ├── build/ # 编译输出 └── Makefile

这样分的好处是：启动文件、链接脚本、外设驱动各自独立，换芯片型号时只需要改链接脚本和启动文件，业务代码基本不动。入门阶段可能觉得麻烦，但等你跑到第五个外设时，就会感谢自己当初分了目录。

3. 环境搭建的完整实操步骤

3.1 安装交叉编译工具链

Linux 下最省事，直接包管理器装：

sudo apt install gcc-arm-none-eabi gdb-arm-none-eabi

Windows 下我推荐用 MSYS2 或者直接下载 ARM 官方的 GNU Toolchain 压缩包，解压后把bin目录加到 PATH。macOS 用 Homebrew：

brew install arm-none-eabi-gcc arm-none-eabi-gdb

装完后验证一下：

arm-none-eabi-gcc --version arm-none-eabi-gdb --version

两条命令都能输出版本号，说明工具链就位。这里有个细节：版本不要太老，我建议 GCC 10 以上，因为老版本对 Cortex-M 的新指令支持不全，编译某些启动文件时会报错。

3.2 获取并编译带 STM32 支持的 QEMU

系统自带的 QEMU 通常不带 STM32 机器模型，需要自己编译。步骤不复杂，但有几个关键配置项不能漏：

git clone https://github.com/qemu/qemu.git cd qemu ./configure --target-list=arm-softmmu --disable-werror make -j$(nproc)

--target-list=arm-softmmu是关键，只编译 ARM 系统模拟，省时间。--disable-werror是为了避免新版编译器把警告当错误导致编译中断。编译完成后，build/arm-softmmu/qemu-system-arm就是我们要的可执行文件。

验证是否支持 STM32：

./qemu-system-arm -M help | grep stm32

如果能看到stm32vldiscovery、netduino2之类的机器名，说明支持到位。我一般用stm32vldiscovery，因为它对应 STM32F100，外设模型比较全，适合入门。

3.3 链接脚本与启动文件的关键配置

这是整个搭建里最容易出错的地方。链接脚本决定了代码放在 Flash 的哪个地址、数据放在 RAM 的哪个地址。STM32F100 的 Flash 起始地址是0x08000000，RAM 起始是0x20000000。一个最小可用的链接脚本长这样：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 8K } SECTIONS { .text : { KEEP(*(.isr_vector)) *(.text*) *(.rodata*) } > FLASH .data : { *(.data*) } > RAM AT> FLASH .bss : { *(.bss*) } > RAM }

KEEP(*(.isr_vector))这一行必须放在最前面，否则中断向量表可能被链接器优化掉，导致中断进不去。这个坑我踩过，现象是程序能跑，但一开定时器中断就死机，查了半天才发现是向量表被丢了。

启动文件里最关键的是向量表的定义和复位处理函数。向量表第一项是初始栈指针，第二项是复位向量。复位处理函数里要先初始化.data段（从 Flash 拷贝到 RAM），再清零.bss段，最后调用main。这三步少一步，全局变量就会是随机值。

3.4 编译与运行的第一条命令

把上面几块拼起来，一个最小的 Makefile 核心部分是这样：

CC = arm-none-eabi-gcc CFLAGS = -mcpu=cortex-m3 -mthumb -O0 -g -ffreestanding -nostdlib LDFLAGS = -T ld/stm32f100.ld -nostartfiles all: build/firmware.elf build/firmware.elf: src/main.c src/startup.c $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

注意-O0 -g，入门阶段一定要关优化、开调试信息，否则单步调试时行号会乱跳。-ffreestanding -nostdlib是因为我们不用标准库的启动流程，自己控制一切。

编译出firmware.elf后，用 QEMU 跑起来：

qemu-system-arm -M stm32vldiscovery -kernel build/firmware.elf -nographic

-nographic让串口输出直接打到终端。如果程序里往 USART 写了字符，这里就能看到。

4. 外设逐个跑通的实操记录

4.1 GPIO：让虚拟 LED 闪起来

GPIO 是最适合第一个跑的外设，因为它直观。在仿真环境里，我们没有真实的 LED，但可以观测 GPIO 寄存器的输出位变化。STM32F100 的 GPIOC 时钟挂在 APB2 上，先使能时钟：

RCC->APB2ENR |= RCC_APB2ENR_IOPCEN;

然后配置 PC13 为推挽输出，50MHz：

GPIOC->CRH &= ~(0xF << 20); GPIOC->CRH |= (0x3 << 20);

翻转电平就是操作 BSRR 寄存器：

GPIOC->BSRR = GPIO_BSRR_BS13; // 置高 GPIOC->BSRR = GPIO_BSRR_BR13; // 置低

在 GDB 里连上 QEMU 后，可以下断点看GPIOC->ODR的值，每次翻转都能看到第 13 位在变。这就是"虚拟 LED 闪烁"的观测方式。我实测下来，这个流程跟真板子完全一致，唯一区别是你得用调试器看寄存器，而不是用眼睛看灯。

注意：BSRR 是原子操作，比直接读改写 ODR 安全。入门时养成用 BSRR 的习惯，以后写中断里的 GPIO 操作就不会有竞态问题。

4.2 定时器：精确延时与中断

GPIO 跑通后，下一步是定时器。用 TIM2 做一个 1Hz 的中断，让中断里翻转 GPIO。配置步骤：使能 TIM2 时钟、设置预分频和自动重装载值、使能更新中断、配置 NVIC、启动定时器。

预分频和重装载值的计算是重点。假设系统时钟 24MHz，想要 1Hz 中断：

• 预分频设为 24000-1，得到 1kHz 计数频率
• 重装载值设为 1000-1，得到 1Hz 更新事件

TIM2->PSC = 24000 - 1; TIM2->ARR = 1000 - 1; TIM2->DIER |= TIM_DIER_UIE; TIM2->CR1 |= TIM_CR1_CEN;

NVIC 那边要开 TIM2 中断：

NVIC_EnableIRQ(TIM2_IRQn);

中断服务函数名必须跟启动文件里的向量表名字一致，否则链接不上。这个坑很隐蔽，编译不报错，但中断永远不进。我建议每次加中断，都去启动文件里核对一遍函数名。

在 QEMU 里跑起来后，GDB 里给中断服务函数下断点，能看到它每秒命中一次。这就验证了定时器和中断链路都是通的。

4.3 串口：把 printf 重定向到终端

串口是仿真环境里最有价值的外设，因为它能输出信息。配置 USART1：使能时钟、设置波特率、使能收发、配置 GPIO 复用。

波特率计算：假设系统时钟 24MHz，想要 115200，则BRR = 24000000 / 115200 ≈ 208.33，取整后是 208，即0xD0。

USART1->BRR = 0xD0; USART1->CR1 |= USART_CR1_UE | USART_CR1_TE;

发送一个字符就是等 TXE 标志，然后写 DR：

while (!(USART1->SR & USART_SR_TXE)); USART1->DR = ch;

把printf重定向到串口，需要实现_write或者直接写一个uart_puts。我习惯自己写uart_puts，因为不依赖标准库，编译出来更小。

QEMU 启动时加-nographic，串口输出就直接显示在终端。第一次看到自己写的字符串从"虚拟串口"打出来，那种感觉跟真板子一模一样。

4.4 ADC 与 SPI：进阶外设的仿真验证

ADC 在 QEMU 里的模型相对简单，它能响应寄存器配置，但输入电压需要手动注入。我一般用 ADC 的规则通道，配置好采样时间后启动转换，读 DR 寄存器。仿真里读到的值可能是固定的，但整个配置流程和寄存器操作是真实的，这对学习 ADC 编程已经足够。

SPI 稍微复杂一点，因为它是主从通信。仿真里没有真实从设备，但可以验证主机端的时序配置：时钟极性、相位、波特率分频、数据帧格式。我通常用 SPI 配合一个软件模拟的从设备响应，来验证发送和接收流程。这一步的意义在于，把 SPI 的寄存器配置和收发逻辑跑通，等真板子到手，接上真实从设备就能直接用。

5. 常见问题与排查技巧实录

5.1 程序跑飞或直接 HardFault

这是最常见的问题。排查顺序我总结成一张表：

HardFault 的排查有个技巧：在 HardFault 处理函数里读LR寄存器的值，能判断是从哪个栈进的异常。再用 GDB 看PC指向的地址，反汇编一下，基本就能定位到出问题的指令。

5.2 GDB 连不上 QEMU

这个问题的原因通常有三个：QEMU 启动时没加-s -S参数、GDB 用的不是 arm-none-eabi 版本、端口被占用。正确启动方式是：

qemu-system-arm -M stm32vldiscovery -kernel firmware.elf -nographic -s -S

-s表示开 GDB 服务在 1234 端口，-S表示启动后暂停等 GDB 连接。然后另开终端：

arm-none-eabi-gdb build/firmware.elf (gdb) target remote localhost:1234

如果连不上，先telnet localhost 1234看端口通不通。我遇到过端口被别的进程占用，换-gdb tcp::1235指定其他端口就好。

5.3 串口输出乱码或没输出

乱码一般是波特率不对。检查BRR的计算是否用了正确的系统时钟。仿真里系统时钟默认可能是 8MHz 而不是 24MHz，这个要确认清楚。没输出则可能是 USART 的TE位没使能，或者 GPIO 复用没配对。我建议在发送前先读一次USART1->SR，确认TXE和TC标志正常。

提示：QEMU 的串口输出是行缓冲的，如果你只发一个字符不换行，可能看不到。加个\n或者手动 flush 一下。

5.4 外设寄存器读写无效

有时候你写了寄存器，读回来还是旧值。这通常是因为时钟没使能。STM32 的外设时钟默认是关的，不使能时钟，寄存器写入会被忽略。这个坑我踩过不止一次，后来养成习惯：操作任何外设前，先确认对应的 RCC 使能位已经置上。

6. 我在这套方案里踩过的坑和总结的技巧

第一个坑是启动文件里的栈顶地址。向量表第一项必须是 RAM 末尾的地址，我一开始写成了 RAM 起始地址，结果一压栈就覆盖了代码区，程序行为完全乱套。正确写法是0x20000000 + 8K，也就是 RAM 的末尾。

第二个坑是链接脚本的AT>语法。.data段既要放在 RAM 的运行时地址，又要从 Flash 加载初始值，必须用> RAM AT> FLASH。我漏了AT>，结果.data的初始值没被加载，全局变量全是零。

第三个坑是GDB 的load命令。在 QEMU 里其实不需要load，因为-kernel已经把 elf 加载进去了。我一开始习惯性敲load，结果把代码又加载了一遍，地址冲突。后来改成直接target remote然后continue就好。

第四个坑是中断优先级。仿真里 NVIC 的行为跟真实芯片一致，如果两个中断优先级设成一样，抢占行为可能跟预期不同。我建议入门阶段先把所有中断优先级设成不同值，避免调试时分心。

这套纯软件方案我用了挺长时间，最大的体会是：它把"硬件门槛"和"编程门槛"解耦了。你不需要先搞定焊接、接线、供电，就能把 STM32 的编程模型、寄存器操作、中断机制、外设配置全部跑一遍。等真板子到手，你只需要把代码烧进去，剩下的就是验证物理现象，而不是从零开始摸索。

如果你也想试试，我建议从 GPIO 开始，然后定时器，然后串口，最后 ADC 和 SPI。每跑通一个，就在 GDB 里把相关寄存器都看一遍，理解每个位的含义。这个习惯坚持下来，你对 STM32 的理解会比只看教程深得多。后续还可以把这套环境扩展成自动化测试，比如用脚本跑一遍所有外设，检查输出是否符合预期，那就更接近工程实践了。