1. 从一个看似简单的问题说起
1.1 每个写过 C 语言的人都写过那个main
你第一次打开 Dev-C++ 或者 Visual Studio，敲下那几行代码的时候，大概率写的是这个：
#include <stdio.h> int main() { printf("Hello World\n"); return 0; }编译，运行，控制台弹出一个黑框，打印一行字，然后程序退出。整个过程干净利落，你甚至不需要知道main是谁调用的、什么时候调用的、调用之前发生了什么。你只知道：程序从main开始执行。
这个认知在你写 PC 程序的时候完全够用。你写一个计算器、写一个学生成绩管理系统、写一个贪吃蛇，main就是你的起点，操作系统帮你把一切准备工作都做好了——内存分配好了，堆栈建好了，C 运行时库初始化好了，你只管在main里写业务逻辑就行。
但当你第一次拿到一块 STM32 开发板，打开 Keil 或者 STM32CubeIDE，新建一个工程，你会发现事情变得不太一样了。你同样写了一个main函数，但在这个main之前，有一大堆你从来没见过的代码：启动文件、中断向量表、系统初始化、时钟配置……这些东西在你写 PC 程序的时候根本不存在，或者说，它们被操作系统和编译器隐藏起来了。
这篇文章要聊的就是这个问题：从 C 语言的main到 STM32 的main，你的代码到底经历了什么？中间那些“消失”的环节，究竟是谁在干活？
1.2 这篇文章适合谁看
如果你正在从 PC 端 C 语言转向单片机开发，或者你已经用过 STM32 的标准外设库、HAL 库，但一直没搞明白“为什么我的main之前还有那么多代码”，那这篇文章就是写给你的。我不会只告诉你“启动文件里有个Reset_Handler”，我会把整条链路拆开，让你看清楚每一步在做什么、为什么必须这么做、如果少了某一步会发生什么。
同时，我也会结合GPIO这个最基础的外设，把“从main到点灯”的完整过程串一遍。因为 GPIO 是大多数人接触 STM32 的第一个外设，也是理解“标准外设库到底帮你做了什么”的最佳切入点。
1.3 先给一个全局视角
在 PC 上，你的 C 程序从源码到运行，大致是这样的：
源码 → 编译器 → 目标文件 → 链接器 → 可执行文件 → 操作系统加载 → 运行时库初始化 → main在 STM32 上，这条链路变成了：
源码 → 编译器 → 目标文件 → 链接器 → 可执行文件（.elf/.hex/.bin） → 烧录到 Flash → 上电复位 → 启动文件 → 运行时库初始化 → main看起来差不多，对吧？但关键区别在于：PC 上“操作系统加载”和“运行时库初始化”是操作系统和 C 运行时库帮你做的，你不需要关心；而在 STM32 上，这些工作必须由你自己（或者说，由启动文件和链接脚本）来完成。
这就是为什么你在 STM32 工程里会看到一个startup_stm32f10x_md.s这样的文件，而在 PC 工程里从来没见过类似的东西。
2. 拆解main之前的那些事
2.1 启动文件：STM32 的“第一行代码”
当你把 STM32 的工程展开，找到那个.s结尾的汇编文件，打开它，你会看到类似这样的内容：
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main IMPORT SystemInit LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP这段代码非常短，但它做的事情极其关键。我们逐行拆解：
Reset_Handler是一个标签，它对应的是复位中断服务程序。STM32 上电或者按下复位键之后，CPU 会从固定的地址取出第一条指令的地址，然后跳过去执行。这个地址就是Reset_Handler的入口。SystemInit是芯片厂商提供的一个函数，通常用 C 语言写，负责配置系统时钟、初始化外部存储器控制器等。在标准外设库的工程里，你会在system_stm32f10x.c里找到它。__main不是你的main函数。它是编译器（ARMCC 或 GCC）提供的运行时入口，负责初始化堆栈、清零 BSS 段、拷贝 DATA 段，然后才会调用你写的main。
这里有一个非常容易混淆的点：__main和main是两个不同的东西。__main是编译器运行时库的一部分，main是你写的业务代码入口。很多初学者在调试的时候发现程序跑不到main，就是因为__main之前的某个环节出了问题。
注意：在 Keil MDK 环境下，如果你在
main函数里打断点，有时候会发现程序先停在__main里，然后再跳到main。这是正常的，不是你的代码有问题。
2.2 链接脚本：决定代码放在哪里
在 PC 上，你的可执行文件由操作系统加载，加载地址由操作系统决定。在 STM32 上，代码放在 Flash 里，变量放在 SRAM 里，这些地址是固定的，由链接脚本（Linker Script）决定。
以 GCC 为例，链接脚本通常是一个.ld文件，里面会定义：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K }这告诉链接器：Flash 从0x08000000开始，大小 128K；SRAM 从0x20000000开始，大小 20K。你的代码段、只读数据段会被放到 Flash 里，可读写数据段和 BSS 段会被放到 SRAM 里。
为什么 STM32 的 Flash 起始地址是0x08000000？这是 ARM Cortex-M 系列芯片的存储器映射决定的。0x00000000地址区域被映射到了 Flash 或者系统存储器，具体取决于 BOOT 引脚的配置。上电时，CPU 从0x00000000取向量表，而向量表的第一个条目就是初始堆栈指针，第二个条目就是Reset_Handler的地址。
如果你在链接脚本里把 Flash 起始地址写错了，程序烧进去之后根本跑不起来，因为 CPU 找不到有效的向量表。
2.3 向量表：中断的“通讯录”
向量表是启动文件里另一个核心内容。它本质上是一个数组，每个元素是一个函数地址，对应一个中断或异常。
__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler DCD HardFault_Handler ; Hard Fault Handler DCD MemManage_Handler ; MPU Fault Handler DCD BusFault_Handler ; Bus Fault Handler DCD UsageFault_Handler ; Usage Fault Handler ...第一项__initial_sp是堆栈指针的初始值，通常指向 SRAM 的末尾。第二项Reset_Handler就是上电后执行的第一条指令的地址。后面的每一项对应一个中断源。
当你在代码里写了void EXTI0_IRQHandler(void)这个函数，并且使能了外部中断 0，那么当按键按下触发中断时，CPU 就会从向量表里找到EXTI0_IRQHandler的地址，跳过去执行。如果你没有定义这个函数，向量表里默认指向的是一个死循环，程序就会卡在那里。
实操心得：很多人在调试中断的时候发现程序“跑飞了”，最后查出来是因为中断服务函数的名称写错了，比如把
EXTI0_IRQHandler写成了EXTI0_Handler。编译器不会报错，因为链接器会使用启动文件里的弱定义（WEAK），但实际执行的是默认的死循环。
2.4 运行时初始化：BSS 和 DATA 段的处理
__main函数做的最重要的一件事，就是初始化内存。具体来说：
- BSS 段：存放未初始化的全局变量和静态变量。C 语言标准规定这些变量初始值为 0。
__main会把 BSS 段对应的 SRAM 区域全部清零。 - DATA 段：存放已初始化的全局变量和静态变量。这些变量的初始值存储在 Flash 里，
__main会把它们从 Flash 拷贝到 SRAM。
如果你在代码里写了int global_var = 42;，这个 42 会先存在 Flash 里，上电后由__main拷贝到 SRAM 中对应的位置。如果你写了int global_var;，它会被放在 BSS 段，上电后被清零。
这个过程在 PC 上是由操作系统加载器完成的，在 STM32 上则由__main完成。如果你自己写启动代码（比如用汇编从头写），就必须手动实现这个过程，否则全局变量的初始值就是随机数。
3. 从main到 GPIO：标准外设库帮你做了什么
3.1 标准外设库的定位
当你打开一个基于标准外设库（Standard Peripheral Library，简称 SPL）的 STM32 工程，你会看到这样的代码：
#include "stm32f10x.h" int main(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStructure); while (1) { GPIO_SetBits(GPIOC, GPIO_Pin_13); for (int i = 0; i < 1000000; i++); GPIO_ResetBits(GPIOC, GPIO_Pin_13); for (int i = 0; i < 1000000; i++); } }这段代码做的事情很简单：让 PC13 引脚上的 LED 闪烁。但如果你把这几行代码和 STM32 参考手册里的寄存器操作对照一下，你会发现标准外设库帮你隐藏了大量的细节。
3.2 时钟使能：为什么第一步是 RCC
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);这行代码的作用是使能 GPIOC 的时钟。
为什么必须使能时钟？因为 STM32 的外设默认是关闭的，不消耗电能。只有当你使能了某个外设的时钟，这个外设的寄存器才能被读写。如果你不使能时钟就直接操作 GPIO 寄存器，写进去的值不会生效，读出来的值也没有意义。
这就像你家里的电器：插头插上了，但墙上的开关没打开，电器还是不工作。RCC（复位和时钟控制）就是那个开关。
在标准外设库中，RCC_APB2PeriphClockCmd最终操作的是RCC->APB2ENR寄存器。你可以直接写：
RCC->APB2ENR |= RCC_APB2ENR_IOPCEN;效果是一样的。标准外设库只是把寄存器操作封装成了函数，让代码更可读。
3.3 GPIO 的 8 种工作模式
标准外设库定义了 8 种 GPIO 模式，对应参考手册里的配置：
| 模式 | 宏定义 | 典型应用 |
|---|---|---|
| 浮空输入 | GPIO_Mode_IN_FLOATING | 外部信号输入，电平由外部决定 |
| 上拉输入 | GPIO_Mode_IPU | 按键输入，默认高电平 |
| 下拉输入 | GPIO_Mode_IPD | 按键输入，默认低电平 |
| 模拟输入 | GPIO_Mode_AIN | ADC 采集 |
| 开漏输出 | GPIO_Mode_Out_OD | I2C 总线 |
| 推挽输出 | GPIO_Mode_Out_PP | LED 驱动 |
| 复用开漏 | GPIO_Mode_AF_OD | 复用功能，如 I2C |
| 复用推挽 | GPIO_Mode_AF_PP | 复用功能，如 SPI |
选择哪种模式，取决于你的外设需求。比如驱动 LED，用推挽输出；读取按键，用上拉或下拉输入；做 I2C 通信，用开漏输出。
常见问题：为什么我的按键读不到低电平？检查一下是不是配置成了浮空输入，而外部又没有上拉电阻。浮空输入的电平是不确定的，必须外部提供确定的电平。
3.4 从库函数到寄存器：一层层剥开
GPIO_Init这个函数看起来很简单，但它内部做的事情并不少。以推挽输出为例，它需要配置CRL或CRH寄存器中的 4 个位（MODE 和 CNF）。
对于 PC13，它属于 GPIO 的高 8 位，所以配置的是CRH寄存器。GPIO_Init会根据你传入的GPIO_Pin计算出对应的位偏移，然后清除原来的配置，写入新的配置。
如果你直接操作寄存器，代码是这样的：
// 配置 PC13 为推挽输出，最大速度 50MHz GPIOC->CRH &= ~(0x0F << 20); // 清除 PC13 的配置位 GPIOC->CRH |= (0x03 << 20); // MODE=11 (50MHz), CNF=00 (推挽输出)标准外设库的GPIO_Init做的事情本质上和上面两行代码一样，只是它加了参数检查、支持同时配置多个引脚、代码更通用。
4. 实操：从零搭建一个 STM32 工程
4.1 工程目录结构
一个典型的基于标准外设库的 STM32 工程，目录结构大致如下：
Project/ ├── CMSIS/ │ ├── core_cm3.h │ ├── stm32f10x.h │ └── system_stm32f10x.c ├── Library/ │ ├── stm32f10x_gpio.c │ ├── stm32f10x_rcc.c │ └── ... ├── Startup/ │ └── startup_stm32f10x_md.s ├── User/ │ ├── main.c │ └── stm32f10x_conf.h └── Project.uvprojxCMSIS目录存放 ARM Cortex-M 内核相关的头文件和芯片厂商提供的系统初始化代码。Library目录存放标准外设库的源文件。Startup目录存放启动文件，根据芯片型号选择对应的.s文件。User目录存放你自己的代码。
4.2 启动文件的选择
STM32F103 系列有不同的容量版本：小容量（16K-32K Flash）、中容量（64K-128K Flash）、大容量（256K-512K Flash）。启动文件也对应不同的版本：
startup_stm32f10x_ld.s：小容量startup_stm32f10x_md.s：中容量startup_stm32f10x_hd.s：大容量
如果你选错了启动文件，比如中容量的芯片用了小容量的启动文件，堆栈大小和向量表可能会不匹配，导致程序运行异常。
实操心得：我一般会直接看芯片型号里的 Flash 容量。比如 STM32F103C8T6，C8 代表 64K Flash，属于中容量，所以选
startup_stm32f10x_md.s。STM32F103ZET6，ZE 代表 512K Flash，属于大容量，选startup_stm32f10x_hd.s。
4.3 时钟配置：72MHz 是怎么来的
STM32F103 的最高主频是 72MHz。这个 72MHz 不是凭空来的，而是通过外部晶振（通常是 8MHz）经过 PLL 倍频得到的。
SystemInit函数会配置时钟树：
- 使能外部高速晶振（HSE）。
- 等待 HSE 稳定。
- 配置 PLL：HSE × 9 = 72MHz。
- 切换系统时钟源到 PLL。
- 配置 AHB、APB1、APB2 的分频系数。
APB1 的最高频率是 36MHz，所以通常设置为 2 分频；APB2 的最高频率是 72MHz，所以设置为 1 分频。
如果你不调用SystemInit，或者SystemInit里的配置不对，系统会默认使用内部 8MHz 的 HSI 时钟，所有外设的时序都会变慢。比如你配置串口波特率为 115200，但实际时钟是 8MHz 而不是 72MHz，波特率就会偏差很大，通信会出错。
4.4 编译、链接、烧录
在 Keil MDK 里，编译和链接是一键完成的。但如果你用 GCC 命令行，过程是这样的：
# 编译 arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O2 -o main.o main.c # 链接 arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -T stm32f103c8t6.ld -o project.elf main.o startup.o ... # 生成 hex 和 bin arm-none-eabi-objcopy -O ihex project.elf project.hex arm-none-eabi-objcopy -O binary project.elf project.bin链接脚本stm32f103c8t6.ld决定了代码和数据的布局。如果你用的是 Keil，链接脚本是隐式的，由 Keil 根据芯片型号自动生成。
烧录的时候，你需要一个调试器，比如 ST-Link 或 J-Link。把调试器和开发板连接好，然后在 IDE 里点击下载按钮，代码就会被写入 Flash。
5. 常见问题与排查技巧
5.1 程序跑不到main
这是最常见的问题之一。可能的原因有：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 程序卡在启动文件 | 堆栈指针设置错误 | 检查链接脚本中的__initial_sp |
程序卡在SystemInit | 外部晶振未起振 | 用示波器测量晶振引脚 |
程序卡在__main | 堆栈溢出 | 增大启动文件中的堆栈大小 |
| 程序直接进入 HardFault | 向量表地址错误 | 检查 Flash 起始地址和 BOOT 引脚 |
避坑技巧：如果你在
main函数的第一行打断点，程序停不下来，先检查一下是不是启动文件选错了。我曾经用了一个大容量的启动文件去编译中容量的芯片，结果堆栈指针指向了不存在的 SRAM 区域，程序一上电就 HardFault。
5.2 GPIO 不工作
GPIO 配置好了但不工作，通常有以下几个原因：
- 时钟没使能：这是最常见的。检查
RCC_APB2PeriphClockCmd是否调用了，参数是否正确。 - 引脚被复用：有些引脚默认是复用功能，比如 JTAG 引脚。如果你要用 PB3、PB4、PA15 做普通 GPIO，需要先禁用 JTAG 功能。
- 模式配置错误：输出模式配成了输入模式，或者推挽配成了开漏。
- 硬件问题：LED 接反了，限流电阻太大，或者引脚虚焊。
5.3 中断不触发
中断配置的步骤比较多，容易漏掉某一项：
- 使能外设时钟。
- 配置 GPIO 为输入模式。
- 配置 EXTI 线，选择触发边沿。
- 配置 NVIC，使能对应的中断通道。
- 在启动文件对应的中断服务函数里写处理逻辑。
如果中断不触发，逐项检查以上步骤。特别是 NVIC 的优先级配置，如果优先级设置不当，可能会被其他中断屏蔽。
5.4 标准外设库和 HAL 库的区别
标准外设库是 ST 早期推出的库，直接操作寄存器，代码效率高，但可移植性差。HAL 库是后来推出的，抽象层次更高，支持 STM32 全系列，但代码体积大，效率略低。
如果你刚开始学 STM32，我建议先从标准外设库入手，因为它更接近硬件，能帮你理解底层原理。等你对寄存器操作熟悉了，再转向 HAL 库或 LL 库，会轻松很多。
6. 一些个人体会
我从 PC 端 C 语言转到 STM32 的时候，最大的困惑就是“为什么我的main之前还有那么多代码”。后来把启动文件、链接脚本、运行时初始化这些东西啃了一遍，才真正理解了一个程序从源码到运行的全过程。
这个过程在 PC 上被操作系统和编译器隐藏了，但在单片机上，你必须自己面对。这既是挑战，也是机会——因为你可以完全掌控代码的每一个字节，知道每一段内存里放的是什么，每一条指令在做什么。
如果你正在学 STM32，我建议你不要只满足于“库函数能用就行”。试着打开启动文件看看，试着查一下链接脚本，试着用寄存器操作点一次灯。这些底层的知识，会在你遇到奇怪问题的时候，帮你快速定位原因。
最后分享一个我常用的调试技巧：如果程序跑飞了，先在HardFault_Handler里打个断点，然后查看 LR 寄存器的值，它能告诉你出错前程序在哪个地址执行。结合反汇编文件，通常能很快找到问题所在。
