企业官网建设流程全解析

摘要：2025 年，嵌入式行业已全面转向CMake，从 STM32 到 ESP32、Zephyr，七大主流平台均已原生支持或强制采用。本文逐一对比各平台现状，并聚焦国产芯片LKS32的独特机遇——官方虽仅提供 Keil 工程，但通过完整的移植方案，我们已成功将其接入 CMake 生态，填补国产芯片构建体系的最后一块空白。

各平台现状总览

行业迁移现状：嵌入式 CMake 化浪潮

2018 年还只是一个趋势——2025 年已经是共识。从 MCU SDK 到 RTOS，整个嵌入式生态正在全面转向 CMake。

本课目标

• 看清 2025 年各大 MCU 平台对 CMake 的支持现状

• 理解为什么 STM32/ESP32/Zephyr 三巨头全部转向 CMake

• 定位 LKS32 的现状——官方仅有 Keil，但我们已完整移植

各大平台 CMake 支持现状 — 2025 年

迁移时间线 2018 -> 2025

三大驱动力——为什么全行业都在转

开源生态需求

RTOS（Zephyr/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 大平台一图看清

⏳ 迁移时间线深度解析——四个关键转折点

💡 看懂这个时间线的规律每一次迁移都遵循同一模式：先是大厂表态 → 然后是开源社区跟进 → 最后全行业默认。LKS32 还在"官方仅 Keil"阶段——你现在学的，正是下一波浪潮的入场券。

🧲 三大驱动力的深度拆解——为什么"转"是必然

💡 一句话总览2025 年选 CMake 不是"创新"，是*“跟随行业共识”*。今天你不学，明天换工作、换项目、换芯片时，CMake 会来找你。

📋 行业迁移状态总表——把你的芯片对号入座

💡 对号入座结论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 的迁移意义

💡 这跟 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 Workbench（SW4STM32/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 -T"STM32F103C8Tx_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 开发者用 CubeMX“一键生成”CMake 工程，但他们常常不理解生成的配置。你手把手把 LKS32 从 Keil 移植成 CMake——你对构建的理解比大多数 STM32 开发者更深。这份理解，就是迁移任何芯片的通用能力。

📊 STM32 生态规模——为什么它的选择影响全行业

🧩 STM32CubeMX 生成工程 vs LKS32 手写工程——同一骨架，两种来源

💡 定位差异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 -DBOARD=nrf52840dk_nrf52840 # cmake --build build

对比 ESP32 vs Zephyr vs STM32 — 三种 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-IDF（v5.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"学到什么

💡 本页小结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 工程

LKS32 CMake 移植的五步流程

移植后的验证结果

💡 这就是本教程的价值我们不仅教你 CMake 语法——我们给你一个完整可运行的 LKS32 CMake 工程，从 Keil 完全迁移到了 GCC+CMake 生态系统。Flash 仅用 3.91%——还有 96% 空间留给你加功能。

本页大纲：LKS32 现状与机遇

① 凌鸥官方的现状——仅 Keil → ② 这不是"落后"，是"机会" → ③ 五步移植方案总览 → ④ 交互：移植前后对比 → ⑤ 移植后你的独特竞争力

🔴 凌鸥 LKS32 的现状——官方仅提供 Keil 工程

打开凌鸥官方 SDK 下载页：所有示例工程都是 .uvprojx（Keil 格式）。没有 CMake、没有 GCC 工程、没有 Linux 支持。对大多数用户这不是问题——“Keil 能用就行”。但这也意味着：所有依赖自动化、CI、跨平台的现代工作流，LKS32 生态都无法直接享受。

🗺️ 五步移植方案——本教程 58 课的总路线图

💡 好消息官方 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.h

lks32-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 课如何一步步走完