嵌入式编程之状态机_状态机编程(2)，2024年最新Golang岗面试12家大厂成功跳槽

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

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

程序清单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 法。

「程序清单 List6 ：」

extern struct fsm_node g_arFsmDrvTbl[][]; /*状态机驱动表格*/
INT8U u8CurStat = 0; /*状态暂存*/
INT8U u8EvntTyp = 0; /*事件类型暂存*/
void* pEvnt = NULL; /*事件变量地址暂存*/
struct fsm_node stNodeTmp = {NULL, 0}; /*状态机节点暂存*/
u8CurStat = get_cur_state(); /*读取当前状态*/
u8EvntTyp = get_cur_evnt_typ(); /*读取当前触发事件类型*/
pEvnt = (void*)get_cur_evnt_ptr(); /*读取事件变量地址*/
stNodeTmp = g_arFsmDrvTbl[u8CurStat ][u8EvntTyp ];/*定位状态机节点*/
stNodeTmp.fpAction(pEvnt ); /*动作响应*/
set_cur_state(stNodeTmp.u8NxtStat); /*状态迁移*/
…

表格驱动法好则好矣，但用它写出来的程序还有点儿小问题，我们先来看看按照表格驱动法写出来的程序有什么特点 。

前面说过，表格驱动法可以把状态机调度的部分做成标准统一的框架代码，这个框架适用性极强， 不管用状态机来实现什么样的应用， 框架代码都不需要做改动， 我们只需要根据实际应用场合规划好状态转换图，然后将图中的各个要素(状态、事件、动作、迁移，有关“条件”要素一会儿再说)用代码实现就行了，我把这部分代码称作应用代码。

在应用代码的.c 文件中， 你会看到一个声明为 const 的二维数组， 也就是图 4 所示的状态驱动表格， 还会看到许多彼此之间毫无关联的函数， 也就是前面提到的动作封装函数。这样的一份代码， 如果手头上没有一张状态转换图， 让谁看了也会一头雾水， 这样的格式直接带来了代码可读性差的问题。

如果我们想给状态机再添加一个状态，反映到代码上就是给驱动表格再加一列内容，同时也要新添加若干个动作封装函数。如果驱动表格很大， 做这些工作是很费事儿的， 而且容易出错。如果不小心在数组中填错了位置， 那么程序跑起来就和设计者的意图南辕北辙了，

远没有在 switch—case 法中改动来得方便、安全。上面说的只是小瑕疵， 其实最让我不爽的是表格驱动法不能使用干货 | 嵌入式之状态机编程 中 g_stFSM那样的 Extended State Machine(对这个词组还有印象吧？)！Extended State Machine 的最大特点就是状态机响应事件之前先判断条件，根据判定结果选择执行哪些动作，转向哪个状态。

也就是说，系统在状态 Sn 下发生了事件 Em 后，转向的状态不一定是唯一的，这种灵活性是 Extended State Machine 的最有价值的优点。

回过头来看看程序清单 List5 中给出的状态机节点结构体，如果系统在状态 Sn 下发生了事件 Em， 状态机执行完 fpAction 所给出的动作响应之后， 必须转到 u8NxtStat 指定的状态。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
这种灵活性是 Extended State Machine 的最有价值的优点。

回过头来看看程序清单 List5 中给出的状态机节点结构体，如果系统在状态 Sn 下发生了事件 Em， 状态机执行完 fpAction 所给出的动作响应之后， 必须转到 u8NxtStat 指定的状态。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-3OdQUsTt-1713214678339)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！