CN101980167A - 一种嵌入式实时操作系统的任务状态机管理机制运行方式 - Google Patents

Abstract

本发明涉及操作系统的技术领域，公开了一种嵌入式实时操作系统的任务状态机管理机制运行方式。为了解决现有技术中设计工作很复杂等等技术问题，提出了如下技术方案。本发明运行方式，其特征是：配套使用两个以上的任务状态机；包括以下步骤：第一步骤，初始化；第二步骤，收集和判断是否有事件发生的信息；如果没有则继续收集和判断；如果有则进行第三步骤；第三步骤，获取事件的索引号；第四步骤，根据得到的事件索引号，搜索事件的响应动作列表、并获取相关内容；第五步骤，执行动作列表中相关内容所规定的动作；第六步骤，回到第二步骤。有益效果是：新增了统一的任务状态机管理机制，使设计工作的复杂性、以及对任务与任务之间耦合程度的要求均大大降低；有利于程序的构件化、标准化；封装性好，更换或升级操作系统方便。

Description

一种嵌入式实时操作系统的任务状态机管理机制运行方式

技术领域

本发明涉及操作系统的技术领域，特别是涉及一种嵌入式实时操作系统的任务状态机管理机制运行方式。

背景技术

目前，嵌入实时操作系统在嵌入式系统中的应用已经越来越广。实时操作系统应用到嵌入式系统中的一个重要目的，就是为了实现多任务的并发运行机制，以此来实现嵌入式系统的实时响应的功能。

状态机(有时也称任务状态机)是软件编程中的一个重要概念，在一个思路清晰而且高效的程序中，必然有状态机的身影出现。当状态机应用到实施操作系统中，对每个任务实现状态机的管理，是一个必须解决的问题。

在系统层中嵌入式实时操作系统，具备了对各个任务的运行状态进行调度和管理的功能，任务状态机的功能是在应用层实现的。

在现有技术中，就嵌入式实时操作系统的应用而言，各个任务都是自己管理自己的状态机，因而造成：设计工作很复杂，对任务与任务之间的耦合程度要求高，难以施行和提高程序的构件化、标准化。

发明内容

现有技术中的嵌入式实时操作系统，其存在的技术问题有：设计工作很复杂，对任务与任务之间的耦合程度要求高，难以施行和提高程序的构件化、标准化；为了解决上述技术问题，本发明提出了如下技术方案。

1.一种嵌入式实时操作系统的任务状态机管理机制运行方式；

在嵌入式实时操作系统中配套使用多个任务状态机；所述的多个为两个以上；

所述的运行方式包括以下步骤：

第一步骤，初始化；所述的初始化包括任务状态机的初始化；

第二步骤，收集和判断是否有事件发生的信息；如果没有事件发生的信息，则继续收集和判断；如果出现事件发生的信息、则进行第三步骤；

第三步骤，获取事件的索引号；每一个具体事件为信号事件或者为消息事件；

第四步骤，根据得到的事件索引号，搜索事件的响应动作列表、并获取相关内容；

第五步骤，执行动作列表中相关内容所规定的动作；

第六步骤，回到第二步骤。

2.所述的任务状态机的初始化包括：各个任务依据任务状态机管理机制对状态机数据结构体的定义，根据自己在运行过程中的状态、事件和动作三者的对应关系，构建自己的状态机数据结构；

任务在状态机数据结构的基础上，利用任务状态机管理机制对自己的任务状态机进行管理。

3.所述的数据结构体，其包括如下六个成员：

任务索引号为成员一；每一具体的任务索引号，对应着规定的任务；

任务状态为成员二，其反映了所属任务的当前状态；

事件触发源为成员三，能够接受的触发条件有两类事件：信号事件和消息事件；

事件组为成员四，其为对应列表；任务状态机运行中的事件、状态、触发条件之三者，对应列表对它们的动作关系或者对应变化关系或者对应响应关系作了全部列表；

动作列表为成员五，其对任务所要执行的所有动作进行了全部列表，即对任务功能函数进行全部列表；

机制为成员六，其为任务状态迁移时三要素的对应表；所述的三要素是指：状态、事件和动作；对应表中的有效成员数量与任务的状态数量相同；

含有上述六个成员的数据结构，其对任务的状态、任务的事件响应、任务的动作建立起了联系关系，形成了任务状态机管理机制的统一管理对象。

4.所述的嵌入式实时操作系统的任务状态机管理机制，其包括设有以下的五个内容：第一个内容是操作系统提供的事件标志机制，第二个内容是事件触发源、并且触发源中设有对位的定义，第三个内容是事件组、并且事件组中设有事件索引号，第四个内容是机制、并且机制中设有动作索引号，第五个内容是动作列表、并且动作列表中设有动作函数的入口地址；

所述的第三步骤及其后续步骤、即获取事件索引号的步骤和后续步骤，它们包括以下进行的工作：

第一工作，获取事件标志数据；

第二工作，判断事件标志数据中被触发的位，它在事件触发源中有定义吗？如果有定义的则进行以下的第三工作，如果没有定义的则返回所述的第二步骤；

第三工作，判断事件是否为信号事件：如果是信号事件的，则进行信号事件的后续作业，后续作业之后返回到所述的第二步骤；如果不是信号事件的，则进行消息事件的后续作业，后续作业之后返回到所述的第二步骤。

5.所述的第三工作，判断事件为信号事件，其后续作业包括以下内容：

作业a.目标任务根据自己的当前状态以及信号内容，在事件组中寻找相应的事件索引号；如果找到就进行以下作业b，如果没有找到就直接返回到第二步骤；

作业b.根据事件索引号，从机制中寻找相应的动作索引号；

作业c.根据动作索引号，从动作列表中找到动作函数的入口地址；

作业d.执行该函数、即执行任务的动作；

作业e.返回所述的第二步骤。

6.所述的第三工作，判断事件不是信号事件，则进行消息事件的后续作业，包括如下内容：

作业a.目标任务从消息队列中取出消息；

作业b.目标任务取出消息后，根据消息头和自己当前状态，在事件组中寻找相应的事件索引号；如果找到就进行以下的作业c，如果没有找到就直接返回到第二步骤；

作业c.根据获得的事件索引号，从机制中寻找相应的动作索引号；

作业d.根据获得的动作索引号，从动作列表中找到动作函数的入口地址；

作业e.执行该函数、即执行任务的动作；

作业f.返回所述的第二步骤。

本发明的有益效果是：本发明的技术方案，新增了统一的任务状态机管理机制，使设计工作的复杂性大大降低，并对任务与任务之间耦合程度的要求也大大降低；本发明还对施行和提高程序的构件化、标准化带来很大好处。另外，本发明中的结构具有封装性好的特点，可以方便的更换或升级操作系统。

附图说明

图1是现有技术的系统架构示意图；

图2是本发明的系统架构示意图；

图3是本发明的流程示意图之一；

图4是本发明的流程示意图之二；

图5是本发明的流程示意图之三；图4中的左部最后三个流程小框和右部最后三个流程小框，在本图中作了合并处理；

图6是实施例七中的示意图之一；

图7是实施例七中的示意图之二。

本专利文件中，相关的中英文名词对照：索引号/ID；任务索引号/instance_id；任务状态/state；事件触发源/event_sources；信号事件/singal；消息事件/message；事件组/events；动作列表/actions_table；机制/machine；事件标志/event flag；消息头/msg_head；消息体/msg_data。

下面结合附图和具体实施方式对本发明作进一步的详细说明。

具体实施方式

本发明的特点是：在嵌入式实时操作系统的基础上，实现一种任务状态机管理机制，使各个任务利用该状态机管理机制，管理自己的状态机和响应事件；并且将操作系统完全封装，使应用层与系统层隔离。在应用层，设计者只需关注任务的状态、发生的事件、要及时响应的动作，即状态迁移图中的状态、事件和动作三个要素。状态迁移图的相关技术属于本技术领域的普通技术人员熟知的现有技术；书店中和英特网中有众多的书籍、资料予以了介绍，由于篇幅关系，不再赘述。

现有技术的系统架构，如图1所示；本发明技术的系统架构，如图2所示；不论是现有技术还是本发明技术，状态机管理机制是介于应用层与系统层之间的。

本发明关键内容是将嵌入式系统中的任务状态机机制抽象化为一种具有状态机功能的数据结构体。所有任务的状态机机制的都是在这个数据结构体基础上实现的。任务的状态迁移图上的每一个要素在该数据结构体中都有体现，所以从任务的状态迁移图到转换成代码也非常容易。该数据结构体具有封装性好的特点，使用该数据结构体能降低的任务设计时的复杂度，并且大大减少了任务与任务之间的耦合程度，提高程序的构件化和标准化程度。

在每个任务拥有统一的状态机数据结构体的基础上，任务即可以运行状态机管理机制对自己的状态机进行管理。状态机管理机制的运作基础是嵌入式操作系统，所使用的技术是一般操作系统都具备的基本功能，如信号量(semaphores)、事件标志(event flag)、消息队列(message queue)。

在本发明中，可以将这些操作系统功能函数的接口完全封装起来，也可以不把这些操作系统功能函数的接口完全封装起来；如果选用前者，将接口完全封装起来，本发明就具有通用性强的特点，只要更改操作系统接口函数，就可以将工程(或项目)移植到任何嵌入式实时操作系统，而不需要更改任务的任何代码，从而提高了程序的通用性。

下面，结合图3对本发明作说明、介绍和解释。

本发明的一种嵌入式实时操作系统的任务状态机管理机制运行方式，具有如下的特点。

在嵌入式实时操作系统中配套使用多个任务状态机；所述的多个为两个以上；

所述的运行方式包括以下步骤：

第一步骤，初始化；所述的初始化包括任务状态机的初始化。说明：初始化工作，包括将有关的程序、数据在事先输入，系统调试完毕等；还包括在每次开机通电时，相关的数据结构建立等等。

第二步骤，收集和判断是否有事件发生的信息；如果没有事件发生的信息，则继续收集和判断；如果出现事件发生的信息、则进行第三步骤。

第三步骤，获取事件的索引号；每一个具体事件为信号事件或者为消息事件。说明：在全部事件集合中，既有信号事件也有消息事件，还可能是目标任务所不接受的事件；对每一个具体事件而言，它不可能既是信号事件又是消息事件；因此，每一个具体事件而言，可能是信号事件、也可能是消息事件，但不能是同时具有两种性质的事件，当然，还可能是目标任务所不接受的事件。

第四步骤，根据得到的事件索引号，搜索事件的响应动作列表、并获取相关内容。

第五步骤，执行动作列表中相关内容所规定的动作。

第六步骤，回到第二步骤。

实施例一

本实施例对状态机数据结构体的定义作描述、介绍和说明。

状态机数据结构体是状态机管理机制的核心内容，每个任务都必须有该状态机数据结构体定义的状态机数据结构。状态机数据结构体定义如下所示：

typedef struct  _state_machine

{

    UINT    instance_id；

    UINT    state；

    UINT    event_count；

    UINT    action_count；

    UINT    event_sources；

    const   LOCAL_EVENT *events；

    const   ACTION *action_table；

    STATE_ACTIONS machine[STM_MAX_STATES]；

}STATE_MACHINE；

在本实施例中，数据结构体包括实现任务功能的八个成员：instance_id(任务索引号)，state(任务状态)，event_count  (事件总数)，action_count(动作总数)，event_sources(事件触发源)，events(事件组)，actions_table(动作列表)，machine(机制)。

(1)instance_id代表该状态机所属任务的索引号。

(2)state代表该任务当前所处的状态。

(3)event_count代表状态机运行中会发生的事件总数。

(4)action_count代表状态机运行中应执行的动作总数。

(5)event_sources为事件触发源，代表该任务所有能接受的事件触发条件。事件触发条件分为信号Signal和消息Message两类。信号Signal代表单纯信号事件的触发，如外部中断，定时器，信号量等。每一个信号事件占EventSource事件触发源数据的一个bit位。消息message代表含有有效数据传递事件的触发，消息事件仅占EventSource事件触发源数据的一个bit位。

(6)events是事件组，代表任务状态机运行时，事件与状态，触发条件的对应列表。状态迁移图中每一个事件都必须在该表中体现出来。该成员数据结构体定义如下所示：

typedef  struct _local_event

{

    UINT event_type；

    UINT event_index；

    UINT valid_state；

    UINT global_value；

}LOCAL_EVENT；

   event_type表示事件类型，即信号类或消息类。

   event_index表示事件索引号。

   valid_state表示事件发生时任务的有效状态。

   global_value表示任务收到的触发事件的数据。

(7)actions_table代表任务要执行的所有动作列表。

(8)machine是机制，代表任务状态迁移时三要素(即状态，事件，动作)的对应表。该队列的有效成员数量与任务的状态数量相同。该队列成员的数据结构体定义如下所示：

typedef struct _state_actions

{

    UINT count；

    const ACTION_LIST *actions；

}STATE_ACTIONS

count表示任务在此状态时可能发生的事件总数。

actions表示任务在此状态时事件与动作的对应关系，该成员的数据结构体定义如下所示：

typedef struct _action_list

{

    UINT event；

    UINT action_count；

    ACTION_ENTRY actions[MAX_ACTIONS]；

}ACTION_LIST

event表示事件的索引号。

action_count表示此事件发生时要执行的动作数量。

actions表示此事件发生时要执行的所有动作的队列，队列中的每一个成员代表了一个动作，成员的数据结构体定义如下所示：

typedef  struct _action_entry

{

    UINT action_index；

    UINT arg；

}ACTION_ENTRY；

action_index表示该动作在action_table中的索引号。

arg表示要传给动作函数的参数。

实施例二

本实施例对状态机管理机制，结合图4、图5进行描述、介绍和说明；其中，图4中的左部最后三个流程小框和右部最后三个流程小框，在图5中作了合并处理。

(1)状态机管理过程的相关描述

状态机管理机制工作过程，参见图4进行理解。首先在任务状态机运行之前，要对任务的状态机进行初始化，即建立该任务状态机的结构。然后启动任务状态机管理机制。

初始化后，任务等待事件发生，即利用操作系统的事件标志(event flag)机制来等待事件标志被触发。事件标志被触发后，任务首先获取事件标志数据；其次，判断事件触发源(event_sources)中有没有该位的定义，如果没有则说明此事件不是目标任务所能接受的事件，那么就拒绝接受该事件、并挂起；如果数据中被触发的位在事件触发源(event_sources)中有相应位的定义，那么不仅可以接受该事件，而且可以据此来判断是信号事件还是消息事件。

上述判断后，需要根据是信号事件还是消息事件来进行不同的后续处理，即：如果事件触发源(event_sources)对该位的定义为信号事件的，则按信号事件进行相关的后续处理；如果事件触发源(event_sources)对该位的定义为消息事件的，则按消息事件进行相关的后续处理。

(2)信号事件处理过程的相关描述

信号事件处理过程，参见图4进行理解。当信号事件发生时，利用操作系统的事件标志(event flag)机制通知目标任务；目标任务被唤醒后得到事件标志数据，根据该数据中被触发的位与事件触发源(event_sources)中相应位的定义，通过判断是信号事件，然后目标任务根据所发生的信号和自己当前状态，在events(事件组)中寻找相应的事件索引号(如果未找到说明事件不是目标任务所能接受的事件，则拒绝接受该事件并挂起)；根据获得的事件索引号，从machine(机制)中寻找相应的动作索引号；根据获得的动作索引号，从actions_table(动作列表)找到动作函数的入口地址；最后执行该函数、即实施任务的动作，完成后返回。

(3)消息事件处理过程的相关描述

消息事件处理过程，参见图4进行理解。当有任务需要向另外一个任务发送消息时，该任务首先将消息发送到目标任务的消息队列中；然后利用操作系统的事件标志(event flag)机制通知目标任务；目标任务得到事件标志数据后，根据该数据中被触发的位与事件触发源(event_sources)中相应的位的定义，判断是消息事件、并从自己的消息队列中取出消息。

消息的数据结构体定义如下：

typedef struct _str_msg

{

    UINT  msg_head；

UINT msg_data[4]；

}MESSAGE

msg_head(消息头)该数据由源任务的索引号和消息索引号组成；

msg_data(消息体)该数据包含了消息实际数据。

目标任务在取出整个消息后，根据消息头和自己当前状态，在events(事件组)中寻找相应的事件索引号：如果找不到事件索引号的，说明目标任务在当前状态下不接受此事件，则拒绝接受该事件并挂起；如果获得事件索引号的，接着再从machine(机制)中寻找相应的动作索引号；然后根据获得的动作索引号，从actions_table(动作列表)找到动作函数的入口地址；最后执行该函数、即实施任务的动作，完成后返回。

实施例三

本实施列介绍状态机管理机制的实施。

1.任务状态机初始化：首先任务需要进行任务的状态机初始化操作，该操作主要是为了实现一个状态机数据结构，并由状态机管理机制将该状态机数据结构挂到状态管理机制的状态机链表上。该状态机数据结构主要目的是确立任务的状态、任务的事件响应、任务的动作这三者之间的联系。当该状态机数据结构挂到目标链表上后，状态机管理机制即可对任务的状态机进行管理操作。

2.等待事件发生并获取事件标志：建立好数据机后任务即可启用状态机管理机制去完成后续操作。状态机管理机制首先是等待事件的发生。当有事件发生时，事件的标志即刻被管理机制获取。

3.事件索引号搜索过程：当状态机管理机制获得事件标志后，首先判断是否是信号事件？如果是的，则直接获取事件索引号。如果不是信号事件，那就是消息事件，就要先从消息队列中获取消息再获取事件索引号。获取事件索引号的过程是根据所获取的事件标志(信号事件)或所获得的消息(消息事件)结合此时任务的状态，从该任务的状态机数据结构中的LOCAL_EVENT成员指针指向的数据结构链表中，搜索该事件所对应索引号的ID值。

4.搜索事件的响应动作列表：事件的响应动作列表保存在任务状态机结构中的machine队列中。machine的每一个成员由状态、事件、响应动作列表组成。所以当状态机管理机制获得了事件的索引号，就可以根据任务的状态，搜索到事件的响应动作列表。

5.执行响应动作列表中的动作：状态机管理机制根据动作列表中所提供的动作入口函数，去执行动作。当所有动作执行完毕，状态机管理机制返回第2处、继续等待下一个事件的发生。

实施例四

本实施例介绍操作系统隔离功能的实现。

任务状态机管理机制中将所有的操作系统接口函数都加以封装，并提供相应的接口函数给任务调用。应用层的任务只有调用封装好的接口函数才可以访问操作系统的数据和接口函数。

当有更换操作系统的要求时，只需更改管理机制中的系统函数封装的内容即可。应用层的任务无需作任何更改。这样就实现了操作系统隔离功能。

实施例五

本实施例结合图4和图5，举例说明对信号事件的处理过程。图4是本发明的流程示意图之二；图5是本发明的流程示意图之三；图4中的左部最后三个流程小框和右部最后三个流程小框，在图5中作了合并处理。

第一，初始化；所述的初始化包括任务状态机的初始化；

第二，不断的收集和判断：有无事件发生？

第三，有事件发生，依靠操作系统提供的事件标志(event flag)机制通知目标任务；

第四，目标任务获得事件标志数据后，在事件触发源(event_sour-ces)寻找到相应的位；

第五，根据上述相应的位而判断出：事件为信号事件；

第六，目标任务根据自己的当前状态以及信号内容，在事件组(events)中寻找到相应的事件索引号；

第七，根据事件索引号，从机制(machine)中寻找相应的动作索引号；

第八，根据动作索引号，从动作列表(actions_table)找到动作函数的入口地址；

第九，执行该函数、即执行任务的动作；

第十，返回以上的第二处，继续不断的收集和判断：有无事件发生？

实施例六

本实施例结合图4和图5，举例说明对消息事件的处理过程。图4是本发明的流程示意图之二；图5是本发明的流程示意图之三；图4中的左部最后三个流程小框和右部最后三个流程小框，在图5中作了合并处理。

第一，初始化；所述的初始化包括任务状态机的初始化；

第二，不断的收集和判断：有无事件发生？

第三，有事件发生，依靠操作系统提供的事件标志(event flag)机制通知目标任务；

第四，目标任务获得事件标志数据后，在事件触发源(event_sour-ces)寻找到相应的位；

第五，根据上述相应的位而判断出：事件不是信号事件而是消息事件；

第六，目标任务从消息队列中取出消息；

第七，目标任务取出消息后，根据消息头和自己当前状态，在事件组(events)中寻找到相应的事件索引号；

第八，根据获得的事件索引号，从机制(machine)中寻找相应的动作索引号；

第九，根据获得的动作索引号，从动作列表(actions_table)找到动作函数的入口地址；

第十，执行该函数、在函数中根据消息体(msg_data)进行相应的处理，即执行任务的动作；

第十一，返回以上第二处。

实施例七

本实施列介绍发明的任务状态机管理机制在用户界面任务中的应用。

在用户界面(user interface，以下简称UI)的任务运行时，主要响应来自键盘的按键中断的信号事件和其他任务需要在UI上显示的消息事件。以下是UI任务利用任务状态机管理机制运行时的实施例。

本实施列下面将要分别描述的内容有：

第一、任务状态机的初始化；

第二、任务运行；

第三、启动消息事件发生；

第四、一号按键信号事件发生；

第五、二号按键信号事件发生；

第六、显示消息事件发送。

第一、任务状态机的初始化

UI任务的状态切换和事件响应视图如图6所示。根据图6，UI任务的状态机数据结构便可以建立起来，数据结构可定义如下：

STATE_MACHINE UI_STAM＝

{

    1，/*instance_id：UI任务的任务ID号值为1*/

    0，/*state：UI任务的初始化状态的状态值为0*/

    4，/*event_count：UI任务运行中总共会发生4个事件*/；

    4，/*action_count：UI任务运行中总共会有4个动作会执行*/

    0xE0，/*event_sources：UI任务运行中要相应的事件源，0xE0

            对应的2进制数为11100000，第八位位置1表示UI任

            务能接受消息事件，第七位置1表示UI任务能接受一

            号按键的信号事件，第六位置1表示UI任务能接受二

            号按键的信号事件*/

    uiEventPtr，/*events：UI任务的事件列表指针*/

    uiActPtr，/*action_table UI任务的动作列表指针*/

    uiStm，/*machine[STM_MAX_STATES]：UI任务状态机的状态、事

             件和动作的对应列表*/

}

UI任务的事件索引号可定义如下一个枚举变量uiActEnum：

enum uiEventId

{

   key1Event＝0，  /*一号按键事件索引号*/

   key2Event，     /*二号按键事件索引号*/

   runEvent，      /*启动事件索引号*/

   displayEvent    /*显示事件索引号*/

}；

UI任务的事件列表uiEventPtr可定义如下：

LOCAL_EVENT uiEventPtr[]＝

{

  /*事件类型    事件索引号    任务状态    事件信息数据*/

 {  signalType，key1Event，   uiRun，     0x40}，

 {  signalType，key2Event，   uiRun，     0x20}，

 {  msgType，   runEvent，    uiIni，     0x01}，

 {  msgType，   displayEvent，uiRun，     0x21}，

}

signalType：信号类型；

msgType：消息类型；

key1Event：一号按键事件；

key2Event：二号按键事件；

runEvent：运行事件；

displayEvent：显示事件：

uiRun：UI任务的运行状态，该值为1；

uiIni：UI任务的初始化状态，该值为0；

0x40：一号按键信号事件的标志位为第7位(0x40的二进制数为01000000)；

0x20：二号按键信号事件的标志位为第6位(0x20的二进制数为00100000)；

0x11：任务ID号为0的任务发送的1号消息(高4位表示发出消息的任务ID

      号，低4位表示消息的ID号)；

0x21：任务ID号为2的任务发送的1号消息；

UI任务的动作列表uiActPtr可定义如下：

ACTION uiActPtr[]＝

{

   key1Action，     /*一号按键事件的响应动作函数*/

   key2Action，     /*二号按键事件的响应动作函数*/

   runAction，      /*运行消息事件的响应动作函数*/

   displayAction    /*显示消息事件的响应动作函数*/

}；

该数组对应一个枚举变量uiActEnum定义如下

enum uiActEnum

{

   key1Act＝0，

   key2Act，

   runAct，

   displayAct

}；

通过该枚举变量的定义就可以找到uiActPtr[]中对应的成员函数。

UI任务状态机的状态、事件和动作的对应列表uiStm可定义如下：

STATE_ACTIONS uiStm[4]＝

{

   {                       /*UI在初始化状态要响应的事件相应

                             的动作*/

     1，                   /*有1个事件*/

      {runEvent，          /*事件索引号：启动事件*/

        {1，               /*该事件发生会执行一个动作*/

           {{runAct，0}}   /*执行runAct动作，没有参数需要传递*/

       }

    }

 }

 {                         /*UI在运行状态要响应的事件相应的动作*/

   3，                     /*有3个事件*/

   {key1Event，            /*事件索引号：一号按键事件*/

    {1，                   /*该事件发生会执行一个动作*/

      {{key1Act，0}}       /*执行key1Act动作，没有参数需要传递*/

    }

 }

 {key2Event，              /*事件索引号：二号按键事件*/

  {1，                     /*该事件发生会执行一个动作*/

    {{key2Act，0}}         /*执行key2Act动作，没有参数需要传递*/

  }

 }

 {displayEvent，           /*事件索引号：显示事件*/

   {1，                    /*该事件发生会执行一个动作*/

     {{displayAct，0}}     /*执行显示动作，没有参数需要传递*/

   }

  }

 }

}

第二、任务运行

建立好状态机数据结构后，UI任务将该数据结构挂接到任务状态机数据链表上，即可启用状态机管理机制。状态机管理机制则开始查询UI任务的事件标志数据，直到UI任务的事件标志数据的某一位被改变，而改变的这一位就表示有一个相应的事件发生。

第三、启动消息事件发生

启动消息事件是UI任务在初始化状态时由ID号为0的任务发给UI任务消息事件，当UI收到该事件时要做的动作是将UI的任务状态切换到运行状态。如图7所示。

1、启动消息为任务ID号为0的任务发给UI任务事件，该消息包含消息头msg_head为0x01。0号任务将消息发送到UI任务的消息接收队列后，会将UI任务状态机管理机制所查询的事件标志数据的最高位置1，即将该数据变为0x80。

2、当UI任务的状态机管理机制发现自己查询的事件的标志数据被改变，则获取被改变的标志数据。首先将获取的标志数据与UI状态机数据结构中事件触发源(event_sources)相比较，发现有相同的置位，并且该位是最高位，表示有消息事件发生(最高位代表消息事件，其余位对应不同的信号事件)。

3、状态机管理机制从UI的消息接收队列中获取0号任务发来的消息，并从获得的消息中取得消息头数据(0x01)。此时状态机管理机制根据消息头数据查询UI任务的事件列表uiEventPtr，找到成员项{msgEvent，runEvent，uiIni，0x01}。核对任务状态、消息类型后，获得事件索引号runEvent。

4、状态机管理机制查询UI任务状态机的状态、事件和动作的对应列表uiStm。根据UI任务当前状态为初始化状态，找到对应的成员项：

{1，                       /*有1个事件*/

  {runEvent，              /*事件索引号：启动事件*/

    {1，                   /*该事件发生会执行一个动作*/

      {{runAct，0}}        /*执行runAct动作，没有参数需要传递*/

    }

}

该成员项表明，当UI任务在初始化状态时只有一个runEvent事件会发生，并且当该事件发生时，只有一个runAct动作要被执行。

5、任务状态机管理机制获得runAct，即可在UI任务的动作列表uiActPtr中找到相应的动作入口函数runAction，并立刻执行。

6、runAction函数中会将UI任务的状态切换为运行状态，即将UI_STAM结构中的state变量改为1(UI任务的运行状态的状态值为1)。当runAction函数执行完毕，表示任务状态机管理机制对启动消息事件响应完毕，此时状态机管理机制继续轮询事件标志数据，等待事件发生。

第四、一号按键信号事件发生

一号按键信号事件是在UI处于运行状态时，用户按下一号按键，此时UI就要响应一号按键被按下时所执行的动作。

1、当用户按下一号按键时，一号按键的中断响应函数即被调用。该中断响应函数会将UI任务状态机管理机制所查询的事件标志数据的第7位置1，即将该数据变为0x40。

2、当UI任务的状态机管理机制发现自己查询的事件的标志数据被改变，则获取被改变的标志数据(0x40)。首先任务状态机管理机制将获取的标志数据与UI状态机数据结构中事件触发源event_sources相比较，发现有相同的置位，并且该位不是最高位，表示有信号事件发生。

3、此时状态机管理机制根据标志数据(0x40)查询UI任务的事件列表uiEventPtr，找到成员项{signalEvent，key1Event，uiRun，0x40}。核对任务状态、消息类型后，获得事件索引号key1Event。

4、状态机管理机制查询UI任务状态机的状态、事件和动作的对应列表uiStm。根据UI任务当前状态为运行状态，找到对应的成员项：

{                          /*UI在运行状态要响应的事件相应的动作*/

  3，                      /*有3个事件*/

    {key1Event，           /*事件索引号：一号按键事件*/

     {1，                  /*该事件发生会执行一个动作*/

       {{key1Act，0}}      /*执行key1Act动作，没有参数需要传递*/

       }

     }

    {key2Event，           /*事件索引号：二号按键事件*/

     {1，                  /*该事件发生会执行一个动作*/

      {{key2Act，0}}       /*执行key2Act动作，没有参数需要传递*/

     }

    }

  {displayEvent，          /*事件索引号：显示事件*/

   {1，                    /*该事件发生会执行一个动作*/

    {{di splayAct，0}}     /*执行显示动作，没有参数需要传递*/

   }

  }

}

该成员项表明，当UI任务在运行状态时有3个事件会发生，分别是key1Event、key2Event、displayEvent。任务状态机根据获得的事件名key1Event可知该事件的响应动作为key1Act。

5、任务状态机管理机制获得key1Act，即可在UI任务的动作列表uiActPtr中找到相应的动作入口函数key1Action，并立刻执行。

6、当key1Action函数执行完毕，表示任务状态机管理机制对一号按键信号事件响应完毕，此时状态机管理机制继续轮询事件标志数据，等待事件发生。

第五、二号按键信号事件发生

二号按键信号事件是在UI处于运行状态时，用户按下二号按键，此时UI就要响应二号按键被按下时所执行的动作。

1、当用户按下二号按键时，二号按键的中断响应函数即被调用。该中断响应函数会将UI任务状态机管理机制所查询的事件标志数据的第6位置1，即将该数据变为0x20。

2、当UI任务的状态机管理机制发现自己查询的事件的标志数据被改变，则获取被改变的标志数据(0x20)。首先任务状态机管理机制将获取的标志数据与UI状态机数据结构中事件触发源event_sources相比较，发现有相同的置位，并且该位不是最高位，表示有信号事件发生。

3、此时状态机管理机制根据标志数据(0x20)查询UI任务的事件列表uiEventPtr，找到成员项{signalEvent，key2Event，uiRun，0x20}。核对任务状态、消息类型后，获得事件名称key2Event。

4、状态机管理机制查询UI任务状态机的状态、事件和动作的对应列表uiStm。根据UI任务当前状态为运行状态，找到对应的成员项：

{key2Event，               /*事件索引号：二号按键事件*/

 {1，                      /*该事件发生会执行一个动作*/

   {{key2Act，0}}          /*执行key2Act动作，没有参数需要传递*/

 }

}

任务状态机根据获得的事件名key2Event可知该事件的响应动作为key2Act。

5、任务状态机管理机制获得key2Act，即可在UI任务的动作列表uiActPtr中找到相应的动作入口函数key2Action，并立刻执行。

6、当key2Action函数执行完毕，表示任务状态机管理机制对二号按键信号事件响应完毕，此时状态机管理机制继续轮询事件标志数据，等待事件发生。

第六、显示消息事件发送

显示消息事件是在UI处于运行状态时，2号任务发送给UI任务的消息事件。UI任务收到该消息后，根据消息中的数据进行显示动作。

1、显示消息为任务ID号为2的任务发给UI任务事件，该消息包含消息头msg_head为0x21。2号任务将消息发送到UI任务的消息接收队列后会将UI任务状态机管理机制所查询的事件标志数据的最高位置1，即将该数据变为0x80。

2、当UI任务的状态机管理机制发现自己查询的事件的标志数据被改变，则获取被改变的标志数据。首先任务状态机管理机制将获取的标志数据与UI状态机数据结构中事件触发源event_sources相比较，发现有相同的置位，并且该位是最高位，表示有消息事件发生。

3、状态机管理机制从UI的消息接收队列中获取该消息，并从获得的消息中取得消息头数据(0x21)。此时状态机管理机制根据消息头数据查询UI任务的事件列表uiEventPtr，找到成员项{msgEvent，displayEvent，uiRun，0x21}。核对任务状态、消息类型后，获得事件名称displayEvent。

4、状态机管理机制查询UI任务状态机的状态、事件和动作的对应列表uiStm。根据UI任务当前状态为运行状态，找到对应的成员项：

{displayEvent，            /*事件索引号：启动事件*/

  {1，                     /*该事件发生会执行一个动作*/

    {{displayAct，0}}      /*执行runAct动作，没有参数需要传递*/

  }

任务状态机根据获得的事件索引号displayEvent、可知该事件的响应动作为displayAct。

5、任务状态机管理机制获得displayAct，即可在UI任务的动作列表uiActPtr中找到相应的动作入口函数displayAction，并立刻执行。

6、displayAction函数中会从消息中获得中剩余的消息数据，该数据就是2号任务要就UI显示的数据。当displayAction函数将数据显示完毕，表示任务状态机管理机制对显示消息事件响应完毕，此时状态机管理机制继续轮询事件标志数据，等待事件发生。

Claims (6)

1.一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：

在嵌入式实时操作系统中配套使用多个任务状态机；所述的多个为两个以上；

所述的运行方式包括以下步骤：

第一步骤，初始化；所述的初始化包括任务状态机的初始化；

第二步骤，收集和判断是否有事件发生的信息；如果没有事件发生的信息，则继续收集和判断；如果出现事件发生的信息、则进行第三步骤；

第三步骤，获取事件的索引号；每一个具体事件为信号事件或者为消息事件；

第四步骤，根据得到的事件索引号，搜索事件的响应动作列表、并获取相关内容；

第五步骤，执行动作列表中相关内容所规定的动作；

第六步骤，回到第二步骤。

2.根据权利要求1所述的一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：所述的任务状态机的初始化包括：各个任务依据任务状态机管理机制对状态机数据结构体的定义，根据自己在运行过程中的状态、事件和动作三者的对应关系，构建自己的状态机数据结构；

任务在状态机数据结构的基础上，利用任务状态机管理机制对自己的任务状态机进行管理。

3.根据权利要求2所述的一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：所述的数据结构体，其包括如下六个成员：

任务索引号(instance_id)为成员一；每一具体的任务索引号，对应着规定的任务；

任务状态(state)为成员二，其反映了所属任务的当前状态；

事件触发源(event_sources)为成员三，能够接受的触发条件有两类事件：信号事件(singal)和消息事件(message)；

事件组(events)为成员四，其为对应列表；任务状态机运行中的事件、状态、触发条件之三者，对应列表对它们的动作关系或者对应变化关系或者对应响应关系作了全部列表；

动作列表(actions_table)为成员五，其对任务所要执行的所有动作进行了全部列表，即对任务功能函数进行全部列表；

机制(machine)为成员六，其为任务状态迁移时三要素的对应表；所述的三要素是指：状态、事件和动作；对应表中的有效成员数量与任务的状态数量相同；

含有上述六个成员的数据结构，其对任务的状态、任务的事件响应、任务的动作建立起了联系关系，形成了任务状态机管理机制的统一管理对象。

4.根据权利要求1所述的一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：

所述的嵌入式实时操作系统的任务状态机管理机制，其包括设有以下的五个内容：第一个内容是操作系统提供的事件标志(event flag)机制，第二个内容是事件触发源(event_sources)、并且触发源中设有对位的定义，第三个内容是事件组(events)、并且事件组中设有事件索引号，第四个内容是机制(machine)、并且机制中设有动作索引号，第五个内容是动作列表(actions_table)、并且动作列表中设有动作函数的入口地址；

所述的第三步骤及其后续步骤、即获取事件索引号的步骤和后续步骤，它们包括以下进行的工作：

第一工作，获取事件标志数据；

第二工作，判断事件标志数据中被触发的位，它在事件触发源中有定义吗？如果有定义的则进行以下的第三工作，如果没有定义的则返回所述的第二步骤；

第三工作，判断事件是否为信号事件：如果是信号事件的，则进行信号事件的后续作业，后续作业之后返回到所述的第二步骤；如果不是信号事件的，则进行消息事件的后续作业，后续作业之后返回到所述的第二步骤。

5.根据权利要求4所述的一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：

所述的第三工作，判断事件为信号事件，其后续作业包括以下内容：

作业a.目标任务根据自己的当前状态以及信号内容，在事件组(events)中寻找相应的事件索引号；如果找到就进行以下作业b，如果没有找到就直接返回到第二步骤；

作业b.根据事件索引号，从机制(machine)中寻找相应的动作索引号；

作业c.根据动作索引号，从动作列表(actions_table)中找到动作函数的入口地址；

作业d.执行该函数、即执行任务的动作；

作业e.返回所述的第二步骤。

6.根据权利要求4所述的一种嵌入式实时操作系统的任务状态机管理机制运行方式，其特征是：

所述的第三工作，判断事件不是信号事件，则进行消息事件的后续作业，包括如下内容：

作业a.目标任务从消息队列中取出消息；

作业b.目标任务取出消息后，根据消息头和自己当前状态，在事件组(events)中寻找相应的事件索引号；如果找到就进行以下的作业c，如果没有找到就直接返回到第二步骤；

作业c.根据获得的事件索引号，从机制(machine)中寻找相应的动作索引号；

作业d.根据获得的动作索引号，从动作列表(actions_table)中找到动作函数的入口地址；

作业e.执行该函数、即执行任务的动作；

作业f.返回所述的第二步骤。

Images