2024年最新嵌入式编程之状态机_状态机编程(1)，2024年最新面试物联网嵌入式开发系统架构

最新推荐文章于 2024-08-03 21:32:51 发布

2401_85013826

最新推荐文章于 2024-08-03 21:32:51 发布

阅读量983

点赞数 23

分类专栏：程序员文章标签：物联网嵌入式硬件学习

本文链接：https://blog.csdn.net/2401_85013826/article/details/138835254

版权

程序员专栏收录该内容

19 篇文章 0 订阅

订阅专栏

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1、什么是状态机？

状态机是一个这样的东东：状态机(state machine)有 5 个要素，分别是状态(state)、迁移(transition)、事件(event)、动作(action)、条件(guard)。

状态：一个系统在某一时刻所存在的稳定的工作情况，系统在整个工作周期中可能有多个状态。例如一部电动机共有正转、反转、停转这 3 种状态。

一个状态机需要在状态集合中选取一个状态作为初始状态。

迁移：系统从一个状态转移到另一个状态的过程称作迁移，迁移不是自动发生的，需要外界对系统施加影响。停转的电动机自己不会转起来，让它转起来必须上电。

事件：某一时刻发生的对系统有意义的事情，状态机之所以发生状态迁移，就是因为出现了事件。对电动机来讲，加正电压、加负电压、断电就是事件。

动作：在状态机的迁移过程中，状态机会做出一些其它的行为，这些行为就是动作，动作是状态机对事件的响应。给停转的电动机加正电压，电动机由停转状态迁移到正转状态，同时会启动电机，这个启动过程可以看做是动作，也就是对上电事件的响应。

条件：状态机对事件并不是有求必应的，有了事件，状态机还要满足一定的条件才能发生状态迁移。还是以停转状态的电动机为例，虽然合闸上电了，但是如果供电线路有问题的话，电动机还是不能转起来。

只谈概念太空洞了，上一个小例子：一单片机、一按键、俩 LED 灯(记为L1和L2)、一人，足矣！

规则描述：

1、L1L2状态转换顺序OFF/OFF--->ON/OFF--->ON/ON--->OFF/ON--->OFF/OFF

2、通过按键控制L1L2的状态,每次状态转换需连续按键5次

3、L1L2的初始状态OFF/OFF

图1

下面这段程序是根据功能要求写成的代码。

程序清单List1：

void main(void)
{
 sys\_init();
 led\_off(LED1);
 led\_off(LED2);
 g_stFSM.u8LedStat = LS_OFFOFF;
 g_stFSM.u8KeyCnt = 0;
 while(1)
 {
  if(test\_key()==TRUE)
  {
   fsm\_active();
  }
  else
  {
   ; /\*idle code\*/
  }
 }
}
void fsm\_active(void)
{
 if(g_stFSM.u8KeyCnt > 3) /\*击键是否满 5 次\*/
 {
  switch(g_stFSM.u8LedStat)
  {
   case LS_OFFOFF:
    led\_on(LED1); /\*输出动作\*/
    g_stFSM.u8KeyCnt = 0;
    g_stFSM.u8LedStat = LS_ONOFF; /\*状态迁移\*/
    break;
   case LS_ONOFF:
    led\_on(LED2); /\*输出动作\*/
    g_stFSM.u8KeyCnt = 0;
    g_stFSM.u8LedStat = LS_ONON; /\*状态迁移\*/
    break;
   case LS_ONON:
    led\_off(LED1); /\*输出动作\*/
    g_stFSM.u8KeyCnt = 0;
    g_stFSM.u8LedStat = LS_OFFON; /\*状态迁移\*/
    break;
   case LS_OFFON:
    led\_off(LED2); /\*输出动作\*/
    g_stFSM.u8KeyCnt = 0;
    g_stFSM.u8LedStat = LS_OFFOFF; /\*状态迁移\*/
    break;
   default: /\*非法状态\*/
    led\_off(LED1);
    led\_off(LED2);
    g_stFSM.u8KeyCnt = 0;
    g_stFSM.u8LedStat = LS_OFFOFF; /\*恢复初始状态\*/
    break;
  }
 }
 else
 {
  g_stFSM.u8KeyCnt++; /\*状态不迁移，仅记录击键次数\*/
 }
}

实际上在状态机编程中，正确的顺序应该是先有状态转换图，后有程序，程序应该是根据设计好的状态图写出来的。不过考虑到有些童鞋会觉得代码要比转换图来得亲切，我就先把程序放在前头了。

这张状态转换图是用UML(统一建模语言)的语法元素画出来的，语法不是很标准，但拿来解释问题足够了。

图2按键控制流水灯状态转换图

圆角矩形代表状态机的各个状态，里面标注着状态的名称。

带箭头的直线或弧线代表状态迁移，起于初态，止于次态。

图中的文字内容是对迁移的说明，格式是：事件[条件]/动作列表(后两项可选)。

“事件[条件]/动作列表”要说明的意思是：如果在某个状态下发生了“事件”，并且状态机

满足“[条件]”，那么就要执行此次状态转移，同时要产生一系列“动作”，以响应事件。在这个例子里，我用“KEY”表示击键事件。

图中有一个黑色实心圆点，表示状态机在工作之前所处的一种不可知的状态，在运行之前状态机必须强制地由这个状态迁移到初始状态，这个迁移可以有动作列表(如图1所示)，但不需要事件触发。

图中还有一个包含黑色实心圆点的圆圈，表示状态机生命周期的结束，这个例子中的状态机生生不息，所以没有状态指向该圆圈。

关于这个状态转换图就不多说了，相信大家结合着上面的代码能很容易看明白。现在我们再聊一聊程序清单List1。

先看一下fsm_active()这个函数，g_stFSM.u8KeyCnt = 0;这个语句在switch—case里共出现了 5 次，前 4 次是作为各个状态迁移的动作出现的。从代码简化提高效率的角度来看，我们完全可以把这 5 次合并为 1 次放在 switch—case 语句之前，两者的效果是完全一样的，代码里之所以这样啰嗦，是为了清晰地表明每次状态迁移中所有的动作细节，这种方式和图2的状态转换图所要表达的意图是完全一致的。

再看一下g_stFSM这个状态机结构体变量，它有两个成员：u8LedStat和 u8KeyCnt。用这个结构体来做状态机好像有点儿啰嗦，我们能不能只用一个像 u8LedStat 这样的整型变量来做状态机呢？

当然可以！我们把图 2中的这 4 个状态各自拆分成 5 个小状态，这样用 20 个状态同样能实现这个状态机，而且只需要一个 unsigned char 型的变量就足够了，每次击键都会引发状态迁移，每迁移 5 次就能改变一次 LED 灯的状态，从外面看两种方法的效果完全一样。

假设我把功能要求改一下，把连续击键5次改变L1L2的状态改为连续击键100次才能改变L1L2的状态。这样的话第二种方法需要4X100=400个状态！而且函数fsm_active()中的switch—case语句里要有400个case，这样的程序还有法儿写么？！

同样的功能改动，如果用g_stFSM这个结构体来实现状态机的话，函数fsm_active()只需要将if(g_stFSM.u8KeyCnt>3)改为if(g_stFSM.u8KeyCnt > 98)就可以了！

g_stFSM结构体的两个成员中，u8LedStat可以看作是质变因子，相当于主变量；u8KeyCnt可以看作是量变因子，相当于辅助变量。量变因子的逐步积累会引发质变因子的变化。

像g_stFSM这样的状态机被称作Extended State Machine，我不知道业内正规的中文术语怎么讲，只好把英文词组搬过来了。

2、状态机编程的优点

说了这么多，大家大概明白状态机到底是个什么东西了，也知道状态机化的程序大体怎么写了，那么单片机的程序用状态机的方法来写有什么好处呢？

(1)提高CPU使用效率

话说我只要见到满篇都是delay_ms()的程序就会蛋疼，动辄十几个ms几十个ms的软件延时是对CPU资源的巨大浪费，宝贵的CPU机时都浪费在了NOP指令上。那种为了等待一个管脚电平跳变或者一个串口数据而岿然不动的程序也让我非常纠结，如果事件一直不发生，你要等到世界末日么？

把程序状态机化，这种情况就会明显改观，程序只需要用全局变量记录下工作状态，就可以转头去干别的工作了，当然忙完那些活儿之后要再看看工作状态有没有变化。只要目标事件(定时未到、电平没跳变、串口数据没收完)还没发生，工作状态就不会改变，程序就一直重复着“查询—干别的—查询—干别的”这样的循环，这样CPU就闲不下来了。在程序清单 List3 中，if{}else{}语句里else下的内容(代码中没有添加，只是加了一条/*idle code*/的注释示意)就是上文所说的“别的工作” 。

这种处理方法的实质就是在程序等待事件的过程中间隔性地插入一些有意义的工作，好让CPU不是一直无谓地等待。

(2) 逻辑完备性

我觉得逻辑完备性是状态机编程最大的优点。

不知道大家有没有用C语言写过计算器的小程序，我很早以前写过，写出来一测试，那个惨不忍睹啊！当我规规矩矩的输入算式的时候，程序可以得到正确的计算结果，但要是故意输入数字和运算符号的随意组合，程序总是得出莫名其妙的结果。

后来我试着思维模拟一下程序的工作过程，正确的算式思路清晰，流程顺畅，可要碰上了不规矩的式子，走着走着我就晕菜了，那么多的标志位，那么多的变量，变来变去，最后直接分析不下去了。

很久之后我认识了状态机，才恍然明白，当时的程序是有逻辑漏洞的。如果把这个计算器程序当做是一个反应式系统，那么一个数字或者运算符就可以看做一个事件，一个算式就是一组事件组合。对于一个逻辑完备的反应式系统，不管什么样的事件组合，系统都能正确处理事件，而且系统自身的工作状态也一直处在可知可控的状态中。反过来，如果一个系统的逻辑功能不完备，在某些特定事件组合的驱动下，系统就会进入一个不可知不可控的状态，与设计者的意图相悖。

状态机就能解决逻辑完备性的问题。

状态机是一种以系统状态为中心，以事件为变量的设计方法，它专注于各个状态的特点以及状态之间相互转换的关系。状态的转换恰恰是事件引起的，那么在研究某个具体状态的时候，我们自然而然地会考虑任何一个事件对这个状态有什么样的影响。这样，每一个状态中发生的每一个事件都会在我们的考虑之中，也就不会留下逻辑漏洞。

这样说也许大家会觉得太空洞，实践出真知，某天如果你真的要设计一个逻辑复杂的程序，

我保证你会说：哇！状态机真的很好用哎！

(3)程序结构清晰

用状态机写出来的程序的结构是非常清晰的。

程序员最痛苦的事儿莫过于读别人写的代码。如果代码不是很规范，而且手里还没有流程图，读代码会让人晕了又晕，只有顺着程序一遍又一遍的看，很多遍之后才能隐约地明白程序大体的工作过程。有流程图会好一点，但是如果程序比较大，流程图也不会画得多详细，很多细节上的过程还是要从代码中理解。

相比之下，用状态机写的程序要好很多，拿一张标准的UML状态转换图，再配上一些简明的文字说明，程序中的各个要素一览无余。程序中有哪些状态，会发生哪些事件，状态机如何响应，响应之后跳转到哪个状态，这些都十分明朗，甚至许多动作细节都能从状态转换图中找到。可以毫不夸张的说，有了UML状态转换图，程序流程图写都不用写。

套用一句广告词：谁用谁知道！

3、状态机的三种实现方法

状态机的实现无非就是 3 个要素：状态、事件、响应。转换成具体的行为就 3 句话。

发生了什么事？
现在系统处在什么状态？
在这样的状态下发生了这样的事，系统要干什么？

用 C 语言实现状态机主要有 3 种方法：switch—case 法、表格驱动法、函数指针法。

switch—case 法

状态用 switch—case 组织起来，将事件也用switch—case 组织起来，然后让其中一个 switch—case 整体插入到另一个 switch—case 的每一个 case 项中。

「程序清单 List4 ：」

switch(StateVal)
{
    case S0:
  switch(EvntID)
  {
   case E1:
    action\_S0\_E1(); /\*S0 状态下 E1 事件的响应\*/
    StateVal = new state value;/\*状态迁移，不迁移则没有此行\*/
    break;
   case E2:
    action\_S0\_E2(); /\*S0 状态下 E2 事件的响应\*/
    StateVal = new state value;
    break;
   ......
   case Em:
    action\_S0\_Em(); /\*S0 状态下 Em 事件的响应\*/
    StateVal = new state value;
    break;
   default:
    break;
  }
  break;
    case S1:
  ......
  break;
    ......
    case Sn:
  ......
  break;
    default:
  break;
}

上面的伪代码示例只是通用的情况，实际应用远没有这么复杂。虽然一个系统中事件可能有很多种，但在实际应用中，许多事件可能对某个状态是没有意义的。

例如在程序清单 List4中，如果 E2、······ Em 对处在 S0 状态下的系统没有意义，那么在 S0 的 case 下有关事件E2、······ Em 的代码根本没有必要写,状态 S0 只需要考虑事件 E1 的处理就行了。

既然是两个 switch—case 之间的嵌套，那么就有一个谁嵌套谁的问题，所以说 switch—case法有两种写法：状态嵌套事件和事件嵌套状态。这两种写法都可以，各有利弊，至于到底选用哪种方式就留给设计人员根据具体情况自行决断吧。

关于 switch—case 法还有最后一点要说明，因为 switch—case 的原理是从上到下挨个比较，越靠后，查找耗费的时间就越长，所以要注意状态和事件在各自的 switch 语句中的安排顺序，不推荐程序清单 List4 那样按顺序号排布的方式。出现频率高或者实时性要求高的状态和事件的位置应该尽量靠前。

表格驱动法

如果说 switch—case 法是线性的，那么表格驱动法则是平面的。表格驱动法的实质就是将状态和事件之间的关系固化到一张二维表格里，把事件当做纵轴，把状态当做横轴，交点[Sn , Em]则是系统在 Sn 状态下对事件 Em 的响应。

如图 4，我把表格中的 Node_SnEm 叫做状态机节点，状态机节点 Node_SnEm 是系统在 Sn状态下对事件 Em 的响应。这里所说的响应包含两个方面：输出动作和状态迁移。状态机节点一般是一个类似程序清单 List5 中的结构体变量。

struct fsm\_node
{
    void (\*fpAction)(void\* pEvnt);
    INT8U u8NxtStat;
};

程序清单 List5 中的这个结构体有两个成员：fpAction 和 u8NxtStat。fpAction 是一个函数指针，指向一个形式为 void func(void * pEvnt)的函数， func 这个函数是对状态转移中动作序列的标准化封装。

也就是说，状态机在状态迁移的时候，不管输出多少个动作、操作多少个变量、调用多少个函数，这些行为统统放到函数 func 中去做。

把动作封装好了之后，再把封装函数 func 的地址交给函数指针 fpAction，这样，想要输出动作，只需要调用函数指针 fpAction 就行了。

再看看上面的 func 函数，会发现函数有一个形参 pEvnt，这是一个类型为 void * 的指针，在程序实际运行时指向一个能存储事件的变量，通过这个指针我们就能获知关于事件的全部信息，这个形参是很有必要的。事件一般包括两个属性：事件的类型和事件的内容。

例如一次按键事件，我们不仅要知道这是一个按键事件，还要知道按下的到底是哪个键。事件的类型和状态机当前的状态可以让我们在图 4 的表格中迅速定位，确定该调用哪个动作封装函数，但是动作封装函数要正确响应事件还需要知道事件的内容是什么，这也就是形参pEvnt 的意义。

由于事件的多样性，存储事件内容的数据格式不一定一样，所以就把 pEvnt 定义成了 void * 型，以增加灵活性。有关 fpAction 的最后一个问题：如果事件 Em 对状态 Sn 没有意义，那么状态机节点Node_SnEm 中的 fpAction 该怎么办？我的答案是：那就让它指向一个空函数呗！前面不是说过么，什么也不干也叫响应。

u8NxtStat 存储的是状态机的一个状态值。我们知道，状态机响应事件要输出动作，也就是调用函数指针 fpAction 所指向的那个封装函数，函数调用完毕后程序返回主调函数，状态机对事件的响应就算结束了，下一步就要考虑状态迁移的问题了。

可能要保持本状态不变，也可能要迁移到一个新的状态，该如何抉择呢？u8NxtStat 存储的状态就是状态机想要的答案！

图 4 的这张表格反映在 C 语言代码里就是一个二维数组，第 1 维就是状态机的状态，第 2维就是统一分类的事件，而数组的元素则是程序清单 List5 中的结构体常量。如果程序中使用表格驱动法，还需要注意一些特别的事项。要将状态当做表格的横轴，那么就要求状态值集合必须满足以下条件：

(1) 该集合是一个递增的等差整数数列

(2) 该数列初值为 0

(3) 该数列等差值为 1

“事件” 作为纵轴，其特点和要求与用来做横轴的“状态” 完全一致。在 C 语言提供的数据类型中，没有比枚举更符合以上要求的可选项了，极力推荐将状态集合和事件类型集合做成枚举常量。**表格驱动法的优点：**调用接口统一，定位快速。

表格驱动法屏蔽了不同状态下处理各个事件的差异性，因此可以将处理过程中的共性部分提炼出来，做成标准统一的框架式代码，形成统一的调用接口。根据程序清单 List5 中的状态机节点结构体，做成的框架代码如程序清单 List6 所示。

表格驱动法查找目标实际上就是一次二维数组的寻址操作，所以它的平均效率要远高于switch—case 法。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

状态机节点结构体，做成的框架代码如程序清单 List6 所示。

表格驱动法查找目标实际上就是一次二维数组的寻址操作，所以它的平均效率要远高于switch—case 法。

[外链图片转存中…(img-udKzsQRT-1715645512314)]
[外链图片转存中…(img-7O0MSK17-1715645512315)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

如果你需要这些资料，可以戳这里获取

2401_85013826

关注

23
点赞
踩
28

收藏

觉得还不错? 一键收藏
0
评论
2024年最新嵌入式编程之状态机_状态机编程(1)，2024年最新面试物联网嵌入式开发系统架构

状态机是一个这样的东东：状态机(state machine)有 5 个要素，分别是状态(state)、迁移(transition)、事件(event)、动作(action)、条件(guard)。状态：一个系统在某一时刻所存在的稳定的工作情况，系统在整个工作周期中可能有多个状态。例如一部电动机共有正转、反转、停转这 3 种状态。一个状态机需要在状态集合中选取一个状态作为初始状态。迁移：系统从一个状态转移到另一个状态的过程称作迁移，迁移不是自动发生的，需要外界对系统施加影响。
复制链接

扫一扫