1. 课程导入
各位同学，大家好。我是你们这堂课的主讲人。做了十几年嵌入式底层，踩过的坑比写过的代码还多。今天咱们开篇第一讲，不急着讲代码，先聊聊一个根本问题——为什么我们要折腾“可移植性架构”？
说白了，就是现在的嵌入式开发环境，跟十年前完全不一样了。芯片短缺、平台碎片化，这两个问题像两座大山，压得很多项目喘不过气。我见过太多团队，产品卖得不错，结果换个主控芯片，代码得重写大半，那叫一个痛苦。
一、芯片荒：一场没有预告的压力测试
2020年那场全球芯片短缺，相信在座的都有体会。一颗原本几块钱的MCU，价格翻了十倍还买不到货。很多公司被迫临时更换芯片方案。
这时候问题就来了：你的代码能快速迁移吗？
现实很残酷：大部分嵌入式项目，代码和硬件是“焊死”在一起的。寄存器操作、外设初始化、中断处理，全都散落在业务逻辑里。换一颗芯片，等于重新开发。
我记得有个做工业控制的朋友，他们产品用的是某款国外MCU。缺货后想换成国产替代，结果发现底层驱动全是直接操作寄存器的，跟芯片数据手册强耦合。三个人，整整干了两个月，才把驱动移植完。业务逻辑还没动呢。
为什么会这样？因为当初写代码的时候，压根没想过要换芯片。你想想看，一个项目从立项到量产，快则半年，慢则一两年。市场变化这么快，谁能保证你选的芯片一直有货？
| 芯片供应状态 | 无移植架构的项目 | 有移植架构的项目 |
|---|---|---|
| 原芯片正常供应 | 正常开发，无额外成本 | 正常开发，初期投入架构成本 |
| 原芯片缺货/涨价 | 代码几乎作废，需重写驱动 | 修改HAL层，业务代码零改动 |
| 需要增加第二供应商 | 维护两套独立代码，工作量翻倍 | 共用上层代码，只适配底层 |
| 产品升级换代 | 从零开始，历史代码难以复用 | 快速移植，保护软件投资 |
二、平台碎片化：一个世界，无数种芯片
芯片荒只是催化剂。真正让可移植性成为刚需的，是嵌入式平台的碎片化。
ARM Cortex-M系列就有M0、M3、M4、M7、M33……这还不算RISC-V、Xtensa、各种国产内核。每家芯片厂商的外设寄存器设计，那真是“八仙过海，各显神通”。
我早期做过一个项目，需要在三款不同架构的芯片上跑同一套应用逻辑。当时年轻气盛，觉得“不就是改改寄存器地址嘛”。结果呢？
- GPIO的配置方式完全不同——有的用位带操作，有的用寄存器组
- 定时器的模式寄存器布局，每家都有自己的“创意”
- 中断优先级的管理，ARM用NVIC，别的内核有自己的玩法
那段时间，我每天都在跟数据手册搏斗。代码里充斥着 #ifdef 条件编译，一个函数能写三套实现。维护起来？别提了，改一个bug要在三个平台分别测试。
避坑指南：我曾经接手过一个项目，代码里全是 #ifdef CHIP_A、#elif CHIP_B 这样的宏。看起来“一套代码支持多平台”，实际上每个平台的代码路径都不一样，测试覆盖不全，出问题根本查不出来。这种“伪移植”比没有移植更可怕。
三、可移植性架构：解决问题的钥匙
那么，怎么解决这些问题？答案就是——驱动分层 + 硬件抽象层（HAL）。
这个思路其实不复杂。就是把软件分成几层：
- 应用层：只关心业务逻辑，不关心硬件细节
- 中间层/服务层：提供操作系统抽象、文件系统、协议栈等
- 硬件抽象层（HAL）：封装所有硬件差异，向上提供统一接口
- 驱动层：直接操作寄存器，实现具体外设功能
打个比方：你家的电器（应用层）只需要插到插座上就能用，不用管发电厂是火电还是水电。插座标准（HAL接口）统一了，换发电厂（换芯片）不影响你用电。
下面这张图，就是我们这门课要讲的核心架构：
我的建议：不要等到项目做大了再重构架构。从第一个工程开始，就把分层思想贯彻进去。哪怕只是点亮一个LED，也走一遍HAL接口。养成习惯后，你会发现移植工作变得异常轻松。
四、这门课能带给你什么？
这门课不讲虚的。30章内容，从驱动分层设计、HAL接口定义，到实际移植适配、调试技巧，全是实战干货。
我们会用具体的芯片平台（比如STM32和GD32）做演示，手把手带你搭建一套可移植的嵌入式软件框架。你学完以后，不管换什么芯片，都能快速把代码迁移过去。
嗯，开篇就到这里。记住一句话：可移植性不是锦上添花，而是嵌入式开发的生存技能。芯片荒和平台碎片化不会消失，我们能做的，就是让自己的代码足够“强壮”，经得起折腾。