事件驱动框架EventOS Nano：把单片机程序从“面条代码“改成“事件流水线“

事件驱动框架EventOS Nano：把单片机程序从"面条代码"改成"事件流水线"

【免费下载链接】eventos嵌入式开发框架，事件驱动，超级轻量。最低占用ROM 1.5KB，RAM 172字节。核心技术是事件总线，支持Reactor和状态机两种模式，协作式内核，极度可靠。可深度裁剪，移植方便。项目地址: https://gitcode.com/gh_mirrors/eve/eventos

如果你写过几万行单片机裸机程序，大概率经历过这样的崩溃时刻：按键、串口、定时器、LED、传感器……每个外设都要在主循环里轮询一遍，状态全靠一堆 if 嵌套和一个写满注释的全局变量撑着。今天要聊的 EventOS Nano，就是一个面向这类痛点的开源事件驱动框架。它主打两件事：一是事件驱动，让代码模块之间彻底解耦；二是超级轻量，最低只要 ROM 1.5KB、RAM 172 字节，一颗小小的 Cortex-M0 都跑得动。

先说说裸机开发的那些坑

在进入事件驱动之前，我想先跟你对一下"病历"。传统裸机写法有三个通病，你应该不陌生：

• 一个 while(1) 承载整个世界。LED 闪烁、按键扫描、串口轮询全塞在循环里，加一个功能，循环体就胖一圈，时序越来越乱。
• 模块之间互相"拉手"。按键模块要直接调用 LED 模块的函数，LED 又要引用按键的全局标志位，改一处，崩三处。
• 状态管理靠人脑。状态多了以后，全局变量满天飞，谁改的、什么时候改的，全靠回忆。

这三个问题有一个共同根源：模块之间通信靠"直接函数调用"，耦合太深。EventOS Nano 的思路很朴素——模块之间不互相认识，只通过"事件"交流。

事件驱动到底是个啥？先想想你上班的流程

事件驱动听着玄乎，其实就是"前台接待 + 排队叫号"那套逻辑。你把一份文件递到前台（发布事件），前台按主题把文件分发给对应的窗口（分发），窗口办完自己的事就收工，压根不用知道文件最初是谁递的。

再换个场景：微信消息推送。你发一条消息到群里，群成员谁感兴趣谁就回应，发消息的人不需要挨个私聊每个人。这就是事件驱动的精髓——发送方与接收方彻底解耦。

落到代码里，EventOS Nano 的事件就是一个"主题 + 数据 + 长度"的小结构体，比如：

eos_event_pub(Event_Button, &key_value, 1); // 按键按下，发布一条事件

这里Event_Button是主题，key_value是携带的数据。发布者只管把事件扔出去，谁订阅了这个事件、谁去处理，它一概不关心。这种解耦带来的好处是：按键模块和 LED 模块互不认识，各自独立演进，改一个模块不会牵连另一个。

一句话总结：事件驱动 = 模块间通过"消息"而非"函数调用"通信，解耦是它的核心价值。

三步把事件循环跑起来

EventOS Nano 的接入过程，比你想象中简单。它不像 RTOS 那样要配置任务栈、信号量，你要做的只有三件事。

第一步：初始化框架

在main函数里，两行代码完成初始化，然后在末尾启动框架：

eos_init(); // 初始化框架 // 在这里初始化你的反应器或状态机 eos_run(); // 启动事件循环，永不返回

注意：eos_run()之后框架会接管 CPU，所以所有业务模块的初始化要放在它之前。

第二步：让你的模块"订阅"事件

以经典点灯为例。你写一个 LED 模块，继承框架的 reactor（反应器），然后订阅一个定时事件：

eos_reactor_init(&actor_led.super, 2, EOS_NULL); eos_reactor_start(&actor_led.super, EOS_HANDLER_CAST(led_e_handler)); eos_event_sub(&actor_led.super, Event_Time_1000ms);

这三行分别干了三件事：初始化反应器、注册事件处理函数、订阅"每秒一次"的事件。之后框架每收到Event_Time_1000ms，就会自动调用你的处理函数，你只需在里面翻转 LED 电平即可。

第三步：定时事件怎么来？

别急，Event_Time_1000ms不是天上掉下来的。EventOS Nano 内置了软定时器，一行代码就能让它周期性地"冒出来"：

eos_event_pub_period(Event_Time_1000ms, 1000);

就是这么简单：你声明一个周期事件，框架负责每 1000 毫秒发布一次，你的 LED 模块负责响应。谁触发、谁响应，各司其职，互不打扰。

三步走完，一个定时闪烁的 LED 就活了。整个工程里，你没有写一行while(1)轮询，没有用任何全局状态标志位。

两种编程范式：反应器与状态机

EventOS Nano 给两类人准备了两种写法，你按业务复杂度选：

• Reactor（反应器）：适合简单逻辑。就一个事件处理函数，switch一下主题就行，上面的 LED 例子就是这种。
• 状态机模式：适合复杂逻辑，比如菜单导航、通信协议、设备流程控制。每个状态是一个函数，状态之间通过EOS_TRAN(state_next)跳转，事件触发跳转，逻辑一目了然。

状态机的妙处在于，复杂流程被拆成了一个个小函数，每个状态只关心自己收到的几种事件，再也不需要"全局状态变量 + 一堆 if"的祖传写法。项目里的电子表例程（digital_watch）就是状态机的典型应用，值得翻一翻。

轻量到啥程度？一张表看懂

这是我最想让你记住的部分——EventOS Nano 的资源占用：

配置	ROM	RAM
全功能（MDK -O3）	约 3.5KB	约 200 字节
最小裁剪（MDK -O0）	约 1.5KB	172 字节

更关键的是，它不是"瘦到没法用"，而是所有特性都可以按需裁剪。层次状态机、平面状态机、发布-订阅、事件携带数据、事件桥……这些在eventos_config.h里都是一个宏开关的事，用不上就关掉，RAM 和 ROM 立刻省下来。连协作式内核的设计，也保证了不会产生资源竞争，运行极度可靠。

移植到你的板子上要写几行代码？

很多嵌入式工程师一听到"框架"两个字就怕，担心移植地狱。EventOS Nano 把移植收敛到几个接口函数上，你照着例程抄就行：

• 临界区保护（关/开中断），对 STM32 就是__disable_irq()/__enable_irq()；
• 一个断言函数，用来在出错时打印信息并停住；
• 三个可选的空 hook 函数（空闲、启动、停止时的回调）。

就这么点东西。项目里现成给了 STM32F103 和 STM32F030 两套裸机例程，MDK 工程直接打开就能编译烧录。

下一步：动手点亮你板子上的灯

别光看，上手才是最快的理解方式。给你三条行动建议：

1. 克隆源码：git clone https://gitcode.com/gh_mirrors/eve/eventos，把仓库拿下来。
2. 先看例程：从examples/stm32f103/User/目录下的 LED 例程开始，对照本文三步走，点亮你手头板子上的灯。
3. 再啃文档：项目documentation目录里有快速入门和裸机移植两份文档，配合阅读，理解会深得多。还有一篇《如何理解事件》的博客，把事件机制讲得特别通俗。

如果你跑通了第一个 LED 例程，欢迎回来聊聊：你打算先把哪个模块改造成事件驱动？是按键还是串口？评论区见。

【免费下载链接】eventos嵌入式开发框架，事件驱动，超级轻量。最低占用ROM 1.5KB，RAM 172字节。核心技术是事件总线，支持Reactor和状态机两种模式，协作式内核，极度可靠。可深度裁剪，移植方便。项目地址: https://gitcode.com/gh_mirrors/eve/eventos