【干货】用FreeRTOS搭建Event-Driven应用框架
【干货】用FreeRTOS搭建Event-Driven应用框架
关注、星标嵌入式云IOT技术圈，精彩及时送达
[导读] 大家好，我是逸珺。
今天来分享一下，之前项目中使用FreeRTOS搭建的Event-Driven事件驱动框架。
什么是Event-Driven？
Event-DrivenEvent在计算机编程方法中，是一种广为使用的编程范式。比如Windows中的鼠标、键盘输入，就被Windows操作系统管理成了外部输入事件，由操作系统向不同的应用分发这些输入事件，再由用户应用程序完成相应的动作Action。在GUI编程中，这是一种主要的编程范式。
其基本结构可以用下面这张图来描述：
- 事件生产者：对系统产生各种事件，并发送事件给系统
- 事件分发：将外部输入的事件进行分发管理
- 事件队列：事件分发后，对应的的事件处理者，有可能有多个事件，因此需要按先后次序依次排队处理，所以就有事件队列管理
- 事件消费者：负责处理由事件生产者发送给它的对应事件，产生响应。事件消费者一般有一个循环程序，一直侦听事件队列，如果接收到事件，则调用相应的处理函数。
为什么推崇事件驱动？
常规的做法是程序按照固有的顺序执行，这样的编程方式，灵活性比较差。一旦需求稍有变动，可能就需要比较大的修改。在现代编程方法论中，软件的复杂度越来越大，传统过程方法不能满足复杂软件的需求，可维护性很差。用户与软件的交互体验也很差。
要回答为什么要推崇事件驱动范式，先来看看其特点：
- 多播通信：事件生产者产生的事件可以将事件发送给多个消费者，也就是事件接收端，因此具备很强的灵活性
- 实时传输：事件可以被事件分发者实时的传输给事件接收端。这在嵌入式应用中尤为明显
- 异步通信：事件发布端不需要等待事件处理端处理前一个事件，发的管发，处理的管处理，这也是一种解耦设计的体现。
- 细粒度通信：事件生产者，可以持续发送细粒度事件，而不需要将一系列事件与其业务逻辑关联，不需要聚合处理。
通过上面简要的总结其特征，再来看看为什么这个范式比较好：
- 敏捷性：敏捷性是指应对系统外部需求的快速变化的响应能力。在事件驱动编程范式中，功能域是松散耦合的。这可确保发生在一个组件上的更改不会影响系统中的其他组件。因此，事件驱动编程范式提供的敏捷程度很高。
- 易于部署：在事件驱动编程范式中，组件是松散耦合的。这在嵌入式Linux多应用程序组成的系统比较常见，在单片机中体现不出来。
- 可测试性：事件驱动编程范式中单元测试难度适中，因为它需要特殊的测试客户端和测试工具来生成测试所需的事件。需要考虑其他因素，例如跨功能域的交互顺序。事件的组合和交互的顺序在系统行为中起着关键作用，需要成为测试的关键考虑因素。
- 性能：事件驱动编程范式能够并行执行异步操作。这带来更好性能，而不管消息排队和出队所涉及的时间延迟如何。
- 可扩展性：由于组件的高度解耦特性，事件驱动编程范式提供了高度的可扩展性。
- 易于开发：由于该模式的异步性质，使用该模式的开发难度较低。
用FreeRTOS搭事件驱动框架
FreeRTOS的Queue提供了任务到任务、任务到中断、中断到任务、中断到任务间的通讯机制。关于FreeRTOS队列本身应如何使用的细节，这里不作展开。
假定Task0需要处理这样一些事件，可以定义如下枚举：
代码如下：
typedef enum {
TASK0_EVENT_0,
TASK0_EVENT_1,
TASK0_EVENT_2
.....
} Task0EventType;
typedef struct Task0Event_t {
Task0EventType type;
union {
float para1;
int para2;
bool on;
struct {
xxx;
}xxx;
} params;
} Task0Event;
定义一个联合params放在Task0Event内，可以使事件发送附加信息的能力，使用union则可以考虑到不同的事件发送方需要传送的附加信息不一样的需求，比如有的中断需要发送开关量信息，有的甚至可能是一条报文或者很多信息。
将Task0的任务循环写成下面这样的形式：
xQueueHandle task0_queue;
//假定每10毫秒循环一次
#define TASK0_INTERVAL_MS 10
void task0_main(void)
{
Task0Event event;
if(xQueueReceive(task0_queue,&event,(TASK0_INTERVAL_MS/portTICK_RATE_MS))==pdTRUE)
{
prv_event_process(&event);
}
/*其他处理*/
.....
}
static void prv_event_process( Task0Event* event)
{
switch( event->type )
{
case TASK0_EVENT_0:
.....
break;
case TASK0_EVENT_1:
.....
break;
case TASK0_EVENT_2:
.....
break;
default:
.....
break;
}
}
这样就写好了事件处理端了，只需要分析出与该任务有哪些外设或其他任务会对该任务发送事件，就可以很好的写出事件发送相关的代码了。
对于事件处理的函数，如果不用switch-case语句，定义一个这样的事件回调函数表也是可以的，一定要讨论哪种好，哪种不好，我觉得意义不是很大，看个人喜欢吧：
//函数指针这里举个简单的例子，实际使用的时候，可能需要加参数，返回值等
typedef void (*Event_Handler)( Task0Event *event );
typedef struct EventProcessor_t
{
Task0Event event;
Event_Handler handler;
} EventProcessor;
EventProcessor task0_event_table[] = {
{TASK0_EVENT_0,event0_handler},
{TASK0_EVENT_1,event1_handler},
{TASK0_EVENT_2,event2_handler},
......
}
void task0_main(void)
{
Task0Event event;
if (xQueueReceive(task0_queue,&event, (TASK0_INTERVAL_MS/portTICK_RATE_MS)) == pdTRUE)
{
task0_event_table[event.type].handler(&event);
}
/*其他处理*/
.....
}
用一张图来描述这个思路，就是这样的：
中断中发送
比如是一个中断需要对该任务发送事件0，就可以在该中断函数内如下发送事件：
void xxx_ISR(void)
{
....
Task0Event event;
event.type = TASK0_EVENT_0;
portBASE_TYPE woken = pdFALSE;
xQueueSendFromISR(task0_queue, &event, &woken);
}
对参数pxHigherPriorityTaskWoken，做个简要说明：
单个队列可能会阻塞一个或多个任务，就是该事件可以被多个任务处理。调用这三个函数：
- xQueueSendFromISR()
- xQueueSendToFrontFromISR()
- xQueueSendToBackFromISR()
这三个函数使等待该事件的任务离开阻塞态。如果调用API函数导致任务离开阻塞状态，并且未阻塞任务的优先级等于或高于当前正在执行的任务（被中断的任务），那么在API内部函数会将 *pxHigherPriorityTaskWoken设置为真。如果这些函数将此值设置为 pdTRUE，则应在退出中断之前执行上下文切换。这将确保中断直接返回到最高优先级的就绪状态任务。
这三个函数的原型为：
BaseType_t xQueueSendFromISR( QueueHandle_t xQueue,
const void *pvItemToQueue,
BaseType_t *pxHigherPriorityTaskWoken );
BaseType_t xQueueSendToBackFromISR( QueueHandle_t xQueue,
const void *pvItemToQueue,
BaseType_t *pxHigherPriorityTaskWoken );
BaseType_t xQueueSendToFrontFromISR( QueueHandle_t xQueue,
const void *pvItemToQueue,
BaseType_t *pxHigherPriorityTaskWoken );
这三个函数的作用基本类似，都是在中断中可以使用的发送事件到队列的API：
- xQueueSendFromISR或xQueueSendToBackFromISR 将发送事件至队尾；
- xQueueSendToFrontFromISR发送至对首。
任务中发送
如任务间需要协作，比如需要向task0发送事件1，可以这样写：
void xxx_f(void)
{
....
Task0Event event;
event.type = TASK0_EVENT_1;
xQueueSend(task0_queue, &event, portMAX_DELAY);
...
}
可被使用的API有这样三个：
BaseType_t xQueueSend( QueueHandle_t xQueue,
const void * pvItemToQueue,
TickType_t xTicksToWait );
BaseType_t xQueueSendToFront( QueueHandle_t xQueue,
const void * pvItemToQueue,
TickType_t xTicksToWait );
BaseType_t xQueueSendToBack( QueueHandle_t xQueue,
const void * pvItemToQueue,
TickType_t xTicksToWait );
这三个函数的作用类似，区别与前面中断版本类似，就不赘述了。
总结一下：
利用FreeRTOS搭建这样一个事件驱动应用框架，可以很容易开发，后期维护也很方便。需要加个功能或修改功能，很容易扩展，这样一种编程范式在其他的RTOS中也可以使用，只不过不同的RTOS提供的API会有差异，方法是相通的。
—— The End ——
腾讯云开发者
