论状态机与模块化_谈谈我对理想编程模型的看法_图文

1、 三、 无法分割的功能 有些功能， 它不长也不短， 大致与系统的查询周期相当， 且不好分片； 另外还有些功能， 漫长又无法分片，但是系统允许在它运行期间独占控制权。这两类功能，就像骨头一样，把 程序卡在那里，我们称之为 骨头 功能。吃饭时吃到骨头怎么办？有时你运气好，刚好是 块软骨，那就把它咬碎吞了。实在是咬不动的骨头怎么办？那就只有硬吞了。如果你的消化 够好，那块骨头能够很好地融入你的身体；如果你消化不行，那就可能造成硬伤了。编程也 一样， 遇到骨头不要急，先仔细分析， 看能不能把它分片， 如果能分片，那就变成裹脚布了。 如果不能分片，而且系统允许，那就直接嵌入这么个长时间执行的功能，但是程

2、序员要很清 楚由此对系统造成的影响， 特别是在后面追加功能的时候， 这个潜在的威胁可能会影响新功 能的实现。 那么硬骨头究竟会对我们的系统造成什么影响呢？ 1） 首先，由于它拖慢了系统的运行，使系统的响应周期变长。当然，这都是对处于主 执行绪中（即中断外）的输入响应造成影响，如果对一个输入的所有响应都在中断 中完成，那是不会受到硬骨头影响的。 2） 其次，由于它拖慢了系统的运行周期，而查询周期没有变，可能会造成某些输入的 丢失。例如，有个系统的查询周期是 10ms，但是系统中的一个写 FLASH 功能可能 要 60ms，那么它就可能丢失 5 个 10ms 触发消息。 其实硬骨头也不可怕， 对于

3、每一块硬骨头， 我们在编写的时候都分析清楚由此对系统造 成的影响，消除由此产生的不良影响，就不会有问题了。很多时候，小骨头（长度在一个查 询周期左右） 几乎不会对系统有任何不良影响， 甚至于在编程时很多小骨头都不知道它的存 在。对于大骨头，我们就要谨慎对待了（因为大骨头很少，所以也花不了多少时间） 。一定 要清楚在它执行期间，系统无法响应其它输入（消息） ，由此造成的消息丢失和处理滞后必 须在系统能承受的范围内。 另外一方面，对于一些频率高的消息（如果 1ms 定时消息） ，我们要清楚地知道它有丢 失的可能，因此，不要试图在它等于某一个特定值时执行一些操作，而应该改成在它大于等 于某个特定值时

4、执行一些操作。 概括一下，对待无法分片的功能，我们要做到：咬碎软骨头，吞掉硬骨头。 四、 模块化编程 一听到模块化，可能很多人会说，这有什么可讲的，现在哪个人编程不是模块化啊？如 果现在还有谁编的程序只有一个源文件，估计他是过不了试用期的。_，当然肯定有例外， 比如 4 位机编程，不过那离我们太遥远了。 但是， 你划分的模块别人是否认同？你编程时是否纠结过这个函数到底该放到哪个模块 内呢？ 模块化不清晰的主要原因在于划分模块没有一个统一的标准， 每个程序员、 每个应用都 不一样，结果模块化也就因人而异了。 那么，到底要怎么划分模块才能清晰呢？接触过 C+或面向对象编程的人都知道，在面 向对象程

5、序里面，把所有的东西都看作对象，每个对象就是现实世界中的一个物体。从面向 对象的角度来看，划分模块就很简单了。每个对象划分成一个模块，就这么容易。 但是我们单片机编程用的是 C 语言呀，又不是 C+，哪来的类和面向对象？不错，我们 用的是 C 语言，但是我们不需要用类，我们只是用对象的观点来划分模块。比如：你的系统 有键盘、LED、USART0、USART1、SPI0，那么就将它们各自划分成一个模块。 从我编程的经验来看，我们尽量用模块来表示对象（单个物体） ，而不是用模块来表示 类。比如上面，我们要定义 USART0、USART1 两个模块，而不是定义一个 USART 模块。这 样做的好处是

6、当我们要实现一个器件的特殊功能时， 就不会牵扯到其它器件， 从而不会使模 块的实现复杂化。 概括一下，用面向对象的观点来划分模块。 五、 状态机与模块化 状态机模块化编程的理论基础是：将一个系统划分成若干个子系统，那么，整个系统的 状态表现为所有子系统的状态之和； 整个系统对输入的响应表现为所有子系统对输入的响应 之和。 例如，一个血氧系统有三个主要的子系统：血氧采集、血氧存储、血氧发送。那么这三 个子系统所做的事加起来，就是整个系统所做的事。反过来，我们可以把整个系统要做的事 分给这三个子系统做，每个子系统只做自己份内的事就行了。这样一来，系统的设计就变得 很简单了。 六、 管道 管道用于在

7、各个模块间传递数据。可能很多人会想，直接定义几个全局变量不就行了 吗？扯那么多弯弯绕干什么？这个想法其实也没有错， 管道的本质就是全局变量， 管道封装 了对全局变量的操作，使模块间的数据传送更简单，更不容易出错。 最常用管道就是 FIFO（先进先出） 。发送数据的模块把数据写进 FIFO，接收数据的模块 从 FIFO 读出数据，所读数据的顺序与写入的顺序一致，并且 FIFO 能够缓冲一定量数据。换 句话说，发送数据的模块只管往里面写数据，而不用等它处理完毕。 很显然，管道的应用使各个模块各干各的，不必同步。 其实，大家都用过管道，只是没有将它封装起来，或者没有叫它 管道 而已。比如， 一个使用

8、中断的串口程序，它有两个 FIFO，一个接收 FIFO，一个发送 FIFO。接收数据时， 中断内将数据存入接收 FIFO 内，然后中断外从 FIFO 读出数据进行处理。 管道不只用于中断内/外传送数据，还用于模块间传送数据。比如，血氧系统中，血氧 采集模块采到数据后，将它放入一个 FIFO 中，然后就可以开始下一次采集了。而血氧存储 模块总是从 FIFO 中读取数据，然后将它存到 FLASH 中。 管道不但有 FIFO，还有 LIFO（后进先出） 、按优先级出队等多种方式，不过这些咱们都 用得很少。 附 A：一个 FIFO 的典型接口 一个 FIFO 所应该具有的典型对外接口如下： void

9、FifoCreate(FIFO *ptFifo, void *puPool, INT32U uWidth, INT32U uDepth; 建立 INT32U FifoIn(FIFO *ptFifo, void *puBuf, INT32U uReqNum; /入队. INT32U FifoOut(FIFO *ptFifo, void *puBuf, INT32U uReqNum; /出队. void FifoClean(FIFO *ptFifo; /清空. INT32U FifoLen(FIFO *ptFifo; /得到队列长度.有效数据个数. 其中，ptFifo 是所要操作的 FIFO。pu

10、Pool 是该 FIFO 所用的缓冲池，实际的数据就是存在这 里面的。uWidth 为 FIFO 中单个元素的宽度（字节数） 。uDepth 为整个 FIFO 的深度，就是缓 冲池能容纳的最大元素个数。puBuf 为出队/入队时的目标缓冲区，uRealNum 为请求出队/ 入队的元素个数。 附 B：BOS 在使用 switch 将漫长的功能剪碎的时候，如果碎片比较多，整个函数看起来就是一团 麻，编程的时候很容易出错。如果一个功能编好以后，后面又要加上几个步骤，这个时候会 很麻烦。另外，用 switch 实现的分步功能，整体看起来前后逻辑性不强，也就比较难理解。 如果我们将 switch 改头换

11、面，封装一下，看起来就会爽很多，编程的时候也会觉得前 后是连在一起操作的。BOS 就是因此而产生的。BOS 封装了 switch 实现分片的功能，使分片 的功能更加容易书写，也更容易读懂。 块操作流,Block Operation Stream,简称 BOS.BOS 用块操作的方式建立模拟任务,实现并发 执行.每一个模拟任务看起来像操作系统中的任务,可以与其它程序实现并发执行,但它们又 不是真正的任务,各个任务之间不存在抢占资源,互斥访问的问题,因为任何一个任务的执行 都不用担心被其它任务打断. BOS 用于前后台系统中 , 使用 switch case 实现 , 将任务分成很多个小块执行 . BOS 是用于帮助程序员书写出更加易懂的程序的,而不是实现一个操作系统. BosTaskStart(ptTask； /启动任务。 BosTaskEnd(ptTask; /结束任务。 BosTaskBodyBegin(ptTask； /开始一个任务体。 BosTaskBodyEnd(ptTask； /结束一个任务体。 BosTaskStepBegin(ptTask,STEP_NO； /