【开源分享】用一套 C++ 接口打通 Linux 与多种 RTOS：`dp_sdk_core` 的设计价值

GitHub：https://github.com/KaminDeng/dp_sdk_core

很多嵌入式项目一开始推进很快：
先在 Linux 主机上把业务流程跑通，再迁移到 MCU；先支持一块板卡，再扩展到更多硬件形态；先用一种 RTOS 完成开发，后续再考虑可移植性。

真正的困难通常不在于“第一版能不能跑起来”，而在于：

平台变化出现以后，业务代码还能不能保持稳定；
Linux 与不同 RTOS 下的编程接口能不能尽量统一；
换板卡、换芯片、换系统时，改动能不能集中在少数边界内；
C++ 抽象在 MCU 上能不能既保留表达力，又不至于失控。

dp_sdk_core 要解决的，正是这些问题。
它不是为了“再包一层接口”，而是试图为嵌入式系统建立一套更适合长期演进的核心层。

一、它真正的价值，不只是“跨平台”

dp_sdk_core 由三个核心模块组成：

模块	关注点	作用
`dp_osal`	OS 抽象	统一线程、互斥锁、队列、定时器、信号量等系统原语
`dp_hal`	硬件抽象	统一 UART、GPIO、SPI、I2C、ADC、PWM 等外设接口
`dp_device`	设备管理	统一设备注册、查找、打开/关闭与生命周期管理

依赖关系非常克制：

device  ->  hal   (public)
device  ->  osal  (private)
hal     ->  independent
osal    ->  POSIX / CMSIS-OS backend

这个结构的意义，不只是“拆了三个模块”，而是它给变化划了边界：

OS 差异收敛到 dp_osal
硬件差异收敛到 dp_hal
设备生命周期收敛到 dp_device

对于长期演进的嵌入式项目来说，这种边界感比“某个驱动封装得多快”更重要。

二、通过 CMSIS-OS 适配多种 RTOS，把 Linux 与 RTOS 的接口体验拉齐

这是 dp_sdk_core 最值得强调的特征之一。

很多嵌入式项目并不是不能支持多个系统，而是：

Linux 上用一套线程与同步模型；
FreeRTOS 上又是一套风格；
换成 RT-Thread 或 Zephyr 后，还要重新适应和改写；
上层业务虽然逻辑相近，却很难共享同一套编程方式。

dp_sdk_core 的做法不是把每一种 RTOS 的原生 API 暴露给上层业务，而是先通过 dp_osal 稳定住上层系统编程模型，再通过 CMSIS-OS 接口向下收敛不同 RTOS。

这意味着：

业务层主要面向统一 OSAL 接口编写；
RTOS 差异被集中到适配层，而不是扩散到业务层；
只要能够适配到 CMSIS-OS 接口的 RTOS，理论上都可以纳入这一模型。

项目已在 FreeRTOS、RT-Thread、Zephyr 等环境中完成适配与验证。
这使它的价值不只是“支持多 RTOS”，而是用一套统一接口拉齐 Linux 与多种 RTOS 下的编程方式。

三、从分层结构上看，它解决的是“变化应该被放在哪里”

dp-sdk-core-arch.

这张图最重要的，不只是分层，而是它在说明几个工程事实：

应用逻辑尽量保持稳定上层业务依赖核心抽象，而不是直接依赖平台 API。
OS 差异收敛在 dp_osalLinux / POSIX 和 RTOS 两个世界，通过统一 OSAL 接口向上表达能力。
硬件差异收敛在 dp_halUART、GPIO、SPI、I2C 等具体实现，不再直接侵入业务代码。
设备生命周期收敛在 dp_device注册、查找、打开/关闭和统一管理不再散落在各个模块里。

跨平台工程最怕的不是有差异，而是差异没有边界。
dp_sdk_core 的价值，正是把这些最容易失控的变化源分别收进明确边界里。

四、从工程演进上看，它让系统迁移和产品扩展更可控

相比架构图，这张迁移图更接近项目在工程落地时的真实价值。

左边是很多嵌入式项目常见的状态：

业务逻辑、RTOS API、厂商 HAL、设备初始化顺序混在一起；
功能虽然能跑，但一旦换系统、换硬件、换产品配置，改动会迅速扩散。

右边则是 dp_sdk_core 试图建立的状态：

上层业务依赖稳定契约；
OS 差异通过 POSIX / CMSIS-OS 路径收敛；
硬件差异通过 HAL port 收敛；
设备管理通过 Device 层收口。

这也是它特别适合从 demo 阶段走向产品线阶段的原因。
demo 阶段追求“尽快跑通”，产品线阶段追求“变化可控”。

五、它不仅强调抽象，更强调 C++ 接口本身的工程价值

很多嵌入式抽象层最终都只剩下一层“把 C API 换个名字再包一遍”的薄封装。表面上用了 C++，实际上既没有明显提升表达力，也没有很好控制成本。

dp_sdk_core 更值得关注的地方，在于它没有放弃 C++ 的工程价值。

1. 生产路径优先使用 CRTP，而不是默认全虚接口

在 dp_osal 与 dp_hal 中，很多核心接口采用 CRTP。

这样做的意义不是为了“模板化”，而是为了让实现类型在编译期确定：

高频路径更容易被编译器内联；
接口层不默认引入 vtable；
抽象能力被保留，但不会自动变成运行时负担。

这对 MCU 很重要，因为抽象层最怕一开始就把运行时成本铺满所有路径。

2. 需要测试注入时，再使用虚接口包装

项目同时提供了 dp_osal_virtual.h 和 dp_hal_virtual.h，用于 host 侧注入与 GMock。

这说明它的思路非常清楚：

生产 / 量产路径优先使用 CRTP；
host 测试路径在真正需要 mock 时再切到虚接口包装。

也就是说，测试能力被保留了，但测试相关的运行时成本没有被默认摊到所有固件路径上。

3. 这是“有节制地使用现代 C++”

从工程角度看，它体现了几类非常适合长期维护的 C++ 特性：

类型化接口，而不是到处透传裸指针；
RAII 风格封装，如锁守卫；
模板与编译期开关配合，适合做裁剪与移植；
接口与实现分层清晰，更适合多人协作。

所以，dp_sdk_core 的特点不是“用了 C++17”这么简单，而是把 C++ 的表达力放在接口设计上，同时把额外代价控制在可接受范围内。

六、`dp_device` 解决的是后期最容易失控的设备生命周期问题

很多嵌入式项目初期会把注意力集中在驱动能不能工作，很少一开始就认真设计“设备生命周期管理”。

等项目规模变大以后，这类问题才会集中暴露：

设备初始化顺序开始混乱；
某些模块重复打开设备，某些模块提前关闭设备；
名称和类型约束全靠人工约定；
设备越来越多，查找、注册、清理逻辑散落在各处。

dp_sdk_core 把这件事单独抽出来做成了 dp_device：

Device 基类统一名称、类型和 open/close 引用计数；
DeviceManager 统一注册、查找、遍历和注销；
设备表使用固定数组，有明确上限；
通过 DeviceType 做类型管理，不依赖 RTTI；
访问过程可由 OSAL 同步能力保护。

这类设计也许不像驱动优化那样“醒目”，但它对长期维护非常关键。
因为它让设备管理从“大家默认知道怎么用”变成“框架明确规定怎么用”。

七、它对资源成本的处理方式，是“可控”，而不是“假装没有成本”

这一点非常重要。

很多嵌入式抽象层喜欢强调优雅、统一、现代化，却不愿正面回答一个关键问题：这些抽象到底增加了多少成本，哪些场景适合，哪些场景不适合。

dp_sdk_core 的处理方式更务实。它没有把所有路径都宣传成“零成本”，而是通过架构设计，把成本控制在可分析、可裁剪、可验证的范围内。

1. 哪些成本被压下来了

dp_hal 以 header-only + CRTP 为主，目标是在编译期消解大部分抽象成本；
dp_osal 的核心接口不是默认全虚函数；
dp_device 使用固定大小数组，而不是默认走堆分配；
类型管理尽量不依赖 RTTI。

2. 哪些成本被正面承认了

线程、线程池、定时器这类能力，本来就不是“免费”的；
一旦引入 std::function、同步对象和状态管理，就需要认真评估 RAM / Flash 开销；
如果为了 host 测试切到虚接口包装，那么运行时分发成本也会随之出现。

这种表述比“抽象层没有代价”更可信。

3. 单片机可行性表，本身就很能说明问题

目标芯片	可行性	说明
Cortex-M4 / M7，RAM ≥ 192 KB（建议带 CCM）	✅ 当前全量测试配置可行	已有构建与验证基础
Cortex-M3 / 小内存 M4，RAM 64–128 KB	⚠️ 仅在强裁剪下可行	必须关闭 `test_all`，减少功能并重新量化
Cortex-M0 / M0+，RAM ≤ 64 KB	❌ 当前配置不可直接宣称可用	需要 tiny 配置与实测数据支撑

这张表的意义不只是“给结论”，更重要的是它体现出一种工程态度：

不是所有 MCU 都适合同一套配置；
架构价值并不等于忽略硬件资源边界；
抽象层是否可用，必须结合目标配置、裁剪策略和实测结果来判断。

所以，dp_sdk_core 对资源问题的处理方式，不是“没有成本”，而是用 CRTP、固定资源上限、裁剪开关和平台验证，把成本控制在可以判断和权衡的范围内。

八、它最适合的工作流，是先在 Linux 上验证，再平滑落到 RTOS 和硬件平台

从项目结构和接口设计来看，dp_sdk_core 很适合下面这种开发路径：

在 Linux / POSIX 环境先把核心业务逻辑跑通；
使用统一的 OSAL / HAL 接口保持上层编程方式稳定；
通过 CMSIS-OS 适配把不同 RTOS 纳入统一模型；
最后切换到具体硬件实现，在 MCU 上完成联调与资源测量。

这条路径的价值很直接：

业务逻辑可以更早在 host 侧验证；
Linux 与 RTOS 下的编程体验更接近；
换板卡、换系统时，改动更集中；
团队能把“业务验证”“RTOS 适配”“硬件移植”纳入一条更一致的工程路径。

九、哪些团队会更适合这类核心层

如果你的项目符合下面这些条件，这类架构会更容易体现价值：

业务逻辑需要同时覆盖 Linux 仿真与 MCU 实机；
产品需要支持多个 RTOS 或多个硬件平台；
团队已经为平台胶水代码付出明显维护成本；
希望在 C++17 嵌入式项目中建立长期可复用的基础层；
希望 Linux 与多 RTOS 之间的接口体验尽量统一。

相反，如果项目是一次性固件、周期很短、平台完全固定，那么自己写一套轻量平台层也未必不行。

dp_sdk_core 的价值，更体现在长期演进，而不是一次性跑通。

十、结语

dp_sdk_core 最值得关注的，不只是它封装了线程、串口、GPIO 这些常见能力，而是它把几个最容易在嵌入式项目中失控的问题放进了同一个清晰框架里：

Linux 与多种 RTOS 下如何保持更一致的编程接口；
不同 RTOS 如何通过 CMSIS-OS 收敛到统一模型；
硬件差异如何通过 HAL port 收敛；
设备生命周期如何统一管理；
C++ 接口如何兼顾表达力与资源成本控制。

从这个角度看，它的价值不是“又一套抽象层”，而是为跨 Linux / RTOS / 硬件平台的嵌入式开发提供一套更稳定、更统一、更可演进的工程基础。