嵌入式 CMake 化浪潮：七大平台现状对比

摘要2025 年嵌入式行业已全面转向CMake从 STM32 到 ESP32、Zephyr七大主流平台均已原生支持或强制采用。本文逐一对比各平台现状并聚焦国产芯片LKS32的独特机遇——官方虽仅提供 Keil 工程但通过完整的移植方案我们已成功将其接入 CMake 生态填补国产芯片构建体系的最后一块空白。行业迁移现状各平台现状总览行业迁移现状嵌入式 CMake 化浪潮本课目标各大平台 CMake 支持现状 — 2025 年迁移时间线 2018 - 2025三大驱动力——为什么全行业都在转开源生态需求CI/CD 压力多架构统一本页大纲行业迁移全景 CMake 化浪潮全景——7 大平台一图看清⏳ 迁移时间线深度解析——四个关键转折点 三大驱动力的深度拆解——为什么转是必然 行业迁移状态总表——把你的芯片对号入座深入 STM32深入 STM32全球最大 ARM MCU 生态的 CMake 化STM32CubeMX 生成的 CMakeLists.txt简化示例STM32 的迁移意义本页大纲深入 STM32 迁移 STM32 的转身——最震撼的行业信号 CubeMX 生成的 CMakeLists.txt 结构——和你将要写的 LKS32 版几乎同构 STM32 vs LKS32 迁移对照表——别人走过的路就是你的地图 STM32 生态规模——为什么它的选择影响全行业 STM32CubeMX 生成工程 vs LKS32 手写工程——同一骨架两种来源深入 ESP32/Zephyr深入 ESP32 与 Zephyr——CMake 作为唯一构建系统ESP-IDF v5.0从 GNU Make 到 CMake 的强制迁移Zephyr RTOS — CMake 原生从第一天对比 ESP32 vs Zephyr vs STM32 — 三种 CMake 化路径本页大纲ESP32 与 Zephyr 的强制 CMake ESP-IDF v5.0 — Make 已被移除是 2022 年最大的行业宣言 Zephyr — 200 开发板一套构建系统的极端测试 从 RTOS 的强制 CMake学到什么 ESP-IDF 与 Zephyr 的构建命令全景对比——同一底层两种体验 从 Zephyr 的设备树看配置驱动构建——CMake 的终极形态LKS32 现状与机遇LKS32 的现状——官方仅 Keil但完整 CMake 移植存在凌鸥官方资源 vs 我们移植的 CMake 工程LKS32 CMake 移植的五步流程移植后的验证结果本页大纲LKS32 现状与机遇 凌鸥 LKS32 的现状——官方仅提供 Keil 工程️ 五步移植方案——本教程 58 课的总路线图 移植后的独特竞争力——为什么这件事值得做稀缺性理解深度可迁移性️ 官方 SDK 目录 vs 移植后目录——差异一目了然 LKS32 移植里程碑——58 课如何一步步走完各平台现状总览行业迁移现状嵌入式 CMake 化浪潮2018 年还只是一个趋势——2025 年已经是共识。从 MCU SDK 到 RTOS整个嵌入式生态正在全面转向 CMake。本课目标看清 2025 年各大 MCU 平台对 CMake 的支持现状理解为什么 STM32/ESP32/Zephyr 三巨头全部转向 CMake定位 LKS32 的现状——官方仅有 Keil但我们已完整移植各大平台 CMake 支持现状 — 2025 年平台CMake 支持状态说明STM32原生官方推荐STM32CubeMX 6.x 原生生成 CMakeLists.txt。全球最大 ARM MCU 生态转向 CMake。ESP32 (乐鑫)强制唯一构建系统ESP-IDF v5.0 彻底移除 GNU Make。Xtensa RISC-V 双架构统一 CMake。Zephyr RTOS强制唯一构建系统Linux 基金会旗下支持 200 开发板。第一天就是 CMake。NXP原生官方推荐MCUXpresso SDK 2023 年起提供 CMake 构建选项。Raspberry Pi Pico强制唯一构建系统Pico SDK 完全是 CMake 项目。官方文档全部以 CMake 为例。Nordic nRF强制唯一构建系统nRF Connect SDK 基于 Zephyr——本质是 CMake。凌鸥 LKS32无需自行移植官方仅提供 Keil 工程。本教程目的完整 CMake 移植方案。迁移时间线 2018 - 2025三大驱动力——为什么全行业都在转开源生态需求RTOSZephyr/FreeRTOS需要在所有平台上可构建。专有 IDE 无法满足——它们没有 CLI、不支持 Linux CI。CI/CD 压力现代软件工程要求每次 PR 自动编译验证。专有 IDE 的 GUI 无法在 CI 服务器上运行。多架构统一Cortex-M RISC-V Xtensa — 不能为每个架构维护一套独立的构建系统。CMake toolchain.cmake 一行切换。 结论2025 年开始一个嵌入式新项目——选择 CMake 不是创新是默认选项。继续用 Keil 管理构建配置是走在越来越窄的路上。本页大纲行业迁移全景① 七大平台 CMake 支持现状 → ② 迁移时间线 2018→2025 → ③ 三大驱动力深度解析 → ④ 平台支持矩阵 SVG → ⑤ 交互点选平台看迁移详情 CMake 化浪潮全景——7 大平台一图看清⏳ 迁移时间线深度解析——四个关键转折点时间事件为什么重要2018 Q2STM32CubeMX 放弃 SW4STM32最大 ARM MCU 厂商表态——行业第一个重大信号2020 Q3Zephyr 2.3 LTS 发布Linux 基金会 RTOS 证明 CMake 在 RTOS 级别可行2022 Q4ESP-IDF v5.0 移除 Make全球销量最大 Wi-Fi MCU 全面 CMake 化2023-25ARM 生态全面转向NXP/Nordic/Renesas 全支持——CMake 成为默认选项 看懂这个时间线的规律每一次迁移都遵循同一模式先是大厂表态 → 然后是开源社区跟进 → 最后全行业默认。LKS32 还在官方仅 Keil阶段——你现在学的正是下一波浪潮的入场券。 三大驱动力的深度拆解——为什么转是必然 一句话总览2025 年选 CMake 不是创新是*“跟随行业共识”*。今天你不学明天换工作、换项目、换芯片时CMake 会来找你。 行业迁移状态总表——把你的芯片对号入座平台CMake 地位迁移时间驱动原因你的行动STM32原生2018 起官方表态 生态压力学会读官方模板ESP32强制2022 v5.0多架构统一理解 idf.py 封装Zephyr强制第一天200 板卡管理学习配置驱动思想Pico强制2021 发布起官方设计决策验证 CMake 普及度Nordic强制2020 起基于 Zephyr同上NXP原生2023 起跟随 ST 步伐同上凌鸥 LKS32无—官方仅 Keil你正在做 对号入座结论7 大平台中 5 个强制/原生CMake、1 个原生、只有 LKS32 是空白。你不是在学一个冷门工具——你是在填补国产芯片生态里最后一块空白。深入 STM32深入 STM32全球最大 ARM MCU 生态的 CMake 化ST 的 CMake 化策略是双向兼容——既保留传统 IDE 工程又原生生成 CMakeLists.txt。STM32CubeMX 6.x 默认勾选Generate CMake project。STM32CubeMX 生成的 CMakeLists.txt简化示例cmake_minimum_required (VERSION 3.20 ) project (stm32f103_blinky C ASM) # CubeMX 自动添加所有源文件 add_executable ( ${PROJECT_NAME} .elf) target_sources ( ${PROJECT_NAME} .elf PRIVATE Core/Src/main.c Core/Src/stm32f1xx_it.c Core/Src/gpio.c Core/Src/usart.c Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio.c Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_rcc.c ... (CubeMX 自动列出所有用到的 HAL 文件) ) target_include_directories ( ${PROJECT_NAME} .elf PRIVATE Core/Inc Drivers/STM32F1xx_HAL_Driver/Inc Drivers/CMSIS/Device/ST/STM32F1xx/Include Drivers/CMSIS/Include ) target_compile_definitions ( ${PROJECT_NAME} .elf PRIVATE USE_HAL_DRIVER STM32F103xB )STM32 的迁移意义层面意义用户量STM32 是全球出货量最大的 Cortex-M 系列 MCU。它的 CMake 化意味着数以百万计的开发者从 Keil/IAR 转向 CMake。生态影响CubeMX 的 CMake 输出成为了嵌入式 CMake 的标准写法——其他厂商的 SDK 借鉴了它的 target_sources target_include_directories 模式。工具链ST 推荐 arm-none-eabi-gcc 而非 ARMCC。这意味着从 STM32 开始GCC 成为 Cortex-M 开发的事实标准编译器。 这跟 LKS32 有什么关系LKS32MC033 也是 Cortex-M0——和 STM32F0 使用的是完全相同的 arm-none-eabi-gcc 工具链。STM32 的 CMake 模式可以直接借鉴到 LKS32 的移植中。本页大纲深入 STM32 迁移① STM32CubeMX 为什么放弃自家 IDE → ② CubeMX 生成 CMake 的完整流程 → ③ 生成的 CMakeLists.txt 结构解剖 → ④ 交互CubeMX 生成流程模拟 → ⑤ STM32 与 LKS32 的对照启示 STM32 的转身——最震撼的行业信号2018 年ST 官方宣布停止维护 System WorkbenchSW4STM32/AC6——这是基于 Eclipse 的免费 IDE。理由很直接开发者要的是构建系统不是IDE 锁定。STM32CubeMX 从 6.0 开始原生生成 CMakeLists.txt全球最大的 ARM MCU 生态正式拥抱 CMake。 CubeMX 生成的 CMakeLists.txt 结构——和你将要写的 LKS32 版几乎同构# CubeMX 生成简化 cmake_minimum_required(VERSION 3.20) project(stm32f103c8t6 LANGUAGES C ASM) add_compile_definitions(STM32F103xB USE_HAL_DRIVER) ← 宏定义 # 收集源文件 file(GLOB_RECURSE HAL_SOURCES Drivers/STM32F1xx_HAL_Driver/Src/*.c) file(GLOB_RECURSE CORE_SOURCES Core/Src/*.c Drivers/CMSIS/Device/*.c) add_executable(${PROJECT_NAME}.elf ${HAL_SOURCES} ${CORE_SOURCES}) # 链接脚本 启动文件 target_link_options(${PROJECT_NAME}.elf PRIVATE -TSTM32F103C8Tx_FLASH.ld) target_sources(${PROJECT_NAME}.elf PRIVATE startup_stm32f103xb.s) # POST_BUILD 生成 .hex/.bin第 18 课详解 add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD COMMAND ${CMAKE_OBJCOPY} -O ihex ... .hex) 对照你的 LKS32 项目你会发现 CubeMX 生成的 CMakeLists.txt 与第 28 课要讲的 LKS32 顶层 CMakeLists.txt骨架几乎一样project() → 宏定义 → 收集源文件 → add_executable → 链接脚本 → POST_BUILD。学会一套所有厂商通用。 STM32 vs LKS32 迁移对照表——别人走过的路就是你的地图维度STM32已迁移LKS32本教程官方 SDKCubeMX 原生生成 CMake仅 Keil 工程迁移难度低——官方已支持中——需手写 CMakeLists 移植启动文件工具链arm-none-eabi-gccarm-none-eabi-gcc同一套调试J-Link/ST-Link GDBJ-Link GDB第 42-46 课你的收益学会看官方模板学会从零构建——理解更深 最关键的认知STM32 开发者用 CubeMX“一键生成”CMake 工程但他们常常不理解生成的配置。你手把手把 LKS32 从 Keil 移植成 CMake——你对构建的理解比大多数 STM32 开发者更深。这份理解就是迁移任何芯片的通用能力。 STM32 生态规模——为什么它的选择影响全行业 STM32CubeMX 生成工程 vs LKS32 手写工程——同一骨架两种来源对比维度STM32CubeMX 生成LKS32 手写本教程CMakeLists 来源工具自动生成手写第 28 课逐行理解深度生成即用未必懂逐行理解全链路掌握启动文件自动生成 .s手写移植 startup.S第 49 课链接脚本自动生成 .ld手写移植第 25-26 课学习曲线低门槛高天花板高投入高回报 定位差异CubeMX 适合快速启动产品开发本教程适合想彻底掌握构建系统的你。两条路殊途同归——都会落到同一份 CMake 语法上。深入 ESP32/Zephyr深入 ESP32 与 Zephyr——CMake 作为唯一构建系统如果说 STM32 的 CMake 化是兼容性过渡那么ESP32 和 Zephyr 的 CMake 化就是断腕式革命——它们彻底移除了旧的构建系统CMake 是唯一选项。ESP-IDF v5.0从 GNU Make 到 CMake 的强制迁移乐鑫在 2022 年做了一个激进但正确的决定在 ESP-IDF v5.0 中完全移 GNU Make 支持。所有 ESP32/ESP32-S/ESP32-C 系列覆盖 Xtensa 和 RISC-V 两种 CPU 架构统一使用 CMake。 迁移成功的原因ESP-IDF 的 CMake 化不是简单的替换构建系统——而是配合 idf.py 命令行工具提供了一个完整的开发体验。所有这些命令底层都调用 CMake。Zephyr RTOS — CMake 原生从第一天Zephyr 从一开始就以 CMake 为核心。它的构建系统非常复杂——支持 200 开发板、多架构ARM/RISC-V/x86/ARC、设备树DeviceTree、Kconfig 配置系统。这证明了CMake 可以胜任最复杂的嵌入式构建场景。# 构建 Nordic nRF52840 开发板的 blinky 示例 west build -b nrf52840dk_nrf52840 samples/basic/blinky # west 底层调用 # cmake -B build -DBOARDnrf52840dk_nrf52840 # cmake --build buildZephyr 特性CMake 如何支撑200 开发板每个板级支持包是一个 CMake 模块通过 BOARD 变量选择设备树 (DeviceTree)CMake 调用 dtc 编译 .dts - .dtb链接到固件Kconfig 配置CMake 调用 kconfig 工具生成 autoconf.h 宏定义多架构toolchain.cmake 自动切换 ARM/RISC-V/x86 GCC对比 ESP32 vs Zephyr vs STM32 — 三种 CMake 化路径平台CMake 化方式激进程度对用户的冲击STM32CubeMX 同时生成 CMake Keil/IAR 工程温和过渡低——用户可自由选择ESP32ESP-IDF v5.0 移除 Make仅 CMake激进革命高——旧 Makefile 工程必须重写Zephyr从第一天就是 CMake无历史包袱无——用户从一开始就用 CMake本页大纲ESP32 与 Zephyr 的强制 CMake① ESP-IDF v5.0 移除 Make 的来龙去脉 → ② Zephyr 的 CMake 构建系统架构 → ③ 强制 CMake 意味着什么 → ④ 交互两平台构建命令对比 → ⑤ 从 RTOS 学到什么 ESP-IDF v5.0 — Make 已被移除是 2022 年最大的行业宣言2022 年 11 月乐鑫发布 ESP-IDF v5.0彻底移除 GNU Make 构建系统——CMake 成为唯一官方构建方式。这意味着所有旧教程失效、所有旧项目要迁移、所有第三方库要更新。一个商业公司为了长期健康敢做破坏性决策——这本身就是信号CMake 不是可选项是唯一选项。# ESP-IDFv5.0—— idf.py 是 CMake 的封装 $ idf.py set-target esp32s3 $ idf.py build # 内部就是 cmake --build $ idf.py flash # 内部就是 esptool 烧录 # Zephyr—— west 是 CMake 的封装 $ west build -b nucleo_f103rb samples/hello_world $ west flash # 内部也是 cmake 烧录器 # 本质两者底层都是 CMake $ cmake --preset default # 你将在第 33-35 课掌握的技能 Zephyr — 200 开发板一套构建系统的极端测试Zephyr RTOS 支持200 开发板、多种架构ARM/RISC-V/Xtensa/SPARC。如果用传统 IDE每个板子一套工程——不可维护。Zephyr 的选择一套 CMake 构建系统 每个板子一个配置文件。 从 RTOS 的强制 CMake学到什么学到的认知具体含义CMake 是底层引擎idf.py/west 只是 CMake 的人性化封装——懂 CMake 就能看懂任何框架的构建配置与代码分离板卡差异 配置文件差异toolchain/设备树不是代码差异学习投资回报高学一次 CMakeZephyr/ESP-IDF/STM32/LKS32 全部通用封装不可怕封装下面是标准 CMake——出问题时剥开看本质 本页小结ESP-IDF 与 Zephyr 的强制 CMake证明当生态复杂到一定程度多架构、多板卡、多厂商唯一可行的构建方案就是 CMake。LKS32 的复杂度虽低但方向一致——你现在打的地基未来能盖任何楼。 ESP-IDF 与 Zephyr 的构建命令全景对比——同一底层两种体验 从 Zephyr 的设备树看配置驱动构建——CMake 的终极形态Zephyr 用 **设备树DTS**描述硬件——每个板卡的引脚、外设、时钟全部写在配置文件里。CMake 读取设备树 Kconfig自动决定编译哪些驱动。这就是配置驱动构建的极致硬件差异全部下沉到配置文件代码零改动。// boards/arm/nucleo_f103rb/nucleo_f103rb.dts uart1 { status okay; ← 使能 UART1 current-speed 115200; ← 波特率 }; spi1 { status okay; ← 使能 SPI1 cs-gpios gpioa 4 GPIO_ACTIVE_LOW; ← CS 引脚 }; 对照你的 LKS32本教程第 35 课多芯片 Presets用的就是同一思想的简化版用 CMakePresets option() 把芯片差异配置化。Zephyr 是终极形态你的 LKS32 是入门形态——但核心思想一致配置与代码分离。LKS32 现状与机遇LKS32 的现状——官方仅 Keil但完整 CMake 移植存在凌鸥官方为 LKS32MC033 提供的开发资源是Keil Pack.pack 压缩包。没有官方的 CMake 支持。这正是本教程的独特价值所在。凌鸥官方资源 vs 我们移植的 CMake 工程官方提供格式我们的移植Keil Pack.pack 压缩包LKS03x v1.1.8提取 CMSIS HAL 源文件 - CMake 工程.uvprojx 工程Keil 二进制 XML重写为 CMakeLists.txt CMakePresets.json toolchain.cmakestartup_xxx.sARMCC 汇编语法AREA/DCD/PROC重写为 GCC 汇编语法.section/.word/.type- startup_lks32mc03x.S链接脚本 .sctScatter FileARMCC 专用重写为 .ldGNU Linker 语法- lks32mc03x.ldnvr.libARMCC 预编译库闭源重写为 lks32mc03x_nvr_gcc.cGCC 源码实现 Read_TrimJ-Link 设备注册手动添加到 JLinkDevices.xml同官方方法——已配置好 LKS32MC033 条目LKS32 CMake 移植的五步流程移植后的验证结果 这就是本教程的价值我们不仅教你 CMake 语法——我们给你一个完整可运行的 LKS32 CMake 工程从 Keil 完全迁移到了 GCCCMake 生态系统。Flash 仅用 3.91%——还有 96% 空间留给你加功能。本页大纲LKS32 现状与机遇① 凌鸥官方的现状——仅 Keil → ② 这不是落后是机会 → ③ 五步移植方案总览 → ④ 交互移植前后对比 → ⑤ 移植后你的独特竞争力 凌鸥 LKS32 的现状——官方仅提供 Keil 工程打开凌鸥官方 SDK 下载页所有示例工程都是 .uvprojxKeil 格式。没有 CMake、没有 GCC 工程、没有 Linux 支持。对大多数用户这不是问题——“Keil 能用就行”。但这也意味着所有依赖自动化、CI、跨平台的现代工作流LKS32 生态都无法直接享受。️ 五步移植方案——本教程 58 课的总路线图步骤内容做什么对应课程1搭环境MSYS2 GCC CMake Ninja第 05-08 课2建骨架七层目录 顶层 CMakeLists toolchain第 19-22、27-29 课3移植代码启动文件 .s→.S、.sct→.ld、HAL 编译第 25-26、48-51 课4接调试VSCode J-Link Cortex-Debug第 36-46 课5上自动化Presets tasks CI/CD第 33-35、47、55 课 好消息官方 SDK 的HAL 驱动源码、寄存器定义、外设库都是跨编译器的——Keil 工程里的 .c/.h 可以直接复用只需要改写启动文件、链接脚本、构建配置这三样。第 48 课会详细讲移植对照。 移植后的独特竞争力——为什么这件事值得做稀缺性全网络搜LKS32 CMake几乎零结果——你做完就是先驱你的工程就是别人的参考理解深度从零移植逼你理解启动、链接、编译全链路——比一键生成开发者理解深得多可迁移性这份移植能力能套用到任何只有 Keil 工程的国产芯片——你的技能边界远超 LKS32 本页小结LKS32 官方没做 CMake不是落后是*“把机会留给了你”*。你现在学的不只是构建工具——是国产芯片生态里稀缺的现代构建能力。️ 官方 SDK 目录 vs 移植后目录——差异一目了然LKS32MC03x_Demo/ ├── LKS32MC03x.uvprojx ← 唯一的构建入口 ├── User/ │ ├── main.c │ └── lks32mc03x_it.c ├── Drivers/ │ ├── CMSIS/ (头文件) │ ├── Device/ (startup system) │ └── HAL/ (18 外设 .c) └── config/ └── lks32mc03x.hlks32-cmake/ ├── CMakeLists.txt ← 顶层构建入口 ├── cmake/toolchain.cmake ← 工具链 ├── CMakePresets.json ← 预设 ├── app/ (main.c) ├── bsp/ (led/delay) ├── drivers/ │ ├── CMSIS/ │ ├── Device/ │ └── HAL/ ├── .vscode/ (settings/launch) └── build/ (自动生成) 关键差异左边的工程构建入口是.uvprojx需 Keil 解析右边是CMakeLists.txt纯文本任何工具可读。源码几乎没动动的是构建方式——这正是移植的全部含义。 LKS32 移植里程碑——58 课如何一步步走完