第一章 移植环境搭建

做RTOS移植，第一件事不是看芯片手册，也不是翻源码。

是先把环境搭好。

我见过太多人，上来就改代码，改到一半发现编译器报错、调试器连不上、代码版本乱成一锅粥。最后折腾两天，发现是工具链版本不对。

嗯，这种坑，我踩过不止一次。

1.1 交叉编译工具链配置

嵌入式开发，说白了就是在PC上写代码，编译成目标芯片能跑的机器码。这个「编译」的过程，就需要交叉编译工具链。

选哪个版本？

我个人习惯用ARM官方的GNU Arm Embedded Toolchain。原因很简单——它跟ARM Cortex-M系列芯片的匹配度最好。你想想看，用GCC通用版去编译ARM代码，有时候链接脚本的语法都不兼容。

安装步骤其实就三步：

1. 下载tar.bz2压缩包，解压到 /opt/ 目录
2. 把 bin/ 目录加到 PATH 环境变量
3. 验证：arm-none-eabi-gcc --version

# 解压
tar -xjf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 -C /opt/

# 配置环境变量（写到 ~/.bashrc 里）
export PATH=/opt/gcc-arm-none-eabi-10.3-2021.10/bin:$PATH

# 验证
arm-none-eabi-gcc --version

1.2 OpenOCD / JLink 调试环境搭建

代码写好了，总得烧进去跑跑看吧？

调试环境这块，我推荐两套方案：

方案	调试器	适用场景	我的评价
OpenOCD + FT2232	FT2232H 模块	量产、低成本	开源免费，但配置稍麻烦
JLink + JLinkGDBServer	JLink EDU / PRO	开发调试	稳定，速度快，我主力用这个

JLink 配置要点：

下载SEGGER官网的JLink软件包，解压后把 JLinkGDBServer 和 JLinkExe 加到PATH里。

# 启动 GDB Server（以STM32F407为例）
JLinkGDBServer -device STM32F407VG -if SWD -speed 4000 -port 2331

OpenOCD 配置要点：

OpenOCD需要两个配置文件：一个是接口配置（告诉它用什么调试器），一个是目标配置（告诉它芯片型号）。

# 启动 OpenOCD（以FT2232H + STM32F4为例）
openocd -f interface/ftdi/ft2232h_breakout.cfg \
        -f target/stm32f4x.cfg

1.3 最小裸机工程验证

环境搭好了，别急着移植RTOS。

先跑一个裸机工程，验证工具链和调试器是不是真的通了。这一步叫「点灯验证」——我做了十年嵌入式，每次换新平台都这么干。

最小工程结构：

project/
├── startup_stm32f407xx.s    # 启动文件
├── main.c                   # 主程序
├── stm32f4xx.h              # 寄存器定义
├── linker.ld                # 链接脚本
└── Makefile                 # 编译脚本

main.c 示例：

// 点灯！验证最小系统
void delay(volatile int count) {
    while(count--);
}

int main(void) {
    // 使能GPIO时钟
    *((unsigned int*)0x40023830) |= (1 << 3);
    
    // 配置GPIO为输出
    *((unsigned int*)0x40020C00) &= ~(0xF << 24);
    *((unsigned int*)0x40020C00) |= (0x1 << 24);
    
    while(1) {
        // 点亮LED
        *((unsigned int*)0x40020C14) |= (1 << 13);
        delay(500000);
        // 熄灭LED
        *((unsigned int*)0x40020C14) &= ~(1 << 13);
        delay(500000);
    }
}

这一步走通了，后面移植RTOS才有底气。否则你都不知道问题是出在RTOS代码上，还是工具链本身就有问题。

1.4 Git 版本管理最佳实践

说到这个，我得坦白——我早期做项目时，版本管理一塌糊涂。

文件夹命名从 project_final 到 project_final_v3_really_final，现在想想都脸红。

嵌入式项目Git管理，我总结了几条铁律：

1. 不要提交编译产物——.o文件、.elf、.hex全部加.gitignore
2. 工具链不提交——只记录版本号，每个人自己装
3. 每个功能点一个commit——别攒一周才提交一次
4. commit message 写清楚——「修复了bug」这种等于没写

# .gitignore 示例
*.o
*.elf
*.hex
*.bin
build/
*.swp
.DS_Store

分支策略：

我习惯用这种结构：

• main —— 稳定版本，只合并不直接开发
• develop —— 日常开发分支
• feature/xxx —— 新功能分支，从develop切出来
• fix/xxx —— 修复分支

本章知识体系

下面这张图，把本章的核心逻辑串起来了：

环境搭建这件事，看着琐碎，但真不能省。我见过有人跳过裸机验证直接移植FreeRTOS，结果折腾三天发现是启动文件里堆栈指针没配对——这种低级错误，一个点灯程序就能暴露出来。

所以，别急。把环境搭稳了，后面移植RTOS就是水到渠成的事。

---

公众号:蓝海资料掘金营，微信deep3321