1. 从看了三篇还没写一行代码说起这个系列到底在磨什么如果你是从这个系列的第一篇一路追过来的看到第五篇的标题大概会心一笑——看了三篇了一行都没让我写呢。这句话我在评论区见过太多次也在自己的学习经历里反复出现过。前四篇我们聊了工具链、聊了工程结构、聊了为什么嵌入式C不能照搬PC端那套写法但确实键盘上的手指还没真正动起来。这一篇就是来还债的。不过在动手之前我想先把一个事情说清楚为什么我要花四篇的篇幅做铺垫而不是第一篇就甩一个main.cpp让你编译烧录。原因很简单STM32上的C和你在PC上写的C虽然语法是同一套但运行环境差了十万八千里。PC上你有操作系统帮你管内存、管异常、管标准库的初始化STM32上这些东西要么不存在要么需要你自己搭。如果一上来就写代码你大概率会遇到编译过了但跑不起来跑起来了但莫名其妙HardFault换个芯片就全崩这类问题然后陷入无尽的搜索和试错。我见过太多人学STM32的C卡在能编译但不敢用的阶段。根本原因不是C难而是没有建立起对运行环境的正确认知。前四篇做的就是这个认知建设工具链怎么选、CMake怎么组织、启动流程里C的构造函数什么时候被调用、堆和栈在链接脚本里怎么划分。这些东西看起来不是代码但它们决定了你后面写的每一行代码能不能可靠运行。所以这一篇我们正式开始写。但我要提前打个预防针这一篇写的代码依然不是点个灯就完事的那种。我会带你从零搭一个能跑C的STM32工程骨架把前面讲的东西全部落地成可编译、可烧录、可调试的实际文件。你会看到.cpp文件、CMakeLists.txt、链接脚本、启动文件是怎么咬合在一起的。写完这一篇你手里就有了一个可以持续迭代的C嵌入式工程底座后面想加什么功能都是往上叠。关键词里提到了STM32、嵌入式、C、CMake、Renode这几个词基本勾勒出了这个系列的技术栈轮廓。这一篇会全部涉及尤其是CMake和Renode前者是工程组织的核心后者是我们没有硬件也能验证代码的手段。如果你手头有开发板当然更好没有的话跟着用Renode跑仿真也完全能跟上。适合谁看如果你有C语言基础、用过Keil或者STM32CubeIDE点过灯、但对C在嵌入式里怎么落地心里没底那这一篇就是写给你的。如果你是完全零基础建议先补一下C语言和STM32的基本概念否则后面讲链接脚本和启动流程的部分会比较吃力。2. 动手前的最后一块拼图把工具链和目录结构定死2.1 为什么目录结构要在写第一行代码前就定好很多人写嵌入式项目的习惯是新建一个工程把所有.c、.h、.cpp文件全扔在根目录编译能过就行。小项目这么干没问题但一旦代码量上去或者要引入第三方库这种一锅炖的结构就会变成灾难。我自己的经验是目录结构定得越早后面重构的成本越低。更重要的是CMake对目录结构是有预期的。如果你用target_include_directories、target_sources这些现代CMake的写法目录组织得清晰CMakeLists写起来就顺如果文件散落各处你就得写一堆相对路径维护起来非常痛苦。我推荐的目录结构是这样的stm32-cpp-starter/ ├── CMakeLists.txt # 顶层构建脚本 ├── cmake/ │ ├── arm-none-eabi.cmake # 工具链配置 │ └── stm32f103.cmake # 芯片相关配置 ├── src/ │ ├── main.cpp # 应用入口 │ ├── system/ │ │ ├── startup_stm32f103.s # 启动文件 │ │ └── syscalls.c # 系统调用桩 │ └── drivers/ │ ├── gpio.cpp │ └── gpio.hpp ├── include/ │ └── config.hpp # 全局配置 ├── ld/ │ └── stm32f103.ld # 链接脚本 └── third_party/ └── CMSIS/ # 芯片头文件这个结构有几个讲究。src和include分开是因为头文件是要被外部引用的源文件是内部实现物理隔离能避免不小心把实现细节暴露出去。cmake目录单独放工具链配置是因为这部分内容和你的应用代码生命周期不同——换芯片时你只动cmake和ldsrc基本不动。third_party放CMSIS这类厂商提供的代码方便你区分自己写的和抄来的。2.2 工具链配置为什么用CMake而不是Keil的工程文件这里要正面回答一个高频问题既然Keil和STM32CubeIDE都能一键生成工程为什么还要折腾CMake。答案不是CMake更高级而是CMake让工程描述和IDE解耦。Keil的.uvprojx是私有格式你没法用Git做有意义的diff团队协作时合并冲突基本靠吼。STM32CubeIDE的工程文件虽然基于Eclipse但同样绑定了特定IDE。CMake的CMakeLists.txt是纯文本谁都能读谁都能改配合CMakePresets.json还能做到一份配置多平台构建。更实际的一点CMake能让你在PC上编译同一份代码做单元测试。嵌入式开发最痛苦的就是改一行烧一次如果核心逻辑能用CMake在PC上编译成可执行文件跑测试开发效率会高一个数量级。这个能力在Keil里基本不可能实现。工具链配置文件cmake/arm-none-eabi.cmake的核心内容set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-none-eabi-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g) set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_OBJCOPY ${TOOLCHAIN_PREFIX}objcopy) set(CMAKE_SIZE ${TOOLCHAIN_PREFIX}size) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) set(CMAKE_C_FLAGS_INIT -mcpucortex-m3 -mthumb -mfloat-abisoft) set(CMAKE_CXX_FLAGS_INIT -mcpucortex-m3 -mthumb -mfloat-abisoft -fno-exceptions -fno-rtti)这里有几个关键点值得展开。CMAKE_SYSTEM_NAME设为Generic是告诉CMake这是个裸机环境别给我加操作系统相关的默认链接选项。CMAKE_TRY_COMPILE_TARGET_TYPE设为STATIC_LIBRARY是因为交叉编译时CMake默认会尝试链接一个可执行文件来测试编译器但裸机环境下没有默认的启动文件和链接脚本链接必然失败设成静态库就能绕过这个测试。C的编译选项里-fno-exceptions和-fno-rtti是嵌入式C的标配。异常机制需要运行时支持会显著增加代码体积和不确定性RTTI运行时类型识别在资源受限环境里基本用不上。关掉这两个你的二进制文件能小一大截运行行为也更可预测。2.3 芯片配置把换芯片这件事变成改一个文件cmake/stm32f103.cmake这个文件的作用是把芯片相关的参数集中管理set(STM32_CHIP STM32F103C8) set(STM32_FAMILY STM32F1) set(STM32_CORE cortex-m3) set(STM32_FLASH_SIZE 64K) set(STM32_RAM_SIZE 20K) set(STM32_DEFINES -D${STM32_CHIP} -DUSE_HAL_DRIVER )这样组织的好处是当你从F103换到F407时只需要改这个文件里的几行顶层CMakeLists和源码基本不用动。我见过太多项目把芯片型号硬编码在编译选项里换芯片时满工程搜索替换非常容易漏。提示芯片型号的宏定义比如STM32F103C8是CMSIS头文件用来选择寄存器定义的关键写错了会导致编译时找不到对应的外设寄存器报一堆undefined错误。这个宏必须和你的实际芯片完全一致。3. 让C真正跑起来启动流程里的三个关键动作3.1 启动文件里C构造函数是怎么被调用的这是整个系列里最容易被忽略、但最关键的一个技术点。C语言里全局变量在启动时被初始化靠的是启动文件里的.data段拷贝和.bss段清零。但C不一样全局对象的构造函数需要在main之前被调用这个机制在裸机环境里不是自动的。启动文件startup_stm32f103.s里Reset_Handler的典型流程是这样的Reset_Handler: ldr r0, _sdata ldr r1, _edata ldr r2, _sidata movs r3, #0 b LoopCopyDataInit CopyDataInit: ldr r4, [r2, r3] str r4, [r0, r3] adds r3, r3, #4 LoopCopyDataInit: adds r4, r0, r3 cmp r4, r1 bcc CopyDataInit ; ... bss清零 ... bl __libc_init_array ; 关键调用C全局构造函数 bl main bx lr__libc_init_array这个函数是newlib提供的它会遍历.init_array段里的所有函数指针并依次调用。C编译器会把每个全局对象的构造函数注册到这个段里。如果你在启动文件里漏掉了bl __libc_init_array那么所有全局对象的构造函数都不会被执行对象的状态就是未初始化的内存——这会导致非常隐蔽的bug因为编译能过链接能过但运行时行为完全错误。我踩过这个坑。当时写了一个全局的Uart对象构造函数里配置了波特率结果串口一直没输出。查了半天以为是时钟配置问题最后发现是启动文件里没有调用__libc_init_array。这个教训告诉我启动文件不是厂商给的、不用看的黑盒它是C能跑起来的前提。3.2 链接脚本里.init_array和.fini_array的位置链接脚本stm32f103.ld里需要显式地把.init_array和.fini_array段放到Flash里.init_array : { . ALIGN(4); __init_array_start .; KEEP(*(.init_array*)) __init_array_end .; } FLASH .fini_array : { . ALIGN(4); __fini_array_start .; KEEP(*(.fini_array*)) __fini_array_end .; } FLASHKEEP这个指令很重要它告诉链接器即使这个段看起来没被引用也不要把它优化掉。因为.init_array里的函数指针是通过特殊机制引用的链接器的垃圾回收--gc-sections可能会误判它们没被使用而删掉。加上KEEP就能避免这个问题。.fini_array在裸机环境里基本用不上因为没有程序正常退出的概念但保留它是为了兼容newlib的__libc_init_array实现有些版本的实现会同时引用这两个符号。3.3syscalls.c为什么裸机也需要它newlib是GCC ARM工具链默认的C库它假设自己运行在一个有操作系统的环境里所以提供了一堆系统调用的弱符号weak symbol比如_write、_read、_sbrk、_close等。在裸机上这些符号没有实现如果你用了printf或者malloc链接时就会报undefined reference to_write。syscalls.c的作用就是提供这些系统调用的最小实现。比如_write可以重定向到串口_sbrk可以基于链接脚本里的堆区域实现extern int _end; static uint8_t *heap_end NULL; void *_sbrk(int incr) { uint8_t *prev_heap_end; if (heap_end NULL) { heap_end (uint8_t *)_end; } prev_heap_end heap_end; heap_end incr; return (void *)prev_heap_end; }这里有个细节_sbrk返回的是增加之前的堆顶指针这是brk/sbrk语义的要求。如果返回错了malloc拿到的地址就会错位导致内存踩踏。这个bug极其难查因为表现是随机崩溃而不是每次都崩在同一个地方。注意如果你在C里用了new它底层会调用malloc进而调用_sbrk。所以即使你不直接用malloc只要用了new就必须实现_sbrk。这也是为什么嵌入式C里通常建议禁用动态内存分配——不是不能用而是用了就要对堆的管理负责。4. 第一个C类从GPIO封装看嵌入式C的设计取舍4.1 为什么不用HAL库的C接口直接写STM32的HAL库是C接口用起来是这样的GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin GPIO_PIN_13; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOC, GPIO_InitStruct); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);这段代码能跑但有几个问题。第一GPIO_InitTypeDef是个结构体每次初始化都要手动填字段容易漏填或者填错。第二GPIOC和GPIO_PIN_13是分离的两个参数调用时可能传错组合。第三没有编译期检查比如你给一个输入引脚调WritePin编译器不会报错。C的封装可以把这些问题解决掉。核心思路是把引脚这个概念建模成一个对象把配置和操作绑定在一起。4.2 GPIO类的设计编译期检查与零开销抽象先看头文件gpio.hpp#pragma once #include cstdint #include stm32f103xx.h class Gpio { public: enum class Mode : uint32_t { Input, OutputPushPull, OutputOpenDrain, AlternatePushPull, Analog }; enum class Pull : uint32_t { None, Up, Down }; constexpr Gpio(GPIO_TypeDef* port, uint16_t pin) noexcept : port_(port), pin_(pin) {} void configure(Mode mode, Pull pull Pull::None) const noexcept; void set() const noexcept; void reset() const noexcept; void toggle() const noexcept; bool read() const noexcept; private: GPIO_TypeDef* port_; uint16_t pin_; };这里有几个设计决策值得说明。constexpr构造函数意味着Gpio对象可以在编译期构造。如果你把它声明为全局对象或者constexpr变量编译器能把它完全优化掉不占任何RAM。这就是所谓的零开销抽象——你用C的语法糖但生成的机器码和手写C一样。configure、set这些方法声明为const是因为它们不修改对象自身的状态port_和pin_不变只是操作硬件寄存器。这符合C的const正确性也让编译器有更多优化空间。noexcept告诉编译器这些函数不会抛异常。在-fno-exceptions的环境下这个标注其实没有运行时影响但它是一种文档表明这个函数的契约。4.3 实现文件把寄存器操作藏起来gpio.cpp的实现#include gpio.hpp void Gpio::configure(Mode mode, Pull pull) const noexcept { // 使能对应端口的时钟简化处理实际项目应集中管理 if (port_ GPIOA) RCC-APB2ENR | RCC_APB2ENR_IOPAEN; else if (port_ GPIOB) RCC-APB2ENR | RCC_APB2ENR_IOPBEN; else if (port_ GPIOC) RCC-APB2ENR | RCC_APB2ENR_IOPCEN; uint32_t pin_pos __builtin_ctz(pin_); // 计算pin的位位置 volatile uint32_t* crl port_-CRL; volatile uint32_t* crh port_-CRH; uint32_t mode_val 0; uint32_t cnf_val 0; switch (mode) { case Mode::OutputPushPull: mode_val 0x2; cnf_val 0x0; break; case Mode::OutputOpenDrain: mode_val 0x2; cnf_val 0x1; break; case Mode::Input: mode_val 0x0; cnf_val 0x2; break; case Mode::Analog: mode_val 0x0; cnf_val 0x0; break; case Mode::AlternatePushPull: mode_val 0x3; cnf_val 0x0; break; } uint32_t config (cnf_val 2) | mode_val; volatile uint32_t* target (pin_pos 8) ? crl : crh; uint32_t shift (pin_pos % 8) * 4; *target ~(0xF shift); *target | (config shift); // 上拉下拉配置F1系列通过ODR寄存器控制 if (mode Mode::Input) { if (pull Pull::Up) port_-ODR | pin_; else if (pull Pull::Down) port_-ODR ~pin_; } }这段代码里__builtin_ctz是GCC的内建函数用来计算一个数末尾零的个数等价于这个位是第几位。用它比手写循环更高效编译器会直接生成CLZ指令。volatile关键字在这里是必须的。硬件寄存器的值可能被外设改变编译器不能假设它不变也不能优化掉对它的读写。漏掉volatile是嵌入式开发里最常见的bug之一表现是代码逻辑没问题但硬件没反应。4.4 使用示例对比C和C的写法差异用这个类点灯代码是这样的#include gpio.hpp int main() { constexpr Gpio led(GPIOC, GPIO_PIN_13); led.configure(Gpio::Mode::OutputPushPull); while (true) { led.toggle(); for (volatile int i 0; i 1000000; i) {} } }对比HAL的写法这里的好处是led对象把端口和引脚绑定在一起不会传错configure和toggle是成员函数IDE能自动补全constexpr让编译器有机会把对象完全优化掉。但我要诚实地说这个封装不是没有代价的。它增加了一层间接对于极度追求性能的场景比如纳秒级翻转直接操作寄存器可能更合适。而且这个类的时钟使能逻辑放在configure里其实不太合理实际项目里应该有一个集中的时钟管理模块。我这里这么写是为了让示例能独立运行你在实际项目里要调整。5. 用CMake把这一切串起来顶层构建脚本的写法5.1 顶层CMakeLists的结构顶层CMakeLists.txt是整个工程的入口它的职责是设置工具链、定义可执行文件、指定源文件和头文件路径、配置链接选项。cmake_minimum_required(VERSION 3.20) # 工具链必须在project()之前设置 set(CMAKE_TOOLCHAIN_FILE ${CMAKE_SOURCE_DIR}/cmake/arm-none-eabi.cmake) project(stm32_cpp_starter LANGUAGES C CXX ASM) # 引入芯片配置 include(cmake/stm32f103.cmake) # 可执行文件 add_executable(${PROJECT_NAME} src/main.cpp src/drivers/gpio.cpp src/system/startup_stm32f103.s src/system/syscalls.c ) # 头文件路径 target_include_directories(${PROJECT_NAME} PRIVATE include src third_party/CMSIS/Include third_party/CMSIS/Device/ST/STM32F1xx/Include ) # 芯片宏定义 target_compile_definitions(${PROJECT_NAME} PRIVATE ${STM32_DEFINES} ) # 编译选项 target_compile_options(${PROJECT_NAME} PRIVATE -Wall -Wextra -Wpedantic -Og -g3 -ffunction-sections -fdata-sections ) # 链接选项 target_link_options(${PROJECT_NAME} PRIVATE -T${CMAKE_SOURCE_DIR}/ld/stm32f103.ld -Wl,--gc-sections -Wl,-Map${PROJECT_NAME}.map --specsnano.specs --specsnosys.specs ) # 生成hex和bin add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_OBJCOPY} -O ihex $TARGET_FILE:${PROJECT_NAME} ${PROJECT_NAME}.hex COMMAND ${CMAKE_OBJCOPY} -O binary $TARGET_FILE:${PROJECT_NAME} ${PROJECT_NAME}.bin COMMAND ${CMAKE_SIZE} $TARGET_FILE:${PROJECT_NAME} )几个关键点。CMAKE_TOOLCHAIN_FILE必须在project()之前设置否则CMake会用主机编译器做编译器检测然后报一堆错。-ffunction-sections和-fdata-sections配合--gc-sections能让链接器把没用的函数和数据删掉显著减小固件体积。--specsnano.specs启用newlib-nano这是专为嵌入式裁剪过的C库比完整版小很多。--specsnosys.specs告诉链接器系统调用我自己提供了避免链接报错。5.2 构建和烧录的实际操作配置和构建cmake -B build -G Ninja -DCMAKE_BUILD_TYPEDebug cmake --build build用Ninja而不是Make是因为Ninja的增量构建更快而且输出更干净。构建完成后build/目录下会有.elf、.hex、.bin三个文件以及一个.map文件。烧录的话如果你用ST-Link可以用openocd或者st-flashst-flash write build/stm32_cpp_starter.bin 0x80000000x8000000是STM32F103的Flash起始地址这个地址在链接脚本里也定义了两边必须一致。5.3 用Renode做无硬件验证Renode是一个开源的仿真框架能模拟包括STM32在内的多种平台。它的价值在于你可以在没有硬件的情况下验证代码逻辑尤其是启动流程、中断处理这些和硬件强相关的部分。Renode的脚本.resc文件大概长这样mach create stm32f103 machine LoadPlatformDescription platforms/cpus/stm32f103.repl sysbus LoadELF build/stm32_cpp_starter.elf showAnalyzer sysbus.uart1 start加载ELF后Renode会从复位向量开始执行你可以通过showAnalyzer观察串口输出或者用GDB连上去单步调试。这对于验证启动文件是否正确调用了__libc_init_array这类问题特别有用——你可以在main下断点看全局对象的状态对不对。提示Renode对STM32F1系列的支持相对成熟但外设模拟的完整度不如真实硬件。用它验证启动流程和核心逻辑没问题但涉及精确时序的外设比如SPI、I2C还是要在真实硬件上测。6. 那些文档不会告诉你的实操细节6.1 全局对象的构造顺序问题C标准规定同一个编译单元内的全局对象按定义顺序构造但不同编译单元之间的构造顺序是未定义的。这在嵌入式里会引发实际问题。假设你有两个全局对象Uart和LoggerLogger的构造函数里调用了Uart::send。如果Logger先于Uart构造那Logger构造时Uart还没初始化调用send就会出问题。解决办法有几个。最稳妥的是避免全局对象之间的依赖用构造即初始化RAII但保持对象独立。如果确实有依赖可以用首次使用才初始化的懒加载模式或者显式地在main里按顺序初始化。我个人的习惯是全局对象只做最简单的初始化比如存个指针真正的硬件配置放在main里显式调用。这样构造顺序就不重要了因为构造函数里没做任何有副作用的事。6.2-fno-exceptions下怎么处理错误关掉异常后C的错误处理就回到了C的风格返回错误码。但C可以做得更优雅一点比如用std::optional或者自定义的Result类型templatetypename T class Result { public: static Result ok(T value) { return Result(value); } static Result err(int code) { return Result(code); } bool is_ok() const { return !error_; } T value() const { return value_; } int error() const { return error_; } private: Result(T value) : value_(value), error_(0) {} Result(int code) : value_(), error_(code) {} T value_; int error_; };这种模式在嵌入式里很常见因为它不依赖异常机制但比裸错误码更类型安全。不过要注意std::optional在newlib-nano里可能不可用需要自己实现或者用第三方库。6.3 中断服务函数能不能用C写可以但要注意几点。首先ISR必须是extern C的因为中断向量表是C链接的extern C void EXTI0_IRQHandler() { // 处理中断 }其次ISR里不要做耗时操作不要调用可能阻塞的函数不要用动态内存分配。如果ISR里要调用C成员函数确保那个函数是noexcept的并且不依赖任何可能在ISR执行时未初始化的全局状态。最后如果ISR和主循环共享数据要考虑原子性。在Cortex-M3上简单的读写可以用volatile加关中断保护复杂的数据结构可能需要无锁设计或者双缓冲。6.4 固件体积的优化经验嵌入式C最容易被诟病的就是体积大。但实测下来只要配置得当C的固件体积和C差距很小。我的经验是优化项效果代价-fno-exceptions减少5-15KB不能用try/catch-fno-rtti减少1-3KB不能用dynamic_cast--specsnano.specs减少10-20KBprintf不支持浮点-ffunction-sections -fdata-sections--gc-sections减少10-30%无避免虚函数每个虚表约几十字节失去多态用constexpr代替运行时初始化减少启动时间无我实测过一个带GPIO封装、串口输出、简单状态机的C工程用上述配置编译出来大概12KB同等功能的C版本大概10KB。2KB的差距换来的是更好的类型安全和可维护性我认为是值得的。但如果你的芯片只有16KB Flash那2KB就是12.5%的空间这时候就要权衡了。我的建议是先用C写编译出来看体积如果超标再针对性优化而不是一开始就假设C一定大而放弃它。7. 从这一篇往后工程骨架能带你走多远写到这里你手里应该有一个能编译、能烧录、能仿真的STM32 C工程骨架了。它包含了一个可用的GPIO类、一套CMake构建系统、一个经过验证的启动流程。这不是一个玩具而是一个可以持续迭代的底座。后面你可以往上加什么串口驱动、定时器、中断管理、状态机框架、通信协议栈都可以基于这个骨架扩展。关键是你已经理解了每一层的职责和边界启动文件负责C运行时初始化链接脚本负责内存布局CMake负责构建组织C类负责硬件抽象。这些认知比具体的代码更重要因为它们决定了你遇到问题时知道去哪里找。我个人在这个阶段踩过的最大的坑是过早引入复杂的抽象。一开始就想搞一套通用驱动框架结果抽象层数太多调试时根本不知道问题出在哪一层。后来我学乖了先用最直接的方式把功能跑通等重复代码出现三次以上再考虑抽象。这个原则在嵌入式里尤其重要因为硬件的行为往往和文档描述有出入过早抽象会把硬件的怪癖藏起来后面更难处理。如果你跟着这个系列一路走下来从工具链到工程结构到实际编码应该能感受到嵌入式C的门槛不在语法而在对运行环境的理解。语法你花一周就能学会但知道构造函数什么时候被调用知道堆栈怎么划分知道中断里什么能做什么不能做这些需要时间和实践去积累。这个系列能做的是帮你把这些认知点串起来少走一些弯路。下一篇我会聊中断和并发那是嵌入式C真正开始有意思的地方——也是坑最多的地方。
STM32嵌入式C++实战：从零搭建可编译烧录的工程骨架
1. 从看了三篇还没写一行代码说起这个系列到底在磨什么如果你是从这个系列的第一篇一路追过来的看到第五篇的标题大概会心一笑——看了三篇了一行都没让我写呢。这句话我在评论区见过太多次也在自己的学习经历里反复出现过。前四篇我们聊了工具链、聊了工程结构、聊了为什么嵌入式C不能照搬PC端那套写法但确实键盘上的手指还没真正动起来。这一篇就是来还债的。不过在动手之前我想先把一个事情说清楚为什么我要花四篇的篇幅做铺垫而不是第一篇就甩一个main.cpp让你编译烧录。原因很简单STM32上的C和你在PC上写的C虽然语法是同一套但运行环境差了十万八千里。PC上你有操作系统帮你管内存、管异常、管标准库的初始化STM32上这些东西要么不存在要么需要你自己搭。如果一上来就写代码你大概率会遇到编译过了但跑不起来跑起来了但莫名其妙HardFault换个芯片就全崩这类问题然后陷入无尽的搜索和试错。我见过太多人学STM32的C卡在能编译但不敢用的阶段。根本原因不是C难而是没有建立起对运行环境的正确认知。前四篇做的就是这个认知建设工具链怎么选、CMake怎么组织、启动流程里C的构造函数什么时候被调用、堆和栈在链接脚本里怎么划分。这些东西看起来不是代码但它们决定了你后面写的每一行代码能不能可靠运行。所以这一篇我们正式开始写。但我要提前打个预防针这一篇写的代码依然不是点个灯就完事的那种。我会带你从零搭一个能跑C的STM32工程骨架把前面讲的东西全部落地成可编译、可烧录、可调试的实际文件。你会看到.cpp文件、CMakeLists.txt、链接脚本、启动文件是怎么咬合在一起的。写完这一篇你手里就有了一个可以持续迭代的C嵌入式工程底座后面想加什么功能都是往上叠。关键词里提到了STM32、嵌入式、C、CMake、Renode这几个词基本勾勒出了这个系列的技术栈轮廓。这一篇会全部涉及尤其是CMake和Renode前者是工程组织的核心后者是我们没有硬件也能验证代码的手段。如果你手头有开发板当然更好没有的话跟着用Renode跑仿真也完全能跟上。适合谁看如果你有C语言基础、用过Keil或者STM32CubeIDE点过灯、但对C在嵌入式里怎么落地心里没底那这一篇就是写给你的。如果你是完全零基础建议先补一下C语言和STM32的基本概念否则后面讲链接脚本和启动流程的部分会比较吃力。2. 动手前的最后一块拼图把工具链和目录结构定死2.1 为什么目录结构要在写第一行代码前就定好很多人写嵌入式项目的习惯是新建一个工程把所有.c、.h、.cpp文件全扔在根目录编译能过就行。小项目这么干没问题但一旦代码量上去或者要引入第三方库这种一锅炖的结构就会变成灾难。我自己的经验是目录结构定得越早后面重构的成本越低。更重要的是CMake对目录结构是有预期的。如果你用target_include_directories、target_sources这些现代CMake的写法目录组织得清晰CMakeLists写起来就顺如果文件散落各处你就得写一堆相对路径维护起来非常痛苦。我推荐的目录结构是这样的stm32-cpp-starter/ ├── CMakeLists.txt # 顶层构建脚本 ├── cmake/ │ ├── arm-none-eabi.cmake # 工具链配置 │ └── stm32f103.cmake # 芯片相关配置 ├── src/ │ ├── main.cpp # 应用入口 │ ├── system/ │ │ ├── startup_stm32f103.s # 启动文件 │ │ └── syscalls.c # 系统调用桩 │ └── drivers/ │ ├── gpio.cpp │ └── gpio.hpp ├── include/ │ └── config.hpp # 全局配置 ├── ld/ │ └── stm32f103.ld # 链接脚本 └── third_party/ └── CMSIS/ # 芯片头文件这个结构有几个讲究。src和include分开是因为头文件是要被外部引用的源文件是内部实现物理隔离能避免不小心把实现细节暴露出去。cmake目录单独放工具链配置是因为这部分内容和你的应用代码生命周期不同——换芯片时你只动cmake和ldsrc基本不动。third_party放CMSIS这类厂商提供的代码方便你区分自己写的和抄来的。2.2 工具链配置为什么用CMake而不是Keil的工程文件这里要正面回答一个高频问题既然Keil和STM32CubeIDE都能一键生成工程为什么还要折腾CMake。答案不是CMake更高级而是CMake让工程描述和IDE解耦。Keil的.uvprojx是私有格式你没法用Git做有意义的diff团队协作时合并冲突基本靠吼。STM32CubeIDE的工程文件虽然基于Eclipse但同样绑定了特定IDE。CMake的CMakeLists.txt是纯文本谁都能读谁都能改配合CMakePresets.json还能做到一份配置多平台构建。更实际的一点CMake能让你在PC上编译同一份代码做单元测试。嵌入式开发最痛苦的就是改一行烧一次如果核心逻辑能用CMake在PC上编译成可执行文件跑测试开发效率会高一个数量级。这个能力在Keil里基本不可能实现。工具链配置文件cmake/arm-none-eabi.cmake的核心内容set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-none-eabi-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g) set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_OBJCOPY ${TOOLCHAIN_PREFIX}objcopy) set(CMAKE_SIZE ${TOOLCHAIN_PREFIX}size) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) set(CMAKE_C_FLAGS_INIT -mcpucortex-m3 -mthumb -mfloat-abisoft) set(CMAKE_CXX_FLAGS_INIT -mcpucortex-m3 -mthumb -mfloat-abisoft -fno-exceptions -fno-rtti)这里有几个关键点值得展开。CMAKE_SYSTEM_NAME设为Generic是告诉CMake这是个裸机环境别给我加操作系统相关的默认链接选项。CMAKE_TRY_COMPILE_TARGET_TYPE设为STATIC_LIBRARY是因为交叉编译时CMake默认会尝试链接一个可执行文件来测试编译器但裸机环境下没有默认的启动文件和链接脚本链接必然失败设成静态库就能绕过这个测试。C的编译选项里-fno-exceptions和-fno-rtti是嵌入式C的标配。异常机制需要运行时支持会显著增加代码体积和不确定性RTTI运行时类型识别在资源受限环境里基本用不上。关掉这两个你的二进制文件能小一大截运行行为也更可预测。2.3 芯片配置把换芯片这件事变成改一个文件cmake/stm32f103.cmake这个文件的作用是把芯片相关的参数集中管理set(STM32_CHIP STM32F103C8) set(STM32_FAMILY STM32F1) set(STM32_CORE cortex-m3) set(STM32_FLASH_SIZE 64K) set(STM32_RAM_SIZE 20K) set(STM32_DEFINES -D${STM32_CHIP} -DUSE_HAL_DRIVER )这样组织的好处是当你从F103换到F407时只需要改这个文件里的几行顶层CMakeLists和源码基本不用动。我见过太多项目把芯片型号硬编码在编译选项里换芯片时满工程搜索替换非常容易漏。提示芯片型号的宏定义比如STM32F103C8是CMSIS头文件用来选择寄存器定义的关键写错了会导致编译时找不到对应的外设寄存器报一堆undefined错误。这个宏必须和你的实际芯片完全一致。3. 让C真正跑起来启动流程里的三个关键动作3.1 启动文件里C构造函数是怎么被调用的这是整个系列里最容易被忽略、但最关键的一个技术点。C语言里全局变量在启动时被初始化靠的是启动文件里的.data段拷贝和.bss段清零。但C不一样全局对象的构造函数需要在main之前被调用这个机制在裸机环境里不是自动的。启动文件startup_stm32f103.s里Reset_Handler的典型流程是这样的Reset_Handler: ldr r0, _sdata ldr r1, _edata ldr r2, _sidata movs r3, #0 b LoopCopyDataInit CopyDataInit: ldr r4, [r2, r3] str r4, [r0, r3] adds r3, r3, #4 LoopCopyDataInit: adds r4, r0, r3 cmp r4, r1 bcc CopyDataInit ; ... bss清零 ... bl __libc_init_array ; 关键调用C全局构造函数 bl main bx lr__libc_init_array这个函数是newlib提供的它会遍历.init_array段里的所有函数指针并依次调用。C编译器会把每个全局对象的构造函数注册到这个段里。如果你在启动文件里漏掉了bl __libc_init_array那么所有全局对象的构造函数都不会被执行对象的状态就是未初始化的内存——这会导致非常隐蔽的bug因为编译能过链接能过但运行时行为完全错误。我踩过这个坑。当时写了一个全局的Uart对象构造函数里配置了波特率结果串口一直没输出。查了半天以为是时钟配置问题最后发现是启动文件里没有调用__libc_init_array。这个教训告诉我启动文件不是厂商给的、不用看的黑盒它是C能跑起来的前提。3.2 链接脚本里.init_array和.fini_array的位置链接脚本stm32f103.ld里需要显式地把.init_array和.fini_array段放到Flash里.init_array : { . ALIGN(4); __init_array_start .; KEEP(*(.init_array*)) __init_array_end .; } FLASH .fini_array : { . ALIGN(4); __fini_array_start .; KEEP(*(.fini_array*)) __fini_array_end .; } FLASHKEEP这个指令很重要它告诉链接器即使这个段看起来没被引用也不要把它优化掉。因为.init_array里的函数指针是通过特殊机制引用的链接器的垃圾回收--gc-sections可能会误判它们没被使用而删掉。加上KEEP就能避免这个问题。.fini_array在裸机环境里基本用不上因为没有程序正常退出的概念但保留它是为了兼容newlib的__libc_init_array实现有些版本的实现会同时引用这两个符号。3.3syscalls.c为什么裸机也需要它newlib是GCC ARM工具链默认的C库它假设自己运行在一个有操作系统的环境里所以提供了一堆系统调用的弱符号weak symbol比如_write、_read、_sbrk、_close等。在裸机上这些符号没有实现如果你用了printf或者malloc链接时就会报undefined reference to_write。syscalls.c的作用就是提供这些系统调用的最小实现。比如_write可以重定向到串口_sbrk可以基于链接脚本里的堆区域实现extern int _end; static uint8_t *heap_end NULL; void *_sbrk(int incr) { uint8_t *prev_heap_end; if (heap_end NULL) { heap_end (uint8_t *)_end; } prev_heap_end heap_end; heap_end incr; return (void *)prev_heap_end; }这里有个细节_sbrk返回的是增加之前的堆顶指针这是brk/sbrk语义的要求。如果返回错了malloc拿到的地址就会错位导致内存踩踏。这个bug极其难查因为表现是随机崩溃而不是每次都崩在同一个地方。注意如果你在C里用了new它底层会调用malloc进而调用_sbrk。所以即使你不直接用malloc只要用了new就必须实现_sbrk。这也是为什么嵌入式C里通常建议禁用动态内存分配——不是不能用而是用了就要对堆的管理负责。4. 第一个C类从GPIO封装看嵌入式C的设计取舍4.1 为什么不用HAL库的C接口直接写STM32的HAL库是C接口用起来是这样的GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin GPIO_PIN_13; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOC, GPIO_InitStruct); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);这段代码能跑但有几个问题。第一GPIO_InitTypeDef是个结构体每次初始化都要手动填字段容易漏填或者填错。第二GPIOC和GPIO_PIN_13是分离的两个参数调用时可能传错组合。第三没有编译期检查比如你给一个输入引脚调WritePin编译器不会报错。C的封装可以把这些问题解决掉。核心思路是把引脚这个概念建模成一个对象把配置和操作绑定在一起。4.2 GPIO类的设计编译期检查与零开销抽象先看头文件gpio.hpp#pragma once #include cstdint #include stm32f103xx.h class Gpio { public: enum class Mode : uint32_t { Input, OutputPushPull, OutputOpenDrain, AlternatePushPull, Analog }; enum class Pull : uint32_t { None, Up, Down }; constexpr Gpio(GPIO_TypeDef* port, uint16_t pin) noexcept : port_(port), pin_(pin) {} void configure(Mode mode, Pull pull Pull::None) const noexcept; void set() const noexcept; void reset() const noexcept; void toggle() const noexcept; bool read() const noexcept; private: GPIO_TypeDef* port_; uint16_t pin_; };这里有几个设计决策值得说明。constexpr构造函数意味着Gpio对象可以在编译期构造。如果你把它声明为全局对象或者constexpr变量编译器能把它完全优化掉不占任何RAM。这就是所谓的零开销抽象——你用C的语法糖但生成的机器码和手写C一样。configure、set这些方法声明为const是因为它们不修改对象自身的状态port_和pin_不变只是操作硬件寄存器。这符合C的const正确性也让编译器有更多优化空间。noexcept告诉编译器这些函数不会抛异常。在-fno-exceptions的环境下这个标注其实没有运行时影响但它是一种文档表明这个函数的契约。4.3 实现文件把寄存器操作藏起来gpio.cpp的实现#include gpio.hpp void Gpio::configure(Mode mode, Pull pull) const noexcept { // 使能对应端口的时钟简化处理实际项目应集中管理 if (port_ GPIOA) RCC-APB2ENR | RCC_APB2ENR_IOPAEN; else if (port_ GPIOB) RCC-APB2ENR | RCC_APB2ENR_IOPBEN; else if (port_ GPIOC) RCC-APB2ENR | RCC_APB2ENR_IOPCEN; uint32_t pin_pos __builtin_ctz(pin_); // 计算pin的位位置 volatile uint32_t* crl port_-CRL; volatile uint32_t* crh port_-CRH; uint32_t mode_val 0; uint32_t cnf_val 0; switch (mode) { case Mode::OutputPushPull: mode_val 0x2; cnf_val 0x0; break; case Mode::OutputOpenDrain: mode_val 0x2; cnf_val 0x1; break; case Mode::Input: mode_val 0x0; cnf_val 0x2; break; case Mode::Analog: mode_val 0x0; cnf_val 0x0; break; case Mode::AlternatePushPull: mode_val 0x3; cnf_val 0x0; break; } uint32_t config (cnf_val 2) | mode_val; volatile uint32_t* target (pin_pos 8) ? crl : crh; uint32_t shift (pin_pos % 8) * 4; *target ~(0xF shift); *target | (config shift); // 上拉下拉配置F1系列通过ODR寄存器控制 if (mode Mode::Input) { if (pull Pull::Up) port_-ODR | pin_; else if (pull Pull::Down) port_-ODR ~pin_; } }这段代码里__builtin_ctz是GCC的内建函数用来计算一个数末尾零的个数等价于这个位是第几位。用它比手写循环更高效编译器会直接生成CLZ指令。volatile关键字在这里是必须的。硬件寄存器的值可能被外设改变编译器不能假设它不变也不能优化掉对它的读写。漏掉volatile是嵌入式开发里最常见的bug之一表现是代码逻辑没问题但硬件没反应。4.4 使用示例对比C和C的写法差异用这个类点灯代码是这样的#include gpio.hpp int main() { constexpr Gpio led(GPIOC, GPIO_PIN_13); led.configure(Gpio::Mode::OutputPushPull); while (true) { led.toggle(); for (volatile int i 0; i 1000000; i) {} } }对比HAL的写法这里的好处是led对象把端口和引脚绑定在一起不会传错configure和toggle是成员函数IDE能自动补全constexpr让编译器有机会把对象完全优化掉。但我要诚实地说这个封装不是没有代价的。它增加了一层间接对于极度追求性能的场景比如纳秒级翻转直接操作寄存器可能更合适。而且这个类的时钟使能逻辑放在configure里其实不太合理实际项目里应该有一个集中的时钟管理模块。我这里这么写是为了让示例能独立运行你在实际项目里要调整。5. 用CMake把这一切串起来顶层构建脚本的写法5.1 顶层CMakeLists的结构顶层CMakeLists.txt是整个工程的入口它的职责是设置工具链、定义可执行文件、指定源文件和头文件路径、配置链接选项。cmake_minimum_required(VERSION 3.20) # 工具链必须在project()之前设置 set(CMAKE_TOOLCHAIN_FILE ${CMAKE_SOURCE_DIR}/cmake/arm-none-eabi.cmake) project(stm32_cpp_starter LANGUAGES C CXX ASM) # 引入芯片配置 include(cmake/stm32f103.cmake) # 可执行文件 add_executable(${PROJECT_NAME} src/main.cpp src/drivers/gpio.cpp src/system/startup_stm32f103.s src/system/syscalls.c ) # 头文件路径 target_include_directories(${PROJECT_NAME} PRIVATE include src third_party/CMSIS/Include third_party/CMSIS/Device/ST/STM32F1xx/Include ) # 芯片宏定义 target_compile_definitions(${PROJECT_NAME} PRIVATE ${STM32_DEFINES} ) # 编译选项 target_compile_options(${PROJECT_NAME} PRIVATE -Wall -Wextra -Wpedantic -Og -g3 -ffunction-sections -fdata-sections ) # 链接选项 target_link_options(${PROJECT_NAME} PRIVATE -T${CMAKE_SOURCE_DIR}/ld/stm32f103.ld -Wl,--gc-sections -Wl,-Map${PROJECT_NAME}.map --specsnano.specs --specsnosys.specs ) # 生成hex和bin add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_OBJCOPY} -O ihex $TARGET_FILE:${PROJECT_NAME} ${PROJECT_NAME}.hex COMMAND ${CMAKE_OBJCOPY} -O binary $TARGET_FILE:${PROJECT_NAME} ${PROJECT_NAME}.bin COMMAND ${CMAKE_SIZE} $TARGET_FILE:${PROJECT_NAME} )几个关键点。CMAKE_TOOLCHAIN_FILE必须在project()之前设置否则CMake会用主机编译器做编译器检测然后报一堆错。-ffunction-sections和-fdata-sections配合--gc-sections能让链接器把没用的函数和数据删掉显著减小固件体积。--specsnano.specs启用newlib-nano这是专为嵌入式裁剪过的C库比完整版小很多。--specsnosys.specs告诉链接器系统调用我自己提供了避免链接报错。5.2 构建和烧录的实际操作配置和构建cmake -B build -G Ninja -DCMAKE_BUILD_TYPEDebug cmake --build build用Ninja而不是Make是因为Ninja的增量构建更快而且输出更干净。构建完成后build/目录下会有.elf、.hex、.bin三个文件以及一个.map文件。烧录的话如果你用ST-Link可以用openocd或者st-flashst-flash write build/stm32_cpp_starter.bin 0x80000000x8000000是STM32F103的Flash起始地址这个地址在链接脚本里也定义了两边必须一致。5.3 用Renode做无硬件验证Renode是一个开源的仿真框架能模拟包括STM32在内的多种平台。它的价值在于你可以在没有硬件的情况下验证代码逻辑尤其是启动流程、中断处理这些和硬件强相关的部分。Renode的脚本.resc文件大概长这样mach create stm32f103 machine LoadPlatformDescription platforms/cpus/stm32f103.repl sysbus LoadELF build/stm32_cpp_starter.elf showAnalyzer sysbus.uart1 start加载ELF后Renode会从复位向量开始执行你可以通过showAnalyzer观察串口输出或者用GDB连上去单步调试。这对于验证启动文件是否正确调用了__libc_init_array这类问题特别有用——你可以在main下断点看全局对象的状态对不对。提示Renode对STM32F1系列的支持相对成熟但外设模拟的完整度不如真实硬件。用它验证启动流程和核心逻辑没问题但涉及精确时序的外设比如SPI、I2C还是要在真实硬件上测。6. 那些文档不会告诉你的实操细节6.1 全局对象的构造顺序问题C标准规定同一个编译单元内的全局对象按定义顺序构造但不同编译单元之间的构造顺序是未定义的。这在嵌入式里会引发实际问题。假设你有两个全局对象Uart和LoggerLogger的构造函数里调用了Uart::send。如果Logger先于Uart构造那Logger构造时Uart还没初始化调用send就会出问题。解决办法有几个。最稳妥的是避免全局对象之间的依赖用构造即初始化RAII但保持对象独立。如果确实有依赖可以用首次使用才初始化的懒加载模式或者显式地在main里按顺序初始化。我个人的习惯是全局对象只做最简单的初始化比如存个指针真正的硬件配置放在main里显式调用。这样构造顺序就不重要了因为构造函数里没做任何有副作用的事。6.2-fno-exceptions下怎么处理错误关掉异常后C的错误处理就回到了C的风格返回错误码。但C可以做得更优雅一点比如用std::optional或者自定义的Result类型templatetypename T class Result { public: static Result ok(T value) { return Result(value); } static Result err(int code) { return Result(code); } bool is_ok() const { return !error_; } T value() const { return value_; } int error() const { return error_; } private: Result(T value) : value_(value), error_(0) {} Result(int code) : value_(), error_(code) {} T value_; int error_; };这种模式在嵌入式里很常见因为它不依赖异常机制但比裸错误码更类型安全。不过要注意std::optional在newlib-nano里可能不可用需要自己实现或者用第三方库。6.3 中断服务函数能不能用C写可以但要注意几点。首先ISR必须是extern C的因为中断向量表是C链接的extern C void EXTI0_IRQHandler() { // 处理中断 }其次ISR里不要做耗时操作不要调用可能阻塞的函数不要用动态内存分配。如果ISR里要调用C成员函数确保那个函数是noexcept的并且不依赖任何可能在ISR执行时未初始化的全局状态。最后如果ISR和主循环共享数据要考虑原子性。在Cortex-M3上简单的读写可以用volatile加关中断保护复杂的数据结构可能需要无锁设计或者双缓冲。6.4 固件体积的优化经验嵌入式C最容易被诟病的就是体积大。但实测下来只要配置得当C的固件体积和C差距很小。我的经验是优化项效果代价-fno-exceptions减少5-15KB不能用try/catch-fno-rtti减少1-3KB不能用dynamic_cast--specsnano.specs减少10-20KBprintf不支持浮点-ffunction-sections -fdata-sections--gc-sections减少10-30%无避免虚函数每个虚表约几十字节失去多态用constexpr代替运行时初始化减少启动时间无我实测过一个带GPIO封装、串口输出、简单状态机的C工程用上述配置编译出来大概12KB同等功能的C版本大概10KB。2KB的差距换来的是更好的类型安全和可维护性我认为是值得的。但如果你的芯片只有16KB Flash那2KB就是12.5%的空间这时候就要权衡了。我的建议是先用C写编译出来看体积如果超标再针对性优化而不是一开始就假设C一定大而放弃它。7. 从这一篇往后工程骨架能带你走多远写到这里你手里应该有一个能编译、能烧录、能仿真的STM32 C工程骨架了。它包含了一个可用的GPIO类、一套CMake构建系统、一个经过验证的启动流程。这不是一个玩具而是一个可以持续迭代的底座。后面你可以往上加什么串口驱动、定时器、中断管理、状态机框架、通信协议栈都可以基于这个骨架扩展。关键是你已经理解了每一层的职责和边界启动文件负责C运行时初始化链接脚本负责内存布局CMake负责构建组织C类负责硬件抽象。这些认知比具体的代码更重要因为它们决定了你遇到问题时知道去哪里找。我个人在这个阶段踩过的最大的坑是过早引入复杂的抽象。一开始就想搞一套通用驱动框架结果抽象层数太多调试时根本不知道问题出在哪一层。后来我学乖了先用最直接的方式把功能跑通等重复代码出现三次以上再考虑抽象。这个原则在嵌入式里尤其重要因为硬件的行为往往和文档描述有出入过早抽象会把硬件的怪癖藏起来后面更难处理。如果你跟着这个系列一路走下来从工具链到工程结构到实际编码应该能感受到嵌入式C的门槛不在语法而在对运行环境的理解。语法你花一周就能学会但知道构造函数什么时候被调用知道堆栈怎么划分知道中断里什么能做什么不能做这些需要时间和实践去积累。这个系列能做的是帮你把这些认知点串起来少走一些弯路。下一篇我会聊中断和并发那是嵌入式C真正开始有意思的地方——也是坑最多的地方。
