tiny-cpp：嵌入式C++零堆事件驱动框架

1. tiny-cpp面向嵌入式裸机与RTOS环境的轻量级C事件驱动框架tiny-cpp 是一个专为资源受限嵌入式系统设计的现代C库其核心目标并非堆叠功能而是以极简主义哲学构建高内聚、低耦合、零堆依赖heapless的运行时基础设施。它并非对传统RTOS或HAL层的替代而是在其上构建的一套可组合、可测试、可移植的事件驱动原语集合。该库直接继承自广受嵌入式开发者欢迎的C语言库tiny的设计思想并通过C语言特性纯虚接口、模板、RAII、函数对象将其工程化表达提升至新高度。tiny-cpp 不追求“大而全”而是聚焦于解决嵌入式应用开发中反复出现的共性问题如何在无动态内存分配的前提下实现可靠的定时、解耦的事件通知、状态清晰的业务逻辑、以及跨上下文中断/线程/主循环的安全数据传递。1.1 设计哲学与工程价值tiny-cpp 的设计决策全部服务于三个根本性的工程约束确定性Determinism、可预测性Predictability和可验证性Verifiability。确定性所有核心组件Timer、EventQueue、Fsm均采用静态内存分配。Timer对象在构造时即完成所有内存的栈或全局静态分配EventQueue使用预分配的环形缓冲区RawRingBuffer其容量在编译期或初始化时固定Fsm的状态转换表由编译期常量数组定义。这彻底消除了运行时内存碎片、分配失败等非确定性行为确保了硬实时场景下的最坏执行时间WCET可精确分析。可预测性tiny-cpp 放弃了多线程模型转而拥抱“运行至完成”Run-To-Complete, RTC范式。每个事件处理函数IEventHandler::handle()必须是短小、无阻塞、且在单次调用中完成所有工作。这种模型与JavaScript的事件循环高度相似但运行在裸机之上。它使得整个系统的控制流变得线性、可追踪——没有线程切换开销没有竞态条件Race Condition没有死锁Deadlock。开发者只需关注“下一个事件是什么”而非“当前线程在哪个状态”。可验证性通过广泛使用纯抽象接口IEvent,IEventQueue,IMessageBus,IKeyValueStoretiny-cpp 实现了完美的依赖倒置Dependency Inversion。业务逻辑代码只依赖于这些接口而与具体实现如Timer、EventQueue、MessageBus完全解耦。这为单元测试提供了天然便利在测试中可以轻松注入模拟Mock或存根Stub实现例如一个不真正触发硬件定时器的MockTimer或一个将所有事件记录到向量中的TestEventQueue。这种设计使得在桌面环境x86_64 CppUTest中对嵌入式业务逻辑进行100%覆盖率的测试成为可能极大提升了固件质量。1.2 核心架构与组件关系tiny-cpp 的架构是一个典型的分层结构自底向上分为硬件抽象层HAL、核心运行时Core Runtime和应用服务层Application Services。--------------------- | Application | -- 用户业务逻辑 (e.g., Fsm, Comm) | Services | ------------------ | ----------v-------- ------------------- | Core Runtime |----| Hardware Abstraction Layer (HAL) | | (Timer, Event, | | (IDigitalIo, IAnalogIn, IPwm, ISerial) | | Queue, Bus, FSM)| ------------------- ------------------ | ----------v-------- | Platform / RTOS | -- 裸机、FreeRTOS、Zephyr、Arduino | (Scheduler, | | Interrupts, | | Memory Layout) | ---------------------HAL层位于include/hal/目录下定义了一组最小化的、面向接口的硬件操作契约。例如IDigitalIo接口仅包含set(),clear(),toggle(),read()四个纯虚函数任何具体的MCU驱动如STM32 HAL封装、AVR寄存器直驱只需实现此接口即可被上层复用。这种设计使得tiny-cpp本身完全不关心底层是ARM Cortex-M还是AVR ATmega极大地增强了代码的可移植性。Core Runtime层这是tiny-cpp的精华所在包含了所有与硬件无关的核心算法和数据结构。其关键组件通过严格的接口隔离彼此之间仅通过事件IEvent和消息IMessageBus进行松耦合通信。Application Services层用户在此层编写自己的业务逻辑。tiny-cpp 提供的Fsm、Hsm、Comm等库正是为这一层服务的高级抽象。它们不是框架的“强制模块”而是可选的、即插即用的工具箱。2. 硬件抽象层HAL统一的硬件操作契约HAL是tiny-cpp可移植性的基石。它不提供任何具体的驱动实现而是定义了一套精炼、稳定、面向用例的C接口。所有接口均设计为纯虚类Pure Abstract Class强制派生类实现其全部方法从而保证了API的一致性和类型安全。2.1 核心HAL接口概览接口名称主要职责典型实现示例IDigitalIo控制数字输入/输出引脚GPIO。支持设置、清除、翻转、读取。STM32_GPIO, AVR_PORTBIAnalogIn读取模拟输入通道ADC。支持单次采样和配置。STM32_ADC, ESP32_ADCIPwm控制脉宽调制PWM输出。支持设置占空比、频率、使能/禁用。STM32_TIM, NRF52_PWMISerial异步串行通信UART。支持发送、接收、配置波特率、数据位等。STM32_UART, AVR_USARTITimer提供毫秒级精度的硬件定时器服务。用于Timer组件的底层计时源。STM32_SYSTICK, NRF52_RTC2.2 HAL接口的工程实践以IDigitalIo为例其定义体现了tiny-cpp对简洁性与效率的极致追求// include/hal/IDigitalIo.h class IDigitalIo { public: virtual ~IDigitalIo() default; // 设置引脚为高电平输出模式 virtual void set() 0; // 设置引脚为低电平输出模式 virtual void clear() 0; // 翻转引脚电平输出模式 virtual void toggle() 0; // 读取引脚电平输入模式 virtual bool read() 0; // 将引脚配置为输出模式可选若硬件要求 virtual void makeOutput() 0; // 将引脚配置为输入模式可选若硬件要求 virtual void makeInput() 0; };关键设计点解析无状态参数set()、clear()等方法不接受引脚编号作为参数。这意味着一个IDigitalIo实例仅代表一个物理引脚。这与传统HAL如STM32 HAL中一个句柄代表一个外设端口的设计截然不同。其优势在于1) 避免了运行时查表开销2) 编译器可对虚函数调用进行更激进的优化特别是当实例为栈对象时3) 使代码意图一目了然——led.set()比HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET)更具可读性。RAII友好IDigitalIo的析构函数为虚函数允许其被安全地存储在智能指针或容器中尽管在裸机环境中通常使用栈对象。一个针对STM32F4的典型实现如下// src/hal/stm32f4/STM32DigitalIo.cpp #include hal/IDigitalIo.h #include stm32f4xx_hal.h class STM32DigitalIo : public IDigitalIo { private: GPIO_TypeDef* port_; uint16_t pin_; public: STM32DigitalIo(GPIO_TypeDef* port, uint16_t pin) : port_(port), pin_(pin) {} void set() override { HAL_GPIO_WritePin(port_, pin_, GPIO_PIN_SET); } void clear() override { HAL_GPIO_WritePin(port_, pin_, GPIO_PIN_RESET); } void toggle() override { HAL_GPIO_TogglePin(port_, pin_); } bool read() override { return HAL_GPIO_ReadPin(port_, pin_) GPIO_PIN_SET; } void makeOutput() override { /* 配置GPIO为输出模式 */ } void makeInput() override { /* 配置GPIO为输入模式 */ } };3. 核心运行时组件深度解析3.1 软件定时器TimerTimer是tiny-cpp中最基础也最常用的组件之一它将底层硬件定时器ITimer的滴答tick抽象为高层的、可编程的“事件生成器”。3.1.1 API设计与使用模式Timer类的构造函数接受一个ITimer引用和一个IEventQueue引用这清晰地表达了其依赖关系它需要一个计时源来产生滴答并需要一个事件队列来投递到期事件。// include/timer/Timer.h class Timer { public: // 构造绑定硬件定时器和事件队列 Timer(ITimer timer, IEventQueue queue); // 启动一次性定时器one-shot void startOnce(uint32_t ms, IEvent event); // 启动周期性定时器periodic void startPeriodic(uint32_t ms, IEvent event); // 停止定时器 void stop(); // 获取当前剩余时间毫秒 uint32_t remaining() const; };使用示例裸机主循环// 全局对象避免动态分配 STM32SysTick sysTick; EventQueue eventQueue(16); // 预分配16个事件槽 Timer ledBlinkTimer(sysTick, eventQueue); // 定义一个事件处理器 struct LedBlinkEvent : public IEvent { IDigitalIo led; explicit LedBlinkEvent(IDigitalIo l) : led(l) {} void handle() override { led.toggle(); } }; LedBlinkEvent blinkEvent(ledPin); // 在main()中初始化 int main() { // ... 初始化HAL ... ledBlinkTimer.startPeriodic(500, blinkEvent); // 每500ms翻转一次LED while (true) { // 主循环处理所有待决事件 eventQueue.dispatchAll(); } }3.1.2 实现原理与内存模型Timer的内部实现极为精巧。它不维护一个复杂的定时器链表而是采用“懒惰更新”Lazy Update策略startOnce()和startPeriodic()会计算出事件的绝对到期时间now delay并将该时间戳和事件引用存储在一个固定的结构体中。ITimer的中断服务程序ISR每毫秒调用一次Timer::tick()方法。tick()方法会检查当前时间是否 存储的到期时间。如果是则将该事件推入IEventQueue并根据类型one-shot/periodic决定是否重置到期时间。这种设计的关键优势在于所有内存都在编译期或构造期静态分配。Timer对象本身就是一个固定大小的结构体其内部不使用任何new或malloc。3.2 事件与事件队列Event EventQueue事件IEvent是tiny-cpp的“数据包”而事件队列IEventQueue则是其“传输管道”。二者共同构成了RTC范式的骨架。3.2.1 事件IEvent类型安全的回调IEvent是一个纯虚基类其唯一抽象方法handle()就是事件的“执行体”。// include/event/IEvent.h class IEvent { public: virtual ~IEvent() default; virtual void handle() 0; };IEvent的强大之处在于其派生类的多样性SingleSubscriberEvent一个事件只能被一个处理器注册适合一对一的通知。Event一个事件可以被多个处理器注册适合一对多的广播如“系统启动完成”事件。用户自定义事件可携带任意数据例如struct TemperatureEvent : public IEvent { float temp; void handle() override { /* 处理温度数据 */ } };3.2.2 事件队列IEventQueue跨上下文的同步桥梁IEventQueue是tiny-cpp中最重要的同步原语它解决了嵌入式开发中最棘手的问题之一如何安全地将数据从高优先级的中断上下文Interrupt Context传递到低优先级的主循环或任务上下文Thread Context。// include/event/IEventQueue.h class IEventQueue { public: virtual ~IEventQueue() default; // 从任意上下文包括ISR安全地入队一个事件 virtual bool post(IEvent event) 0; // 从主循环或任务上下文中安全地出队并处理所有事件 virtual void dispatchAll() 0; // 查询队列中待处理事件的数量 virtual size_t size() const 0; };EventQueue的具体实现基于RawRingBuffer这是一个零拷贝、无锁Lock-Free的环形缓冲区。其post()方法被设计为可在中断中安全调用因为它只涉及原子的写指针更新通常通过__atomic_fetch_add或MCU特定的原子指令实现。dispatchAll()则在主循环中调用它会循环调用pop()并执行event.handle()直到队列为空。工程意义这使得开发者可以将耗时的、非实时的操作如解析协议、更新LCD、发送网络包完全移出ISR。ISR只需做最快速的工作读取寄存器、清除标志位、然后post()一个事件。这极大简化了ISR的编写提高了系统的整体响应性和稳定性。3.3 状态机Fsm HsmFsm有限状态机和Hsm分层状态机是tiny-cpp为解决“状态爆炸”和“状态逻辑纠缠”问题提供的终极方案。它们将复杂的、基于状态的业务逻辑如电机控制、通信协议栈、用户界面转化为清晰、可维护、可测试的函数式结构。3.3.1 Fsm函数即状态Fsm的核心思想是每一个状态都是一个独立的、无状态的函数。状态转换不再是switch-case中一堆if-else的判断而是由一个中心化的、类型安全的转换表Transition Table驱动。// 状态函数签名 using StateFunction Fsm::StateFunction; // 状态函数示例一个简单的LED闪烁状态机 StateFunction stateIdle [](Fsm fsm, const IEvent e) - StateFunction { if (e.isTypeStartEvent()) { // 进入闪烁状态 return stateBlinking; } return stateIdle; // 保持当前状态 }; StateFunction stateBlinking [](Fsm fsm, const IEvent e) - StateFunction { if (e.isTypeStopEvent()) { return stateIdle; } if (e.isTypeBlinkEvent()) { led.toggle(); return stateBlinking; // 继续闪烁 } return stateBlinking; }; // 构建状态机 Fsm ledFsm(stateIdle);Fsm::processEvent(const IEvent)方法会调用当前状态函数并用其返回的新状态函数更新自身。这种设计使得状态逻辑完全无副作用易于单元测试。3.3.2 Hsm状态的层次化组织Hsm在Fsm的基础上引入了“子状态”的概念完美映射了现实世界中复杂系统的层次结构。例如在一个打印机的状态机中“打印中”状态可以有“纸张卡住”、“墨盒缺墨”等子状态而这些子状态共享“打印中”的通用行为如定期检查打印头温度。Hsm的实现利用了C的虚函数和模板其状态函数可以声明为virtual StateFunction onEntry()和virtual StateFunction onExit()从而在进入/退出某个状态时自动执行清理和初始化逻辑。4. 应用服务层构建可靠嵌入式系统的工具箱4.1 通信库CommComm库为点对点Point-to-Point通信提供了简单、健壮的抽象。它不关心物理层UART、SPI、CAN只关注数据的有效载荷Payload和完整性。// include/comm/IComm.h class IComm { public: virtual ~IComm() default; virtual bool send(const uint8_t* data, size_t len) 0; virtual size_t receive(uint8_t* buffer, size_t maxLen) 0; }; // src/comm/Comm.cpp class Comm { private: IComm transport_; uint16_t crc16(const uint8_t* data, size_t len); public: explicit Comm(IComm transport) : transport_(transport) {} // 发送一个带CRC16校验的帧 templatetypename T bool send(const T payload) { static_assert(std::is_trivially_copyable_vT, Payload must be trivially copyable); const uint8_t* ptr reinterpret_castconst uint8_t*(payload); size_t len sizeof(T); uint16_t crc crc16(ptr, len); // 构造帧: [PAYLOAD][CRC_LO][CRC_HI] std::arrayuint8_t, sizeof(T) 2 frame; std::memcpy(frame.data(), ptr, len); frame[len] static_castuint8_t(crc 0xFF); frame[len 1] static_castuint8_t((crc 8) 0xFF); return transport_.send(frame.data(), frame.size()); } };Comm库的价值在于它将底层通信的复杂性字节序、帧同步、错误检测封装起来让应用层只需关注“我要发送什么数据”而无需操心“如何确保数据不被损坏”。4.2 消息总线MessageBus与键值存储KeyValueStoreMessageBus和KeyValueStore是tiny-cpp为实现松耦合、可扩展系统架构提供的高级服务。MessageBus是一个发布-订阅Pub-Sub模式的实现。组件可以向总线发布一个IMessage所有对该消息类型感兴趣的订阅者都会收到通知。这彻底解耦了消息的生产者和消费者是构建模块化固件的理想选择。KeyValueStore则是一个内存中的、类型安全的配置中心。它不仅存储数据还为每个键Key提供“观察者”Watcher机制。当一个键的值发生变化时所有注册的IKeyValueStore::IWatcher都会被通知。这使得UI组件可以自动刷新日志组件可以自动记录变更而无需在业务逻辑中插入大量胶水代码。// RamKeyValueStore 的典型用法 RamKeyValueStore configStore; configStore.set(wifi.ssid, MyNetwork); configStore.set(wifi.password, Secret123); // 注册一个观察者当wifi.ssid改变时被调用 configStore.watch(wifi.ssid, [](const std::string newValue) { printf(WiFi SSID changed to: %s\n, newValue.c_str()); });5. 集成与工程实践指南5.1 与主流生态的集成tiny-cpp 的设计使其能够无缝融入现有开发流程裸机开发只需将include/加入编译器头文件路径并将src/下的所有.cpp文件加入编译。main()函数即为整个应用的入口点。FreeRTOSEventQueue可以与FreeRTOS的xQueueHandle对接Timer可以使用xTimerCreate作为底层。IEvent::handle()可以在FreeRTOS任务中调用eventQueue.dispatchAll()。Arduinotiny-cpp 可以作为Arduino库安装。setup()中初始化HAL和核心组件loop()中调用eventQueue.dispatchAll()即可。Mbed OS利用Mbed的Ticker和EventQueue作为tiny-cpp的底层实现实现零成本抽象。5.2 测试驱动开发TDD工作流tiny-cpp 的接口设计是TDD的天然盟友。其标准测试工作流如下编写测试用例使用CppUTest框架针对一个业务逻辑如TemperatureController编写测试。注入Mock依赖在测试中创建MockTimer,MockEventQueue,MockI2c等模拟对象。断言行为调用被测对象的方法然后断言模拟对象的交互例如mockTimer.wasStarted()或最终状态例如controller.getState() ControllerState::HEATING。实现生产代码根据测试失败信息编写满足需求的生产代码。重复循环往复直至所有测试通过。这种工作流确保了代码在部署到目标硬件之前其核心逻辑已经过100%的验证极大地降低了现场调试的成本和风险。tiny-cpp 的价值不在于它提供了多少炫酷的功能而在于它用一套优雅、一致、经过深思熟虑的C原语为嵌入式工程师构建了一个坚实、可靠、可预测的“思维脚手架”。在这个脚手架上开发者可以将全部精力聚焦于解决真正的业务问题而非与底层细节搏斗。