良许Linux教程网 干货合集 当单片机遇到状态机——入门QP

当单片机遇到状态机——入门QP

前言

前几天在微信上看到李肖遥的公众号,里面讲述了QP框架,让我很受启发。我已经使用QP框架很多年了,一开始用的是QM和QPC++,后来放弃了QM,直接使用QPC来编写程序,最后甚至自己写起了状态机框架。

可以说,QP框架对我的技术成长起到了引导作用。尽管我发布的博文大多以QP为基础,但其中融入了很多QP官网资料所没有的内容。我希望能够倾听大家的意见、建议和批评,相信这对我来说将会有更大的提升。

这一系列的博文取名为《当单片机遇上状态机》系列,下面是我暂时规划的几篇文章:

  • 入门QP

帮助大家开始使用QP框架,消除对QP的顾虑,建立起初步的信心。这一步非常关键。

  • 从switch-case到框架的进化

许多人很难理解,为什么要使用状态机框架,当自己使用switch-case实现状态机已经运作良好。这篇文章旨在解释switch-case状态机是如何逐步发展为一个状态机框架的。我们所编写的这个状态机框架与QP之间到底有什么关系、有多大的差距。

  • QP的高级使用和QM的使用

QM是一种辅助工具,它的作用是什么?它如何生成代码?它与QP之间有何关联?在本文中将进行详细介绍。

  • QP的哲学

精通QP,理解其哲学思想非常重要。它的哲学思想是怎样的?如何体现出来?

  • 其他

接下来的规划将根据大家的反馈意见确定。我使用状态机框架多年,难免无法代入初学者的感受。期待大家积极反馈意见。无论是赞扬还是批评,我都会虚心接受。

入门QP

我们学习一个语言,或者一项技术,第一件要做的事情,就是实现一个类似于Hello world的最小程序。在单片机上,当然就是LED灯的闪烁。不说废话了,先上代码。

代码结构

代码结构,可以在Keil工程中看到,是一个QP的运行最小系统。QP版本使用的是最新的V6.9.3版本。

为了便于大家的学习,我抛弃了官方例程。官方例程有些繁琐,里面还有大量的doxygen格式的注释,对初学者不友好。与官方例程相比,能删掉的部分,全部都删掉了,只留下代码和必要中文注释,目的就是为了最大限度降低大家学习QP的入门门槛,也算是中国特色吧。这四个源码,代码未来我们程序架构的不同层次,以后所有的例程,就是以这个代码结构为基础,进行扩充。

还有一个需要说明的,第一个例程,我并没有使用QM建模工具进行LED状态机的建模和代码生成。QM工具,本质上基于模型的开发方法,是形式化开发方法之一。在软件开发中,这种方法一直饱受争议。这个世界现存的大部分软件框架,是不存在所谓代码生成工具的。目前我对QM等建模工具持保守态度,软件开发还是要回归代码本身,能利用工具,但不要依赖工具。QM工具,我认为是QP框架在营销和商业上的需求推动的。因此,在未来的教程中,我将QM的使用,放在次要位置,主要还直接编程为主,我认为这样才会给大家带来真正的提升。

这四个源码分别是:

  • main.c 包含了硬件的初始化、QP框架的初始化、各状态机模块(暂定称呼,严谨应叫AO模块)的构建,框架的启动等一系列流程。

  • bsp.c 硬件初始化,此处仅包含SysTick的初始化和SysTick中断函数。

  • ao_led.c LED状态机的源码。

  • hook.c QP框架的回调函数的实现,此处都为空函数,暂时不予实现。

  • evt_def.h 事件的定义。QP框架的事件定义,使用枚举实现。个人觉得,事件的定义,如果用字符串实现,更加有利于模块的解耦和对分布式的支持(这个问题可参考后续的博客《将软总线进行到底》)。QP使用枚举来定义事件,个人认为是为了降低RAM和CPU的开销。

  • 其他

    • QP源码
    • QP接口代码
    • QP框架对硬件平台或者RTOS的接口源码。
    • MCU相关代码,包含Startup文件、CMSIS相关、固件库相关代码

QP的启动流程

以下代码就是QP框架的启动过程。

#include "qpc.h"                                        // qpc框架头文件
#include "evt_def.h"                                    // 事件定义头文件
#include "bsp.h"                                        // 硬件初始化
#include "ao_led.h"                                     // LED状态机

Q_DEFINE_THIS_MODULE("Main")        // 定义当前的模块名称,此名称在QS和断言中会使用。

ao_led_t led;                                           // 状态机LED对象

int main(void)
{
    static QSubscrList sub_sto[MAX_PUB_SIG];            // 定义订阅缓冲区
    static QF_MPOOL_EL(m_evt_t) sml_pool_sto[128];      // 定义事件池
    
    QF_init();                                          // 状态机框架初始化
    QF_psInit(sub_sto, Q_DIM(sub_sto));                 // 发布-订阅缓冲区的初始化
    QF_poolInit(sml_pool_sto,                           // 事件池的初始化
                sizeof(sml_pool_sto),
                sizeof(sml_pool_sto[0]));
                
    ao_led_ctor(&led);                                  // 状态机的构建
    
    return QF_run();                                    // 框架启动
}

QP的回调函数

通常的调用,都是上层函数调用底层函数。如果使用了某个函数,需要上层实现,这样就产生了底层对上层函数的调用,称为回调函数(Call back),也叫钩子函数(Hook)。

一般而言,回调函数,主要用于顶层功能在底层模块里的插入,或者实现底层模块的定制功能。QP框架定义四个回调函数,需要QP的使用者来实现。

void QF_onStartup(void) {
    bsp_init();                                         // 硬件初始化
}
void QF_onCleanup(void) {}
void QV_onIdle(void) {}
void Q_onAssert(char_t const * const module, int_t const loc)
{
    (void)module;
    (void)loc;
    while (1);
}

QF_onStartup是用于QP框架启动时,所调用的回调函数。一般可以执行一些初始化工作,比如硬件初始化,内存初始化。这也就是为什么在main函数中没有看到硬件初始化的原因。

QF_onCleanup与RTOS相关,暂时用不到。

QV_onIdle是QP框架空闲时,也就是没有任何事件产生时,所执行的函数。

Q_onAssert是QP的断言的实现。断言,是程序一种检查机制,当程序的执行发生异常时,用于检查不可能发生情况。比如下面的函数,当函数func_add的两个参数,都不可能大于或者等于100时,就可以对使用断言进行检查,以防御可能出现的参数输入错误。这种编程方式,也叫做防御式编程。防御式编程的思想就是,若崩溃,就崩溃的更猛烈些,以便在编程的早期,就发现程序错误,并强迫开发者解决掉。

int func_add(int x, int y)
{
    Q_ASSERT(x return (x + y);
}

系统嘀嗒

在当前的历程中,使用一个QP中自带的协作式内核QV。在使用了QV内核的前提下,SysTick只有一个作用,那就是为时间事件提供时间基准。

#include "bsp.h"
#include "stm32f10x.h"
#include "qpc.h"

void bsp_init(void)
{
    SysTick_Config(SystemCoreClock / 1000);         // 时间基准为1ms
    NVIC_SetPriority(SysTick_IRQn, 0);              // 设置中断优先级
}

void SysTick_Handler(void)
{
    QF_TICK_X(0U, &l_SysTick_Handler);              // 时间基准
}

如果大家需要换一个芯片跑这个例程,那么仅仅需要更换Keil RTE中的Deivce和这里的代码即可。只有这里的代码是硬件相关的。以后大家写程序,也是一样,要执行硬件相关最小原则,也就是说,要把硬件相关的代码压缩到最低。

LED状态机

LED状态机是核心功能,学会了这个,就入门了QP。在QP中,AO(Active Object)是核心,QP的所有功能都是围绕AO展开的,就好比在RTOS中任务是核心一样。AO之间,纯粹靠事件进行通信,原则上是不允许AO间共享全局变量的。

LED状态机的类定义

下面是头文件的定义。头文件中,主要定义了LED状态机类,并声明了类方法。这里所说的类,是在逻辑上的类。在C语言中,没有类的概念,只能使用结构体替代类的实现。

#include "qpc.h"

#define AO_LED_QUEUE_LENGTH                 32

// LED类的定义
typedef struct ao_led_tag{
    QActive super;                                      // 对QActive类的继承
    
    QEvt const *evt_queue[AO_LED_QUEUE_LENGTH];         // 事件队列
    QTimeEvt timeEvt;                                   // 延时事件
    
    bool status;                                        // LED状态
} ao_led_t;

// LED的类方法 构造函数
void ao_led_ctor(ao_led_t * const me);

LED状态机是完全按照C语言面向对象的方法实现的。在C语言中,由于在语言层面并没有对面向对象进行支持,因此面向对象的C开发,是运用了一些特殊技巧的。

QActive类,简单说就是状态机类。在定义一个状态机对象时,需要从QActive类进行继承。

LED状态机类的实现

LED状态机类的实现,共分为两个部分,一是类方法的实现,二是类状态的实现。

这里只有一个类方法,那就是LED类的构造函数。构造函数,是C++中的概念,C语言中并没有这个概念,这里与类相似,仍然是构造功能的模拟。从代码可以看出,构造函数有几个内容,一个必须的步骤,就是活动对象的构造和启动。构造函数中的另一个内容,就是初始化一个时间事件的对象,因为每500ms要发送一个Evt_Time_500ms事件。

// 活动对象(AO,Active Object)LED的构建
void ao_led_ctor(ao_led_t * const me)
{
    // LED对象的变量初始化
    me->status = false;

    // 活动对象的构建
    QActive_ctor(&me->super, Q_STATE_CAST(&state_init));
    // 时间对象的构建
    QTimeEvt_ctorX(&me->timeEvt, &me->super, Evt_Time_500ms, 0U);
    // 活动对象的启动
    QACTIVE_START(  &me->super,
                    1,                              // 优先级
                    me->evt_queue,                  // 事件队列
                    AO_LED_QUEUE_LENGTH,            // 事件队列深度
                    (void *)0,                      // 任务栈,RTOS相关,可忽略
                    0U,                             // 任务栈深度,RTOS相关,可忽略
                    (QEvt *)0);
}

LED状态类有三个状态,初始状态,ON状态和OFF状态。

初始状态

所有的初始状态都是一样的,就是先订阅状态机运行所需要的事件。然后直接跳转到某个特定的状态。实际上,事件的订阅,不一定要在初始状态里执行。在状态机运行时,随时都能订阅事件,或者解除对事件的订阅。

这个事件的订阅机制,就是在软件设计模式中,大名鼎鼎的发布-订阅模式。发布-订阅模式的最大好处,就是模块间的彻底解耦。这里插入一个程序设计原则,好的程序,一定是解耦良好的程序。所谓耦合,就是模块A变了,模块B也得跟着变,否则,B模块会运行不正常,模块之间有依赖;所谓解耦,就是去除模块之间的依赖,模块A变了,模块B无须改变。

// 初始状态
static QState state_init(ao_led_t * const me, void const * const par)
{
    // 事件Evt_Time_500ms的订阅
    QActive_subscribe(&me->super, Evt_Time_500ms);

    return Q_TRAN(&state_on);
}

ON状态

  • 参数的传输

从代码中,可以看到,当产生事件时,框架会自动调用state_on函数,led对象,是通过参数me传进来的,这个me指针,相当于C++里的this指针,而所产生的事件,是通过参数e传输进来的。

  • 事件的处理

大家注意到代码里有三个事件Q_ENTRY_SIG、Q_EXIT_SIG和Evt_Time_500ms。其中前两个是系统事件,也就是QP框架默认支持的事件。Q_ENTRY_SIG是状态进入事件,当进入一个状态时,QP框架会默认执行这个事件。Q_EXIT_SIG是状态退出事件,当退出一个状态时,QP框架也会默认执行这个事件。Evt_Time_500ms是用户事件,也就是我们自己定义的事件。Q_ENTRY_SIG和Q_EXIT_SIG并不强制定义,而我们要根据自己的需要,看在进入或者退出一个状态时,是否有动作执行,来决定是否对这两个系统事件进行实现。QP还有一个系统事件,Q_INIT_SIG,这个和层次化状态机相关,以后再讨论。

  • 事件后的返回值

大家注意到每个状态机在不同的case分支下,都有不同的返回值,比如Q_HANDLED(),Q_TRAN(&state_off)或者Q_SUPER(&QHsm_top)。

之所以有这些返回值的不同,是为了在处理完毕一个事件后,告诉框架,下一步要干什么。Q_SUPER(&QHsm_top)告诉框架此事件被忽略,什么也不处理;Q_HANDLED()告诉框架,此事件已经处理;而Q_TRAN(&state_off)告诉框架,需要跳转到state_off状态,框架这时会执行当前状态的退出事件和下一个状态的进入事件。

  • QP框架的技术约束

无论是事件处理的机制,还是返回值的格式,都是QP框架的技术约束。任何一个软件框架,在带来编程便利的同时,也会带来性能上的开销和技术的约束。我们要使用一个框架,也就要遵守它制定的技术约束,否则框架就没有办法有效的运行。

// LED的on状态
static QState state_on(ao_led_t * const me, QEvt const * const e)
{
    switch (e->sig) {
        case Q_ENTRY_SIG:                           // 状态的进入事件
            me->status = true;                      // 打开LED灯
            QTimeEvt_armX(&me->timeEvt, 500, 0U);   // 500ms后发送时间事件
            return Q_HANDLED();                     // 通知框架,事件已处理

        case Q_EXIT_SIG:                            // 状态的退出事件
            QTimeEvt_disarm(&me->timeEvt);
            return Q_HANDLED();

        case Evt_Time_500ms:
            return Q_TRAN(&state_off);              // 通知框架,状态转移至state_off

        default:
            return Q_SUPER(&QHsm_top);              // 其他事件,在此时不处理
    }
}

// LED的Off状态
static QState state_off(ao_led_t * const me, QEvt const * const e)
{
    switch (e->sig) {
        case Q_ENTRY_SIG:
            me->status = false;                     // 关闭LED灯
            QTimeEvt_armX(&me->timeEvt, 500, 0U);
            return Q_HANDLED();

        case Q_EXIT_SIG:
            QTimeEvt_disarm(&me->timeEvt);
            return Q_HANDLED();

        case Evt_Time_500ms:
            return Q_TRAN(&state_on);

        default:
            return Q_SUPER(&QHsm_top);              // 其他事件,在此时不处理
    }
}
  • OFF状态

与ON状态一样,不再赘述。有人可以会提出疑问,在收到Evt_Time_500ms事件的时候,让LED的状态翻转,不必跳转到OFF状态,不就节约了一个状态吗?的确,这样写的确更简练,但我们的目的是为了展示状态机的使用,因此可以增加了一个OFF状态。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !

137e00002230ad9f26e78-265x300
本文由 良许Linux教程网 发布,可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
良许

作者: 良许

良许,世界500强企业Linux开发工程师,公众号【良许Linux】的作者,全网拥有超30W粉丝。个人标签:创业者,CSDN学院讲师,副业达人,流量玩家,摄影爱好者。
上一篇
下一篇

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部