介绍一个基于消息驱动的嵌入式软件框架

大家好，我是杂烩君。

今天我们来介绍一个基于消息驱动的软件框架——Yearnext Software Framework（YSF）。

https://gitee.com/accumulatedidea/Framework_Open

1. YSF简介

YSF 全称 Yearnext Software Framework，定位是基于消息驱动的单片机软件框架，强调配置简便、跨平台、可裁剪。

如果你关心这几件事，值得翻一翻——

想把「板级驱动」和「业务逻辑」拆开，换板时知道该动哪一层资源紧张的 MCU，想看协作式调度 + 消息队列，而不是一上来上 FreeRTOS想对照一套现成的fw_conf.h 裁剪思路不一定适合所有人。若你已经在成熟 RTOS / 厂商中间件上跑产品，它更像架构参考，而不是替代方案。

平台也不止 README 里写的 ARM。

目录和配置里能看到 8051、STM8、STM32、新唐、HC32、i.MX RT，以及 MSVC 仿真等；换板前先看自己的编译器和 BOARD_PALTFORM 有没有现成包。

仓库顶层大致是：compiler、hal、kernel、component、3rdparty、bsp、protocol、utility、document。

仿真工程适合先在 PC 上摸调度与消息路径，真板再补 MSP 与引脚。

2. 五层怎么读

文档写「五层」，容易和「应用层」两个字拧在一起。按职责拆开更清楚：

硬件层 → 硬件抽象层（HAL）→ 功能模块层 → 业务逻辑层 → 应用处理层

其中后两层合起来常叫应用层：业务逻辑写协议、状态、具体功能；应用处理层负责把产生的消息派发到对应模块。

换板时优先动 HAL/MSP，尽量别让业务代码直接绑死寄存器级类型。

2.1 硬件层

就是板载硬件：MCU、外设、引脚。框架不「神奇地」代替你做原理图，只要求上层通过统一接口下去。

2.2 硬件抽象层

HAL 负责把底层驱动收成统一接口，方便上层调用。它大致三块：

编译器拓展包：框架专用宏、基础类型等，覆盖 Keil、IAR、SDCC、GCC、MSVC 等

MCU 支持包（MSP）：把原厂驱动接到统一的 MSP API

通用外设驱动包：复杂外设的工作机制

MSP 又拆成 LV0 / LV1，这是小容量平台上很实际的取舍：

LV0：贴近芯片，可直接操作底层，常出现原厂类型（例如 GPIO_TypeDef*）。占用小，上层可移植性弱

LV1：标准抽象接口，把通用设备信息转成 LV0 专用信息再落硬件。可移植性更好，占用通常更大

先别急着全上 LV1。Flash/RAM 紧、业务也不换平台时，LV0 往往更现实；真要跨芯片复用业务代码，再把调用面上抬到 LV1。

2.3 功能模块层

这一层是「框架能帮你省什么」的主体，分三块：

框架内核：小型协作式任务调度，内建定时器、事件、消息队列、状态机等；还可选 Protothread。注意有 Full 与 Nano 两套实现，设计思路接近，但 API 互不兼容，在 fw_conf.h 里选版本

功能组件（component）：链表、环形缓冲区、CRC/校验和、查表、位操作等常用库

开源组件（3rdparty）：例如 SEGGER RTT、CmBacktrace、EasyLogger，以及 FatFs、SPIFFS、SimpleGUI、LVGL 等（按需编进工程即可）

消息驱动的主路径可以粗记：硬件或定时产生事件 → 内核排队 → 应用处理层派发 → 业务模块处理。

协作式意味着任务要主动让出；长时间死循环占着 CPU，别的任务就饿着——这和抢占式 RTOS 不是一回事，写简历或对标时别混称。

2.4 应用层怎么串起来

业务逻辑层：协议栈、设备状态、具体功能实现。仓库里 protocol 目前能看到如 xymodem 一类协议代码，文档里该目录仍标着待补充——用的时候以源码为准。

应用处理层：把消息派到对应处理模块。

工程上常见落点在 bsp/<平台>/application：框架初始化、配置裁剪、应用入口都在这一带。

对照例程里的写法，主函数往往很短：

先 Fw_Core_Init()，再 Fw_Core_Startup()；真正的任务用 Fw_Task_Init / Fw_Task_Start 挂上去，Protothread 开着时可用 Fw_PT_Begin / Fw_PT_Delay 这类宏把「延时让出」写清楚。例程里的 LED 翻转，就是在验证调度和板级驱动是否通。

最小闭环：选一个接近你板子的 bsp 工程模版（仓库里有 STM32F1、STM32L4、simulator 等；

文档里还提到过 HC32、N76E003 等模版，以你检出的目录为准）打开 application/fw_conf.h，选 Full/Nano、平台宏，关掉暂时用不到的组件确认主流程能进内核启动；

用 INIT_APP_EXPORT 一类机制注册应用初始化先做一个 LED/定时任务或简单消息通路，确认调度和板级驱动通了，再叠协议

bsp 里常见拆法：application 放应用与 fw_conf.h；paltform（仓库拼写如此）放 board、按键灯串口驱动、msp_conf.h。

3. 注意事项

别把协作式调度当成 RTOS：没有抢占优先级那一套预期时，任务写法要克制。中断里只做短处理，把重活投递成消息或事件，交给任务侧慢慢消化，通常更稳

Full / Nano 不要混用 API：换版本等于换一套接口，裁剪前先定版本再写业务

LV0 / LV1 别在业务里随意混调：抽象边界一旦糊掉，换板成本会回来

文档有空链：例如「框架内核介绍」在 README 里尚未补全，以 document/dir、kernel 源码和例程为准

仓库年代较老：学习分层与裁剪很合适；选型前自己评估维护状态与芯片覆盖

和「自己从零搭分层」比，YSF 的价值主要在现成的配置入口和目录约定；和「直接上 RTOS」比，它更轻，但实时性和任务隔离也弱一截。选哪条路，先看产品要不要抢占、要不要多任务硬隔离，再看 Flash 还剩多少。

4. 总结

项目不是越大越好，YSF 分层把换板成本压在 HAL/MSP；消息驱动把业务拆成可派发的处理单元；能讲清五层职责、LV0/LV1 取舍、Full/Nano 差异，这套经验就比「把整个仓抄进工程」更有用。