🧱 按照“是否可独立工作”来分：
| 库/方式 | 是否可独立使用 | 是否依赖其他库 | 说明 |
|---|---|---|---|
| 寄存器裸写 | ✅ 是 | ❌ 无 | 完全自主控制，无库依赖 |
| 标准库（StdPeriph） | ✅ 是 | ❌ 只依赖 CMSIS | 自成体系（F1专属），只用 CMSIS 的 IRQ 宏等 |
| LL 库 | ✅ 是 | ✅ 依赖 CMSIS 和 startup 文件 | 官方 LL 是基于 CMSIS 和 startup 的 |
| HAL 库 | ✅ 是 | ✅ 依赖 LL（部分）、CMSIS、SysInit | 功能封装度高，常配合 CubeMX 自动生成 |
| CMSIS | ✅ 是 | ❌ 无 | ARM 官方标准，常作为基础层存在 |
| CubeMX | ❌ 不是库 | ✅ 生成 HAL/LL 工程 | 它是生成器，不是库本身 |
| libopencm3 | ✅ 是 | ❌ 自成体系 | 社区库，不依赖 HAL/LL，结构清晰 |
| RTOS（如FreeRTOS） | ✅ 是 | ✅ 通常需要 HAL/LL 支撑底层驱动 | 适用于复杂项目，可以配合 HAL/LL/裸写等 |
| 你自定义的 FSM 驱动 | ✅ 是 | ❌ 看你是否封装在库上 | 可自由封装 HAL/LL/裸写，根据风格决定 |
✅ 总结为一句话：
开发项目时，可以只选用一种库（HAL、LL、裸写等）完成全部功能，不需要混用。
但这些库在内部可能间接依赖更底层的库（比如 CMSIS），这不是问题，你只要知道它存在即可。
🔍 举几个典型开发方式：
🧱 方式 1：纯裸写 + CMSIS（高级硬件控制）
你只包含这几个文件：
-
startup_stm32f10x.s（中断向量表） -
system_stm32f10x.c（时钟初始化） -
<core_cm3.h>（CMSIS 核心支持） -
你自己的
main.c
👉 适合需要极致控制/不依赖任何外部库的场景
🧱 方式 2：标准库（F1）单独用
你包含：
-
CMSIS（自动包含）
-
stm32f10x_gpio.c、stm32f10x_rcc.c等标准库模块 -
自己写的业务逻辑
👉 不需要 HAL，也不依赖 LL，适合 F1 系列使用者
🧱 方式 3：HAL 工程（CubeMX 一键生成）
CubeMX 帮你生成完整结构，包含：
-
HAL 层：
stm32f1xx_hal_gpio.c等 -
底层支持文件：
system_stm32f1xx.c、startup_stm32f103xb.s -
中间层调用 LL（部分 HAL 会内部用 LL 实现）
👉 适合快速开发和团队协作项目
🧠 使用推荐：
| 你的目标 | 推荐策略 |
|---|---|
| 学懂原理、掌控底层 | ✅ 选择标准库 或 LL 库，能看到寄存器 |
| 做出可靠 BLE 模块系统 | ✅ 用 LL 构建 FSM、状态机调度、事件队列等 |
| 掌控全局，不迷失库内部 | ✅ 明确库的层级依赖，但不盲目混用 |
| 后续做产品或模块输出 | ✅ 可用 LL+部分 HAL，便于接口封装 |
)
