干货 | 用FreeRTOS搭建Event-Driven应用框架

Posted 嵌入式大杂烩

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了干货 | 用FreeRTOS搭建Event-Driven应用框架相关的知识,希望对你有一定的参考价值。

[导读]大家好,我是逸珺。

今天来分享一下,之前项目中使用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 ——

往期推荐:

国产芯片替代STM32的一些经验分享

深入理解嵌入式中重要的编程模型

在公众号聊天界面回复1024,可获取嵌入式资源;回复 m ,可查看文章汇总。

点击阅读原文,查看更多分享。

以上是关于干货 | 用FreeRTOS搭建Event-Driven应用框架的主要内容,如果未能解决你的问题,请参考以下文章

FreeRTOS学习笔记 —— 环境搭建

FreeRTOS学习笔记 ——消息队列

FreeRTOS学习笔记 ——消息队列

FreeRTOS学习笔记 ——消息队列

1FreeRTOS移植

邮干货用IIS ARR搭建七层负载均衡站点