第二章：开发环境搭建——嵌入式C开发工具链、硬件仿真与版本控制
好，咱们正式开始动手了。
这一章，我会带你搭好整个开发环境。说白了，就是把你电脑武装成一个能写、能编译、能仿真、能版本管理的嵌入式开发工作站。我见过太多人卡在环境搭建这一步，一卡就是半天。其实没那么玄乎，咱们一步步来。
2.1 嵌入式C开发工具链：GCC与Makefile
嵌入式开发，绕不开GCC。GCC不是个编译器，它是一整套工具链。我习惯用arm-none-eabi-gcc这个版本，专门针对ARM Cortex-M系列。为什么用它？因为STM32就是Cortex-M内核，这个工具链最对口。
2.1.1 安装GCC工具链
Windows用户，我建议直接下载ARM官方的GCC工具链安装包。Linux用户更简单，一条命令搞定：
sudo apt-get install gcc-arm-none-eabi装完之后，验证一下：
arm-none-eabi-gcc --version看到版本号，说明成了。嗯，这里要注意：版本别太老，我建议用10.3以上。太老的版本对C11标准支持不好，咱们后面写HAL层时会用到一些新特性。
2.1.2 Makefile：别怕，它就是个自动化脚本
很多新手看到Makefile就头疼。其实你想想看，它就是个菜谱——告诉编译器先干啥、后干啥、用啥料。
咱们扫地机器人HAL层的Makefile，我习惯这样组织：
# 编译器设置
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld
OBJCOPY = arm-none-eabi-objcopy
# 编译选项
CFLAGS = -mcpu=cortex-m4 -mthumb -Wall -O2 -g
CFLAGS += -I./include -I./drivers -I./hal
# 源文件
SRCS = main.c startup.c system_stm32f4xx.c
SRCS += ./hal/gpio_hal.c ./hal/timer_hal.c ./hal/uart_hal.c
SRCS += ./drivers/motor_driver.c ./drivers/sensor_driver.c
# 生成目标
OBJS = $(SRCS:.c=.o)
TARGET = robot_hal.elf
all: $(TARGET)
$(TARGET): $(OBJS)
$(LD) -T stm32f4.ld -o $@ $^
$(OBJCOPY) -O binary $@ robot_hal.bin
%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
clean:
rm -f $(OBJS) $(TARGET) robot_hal.bin
.PHONY: all clean这个Makefile干了三件事：编译每个.c文件、链接成.elf文件、再转成.bin烧录文件。我个人习惯把HAL层、驱动层、应用层的源文件分开写，这样后期维护时一眼就能找到问题在哪。
-Wall打开所有警告。我刚开始写HAL时，一个未初始化的变量让我查了三个小时。从那以后，我编译时必开-Wall -Wextra。
2.2 硬件仿真环境：QEMU模拟STM32
没有开发板怎么办？别急，QEMU能帮你。QEMU是个硬件模拟器，可以模拟STM32系列芯片。我当年做第一个HAL项目时，就是靠QEMU在没板子的情况下把代码调通的。
2.2.1 安装QEMU
Windows用户下载QEMU安装包。Linux用户：
sudo apt-get install qemu-system-arm装好后，咱们试试能不能模拟STM32F4 Discovery板：
qemu-system-arm -M stm32f4-discovery -kernel robot_hal.bin -nographic看到QEMU启动，说明环境成了。这里要注意：QEMU模拟的是整个芯片，包括GPIO、定时器、UART等外设。你写的HAL代码，在QEMU上跑和在真实板子上跑，行为应该一致。
2.2.2 调试HAL代码
我习惯用GDB配合QEMU调试。先启动QEMU的GDB服务：
qemu-system-arm -M stm32f4-discovery -kernel robot_hal.elf -s -S -nographic然后另开终端，启动GDB：
arm-none-eabi-gdb robot_hal.elf
(gdb) target remote localhost:1234
(gdb) break hal_gpio_init
(gdb) continue你看，代码停在hal_gpio_init函数入口了。这时候你可以单步执行、查看寄存器、检查变量。我在项目中遇到过一个问题：GPIO初始化后电平不对，就是靠GDB一步步跟踪，发现是时钟使能顺序错了。
2.3 版本控制：Git基础
写代码不搞版本控制，就像开车不系安全带。平时没事，一出事就是大事。我见过有人把代码存在U盘里，U盘丢了，三个月白干。
2.3.1 Git初始化
咱们的扫地机器人HAL项目，我建议这样初始化：
cd robot_hal_project
git init
git add .
git commit -m "初始提交：HAL层框架搭建"为什么要用Git？你想想看，你改了一版代码，发现新方案不行，想回退到上一版。没有Git，你只能靠记忆重写。有Git，一条命令搞定：
git checkout .2.3.2 分支管理
我习惯这样管理分支：
| 分支名 | 用途 |
|---|---|
| main | 稳定版本，只合入经过测试的代码 |
| develop | 日常开发，所有新功能先合到这里 |
| feature/gpio_hal | 开发GPIO HAL层时用的临时分支 |
| fix/uart_bug | 修UART bug时用的分支 |
举个例子，你要开发GPIO HAL层：
git checkout -b feature/gpio_hal
# 写代码...
git add gpio_hal.c gpio_hal.h
git commit -m "完成GPIO HAL层初始化函数"
# 测试通过后，合并到develop
git checkout develop
git merge feature/gpio_hal2.3.3 .gitignore：别把垃圾文件提交上去
编译生成的.o文件、.elf文件、.bin文件，这些都不应该进版本库。我习惯这样写.gitignore：
# 编译产物
*.o
*.elf
*.bin
*.hex
# IDE配置
.idea/
.vscode/
*.swp
# 临时文件
*.log
build/嗯，这里要注意：.gitignore要在git add之前写好。如果已经提交了垃圾文件，再用.gitignore就晚了。你得先用git rm --cached把它们从版本库里删掉。
2.4 环境验证：跑一个最小HAL程序
环境搭好了，咱们验证一下。写个最简单的HAL程序：点亮LED。
// main.c
#include "hal_gpio.h"
int main(void) {
hal_gpio_init();
while(1) {
hal_gpio_write(LED_PIN, HIGH);
delay(1000);
hal_gpio_write(LED_PIN, LOW);
delay(1000);
}
return 0;
}编译：
make仿真：
qemu-system-arm -M stm32f4-discovery -kernel robot_hal.bin -nographic看到LED闪烁了吗？没有？因为QEMU没有真实LED。但你可以通过GDB查看GPIO寄存器，确认电平在变化。这就是HAL层的作用——代码写一次，在仿真环境和真实硬件上都能跑。
好，环境搭好了。下一章，咱们开始真正设计HAL层的架构。到时候你会看到，前面这些准备工作有多重要。