ITRON系统使用方法

状态迁移	说明	系统调用
Nonexistent->dormant	任务生成	cre_tsk
Nonexistent->ready	不可	-
Nonexistent->run	不可	-
Nonexistent->wait	不可	-
Nonexistent->suspend	\不可	-
Dormant->nonexistent	任务的删除	del_tsk
Dormant->ready	任务的启动	sta_tsk
Dormant->run	不可（注1）	-
Dormant->wait	不可	-
Dormant->suspend	不可	-
Ready->nonexistent	不可	-
Ready->dormant	任务的强制终了	ter_tsk
Ready->run	在ready状态的任务中，优先级成为最高的任务	-
Ready->wait	不可	-
Ready -> suspend	任务的强制等待	sus_tsk
Run->nonexistent	任务的终了并自删除	Exd_tsk
Run->dormant	正常终了	Ext_tsk
Run->ready	任务的自中断，接受系统的调度（注2）	-
Run->wait	等待要因的发生：时间等待唤醒等待 Event Flag等待 Semaphore等待消息等待内存块等待	Wai_tsk Slp_tsk Wai_flg Wai_sem Rcv_msg Get_blk
Run->suspend	不可	-
Wait->nonexistent	不可	-
Wait->dormant	任务的强制终了	Tet_tsk
Wait->ready	等待要因发生： Time out 唤醒等待 Eventflag等待 Semaphore等待消息等待内存块等待	Wup_tsk Sys_wup Set_flg Sig_sem Snd_msg Rel_blk
Wait->run	不可（注3）	-
Wait->wait_suspend	任务的强制等待	Sus_tsk
Suspend->nonexistent	不可	-
Suspend->dormant	任务的强制终了	Ter_tsk
Suspend->ready	强制等待的解除	Rsm_tsk
Suspend->run	不可（注4）	-
Suspend->wait	不可	-
Suspend->wait_suspend	不可	-
Wait_suspend->wait	强制等待的解除	Rsm_tsk
Wait_suspend->suspend	等待要因的解除	Vsnd_sig

表3.1.3.2-ITRON任务的状态迁移关系表

※1. 通过sta_tsk调用后有时会从dormant状态迁移到run状态，但实际上是经过ready状态后迁移到run状态的。

※2. 当出现比自任务有更高有限级的任务或对于自任务发行rot_rdp系统调用。

※3. 通过等待要因发生后，有时从suspend状态迁移到run状态名单实际上是经过ready状态的。

※4. 通过rsm_tsk系统调用发现有时从suspend状态迁移到run状态，但实际上是经过ready状态的。

3.1.4 任务的应用

ü 创建任务

在Itron系统中创建任务存在两种方式，一种方式是静态注册任务；另一种方法是动态的创建任务。

动态创建任务主要通过cre_tsk调用来实现的。

ü 激活任务

Itron系统中，初始创建的任务的状态是Dormant状态，这个时候任务还处于系统无法调度的状态，所以必须激活任务，激活任务的系统调用是sta_tsk，作用就是将指定任务由Dormant状态迁移到Ready状态。

ü 终止任务

在Itron系统中如果需要实现将任务由ready state, run state, wait state, suspend state, wait-suspendstate迁移到Dormant状态的话，需要通过下面两种方式实现，正常终止和强制终止。

正常终止是任务自身主动放弃系统的使用权。

强制终止是任务自身出现错误，无法自主释放系统使用权，这个时候只能通过其他任务来完成对本任务使用权的剥夺。

实现任务终止的系统调用主要有下面三个：

² ext_tsk system call

The task that issued the ext_tsk system call isswitched from the run state to the dormant state.

² exd_tsk system call

The task that issued the exd_tsk system call isswitched from the run state to the non-existent state.

² ter_tsk system call

The task specified by the parameters isforcibly switched to the dormant state.

ü 删除任务

实现任务状态从Run或者Dormant状态切换到nonexistent状态，实现这个功能主要通过下面两个调用来完成的。

² exd_tsk system call

The task that issued the exd_tsk system call isswitched from the run state to the non-existent state.

² del_tsk system call

The task specified by the parameters isswitched from the dormant state to the non-existent state.

3.1.5 任务的设计

3.1.5.1 任务划分的原则

在将一个软件系统分解成并行任务时, 主要需考虑的是系统内功能的异步性。

可以通过分析数据流图中的变换, 确定哪些变换可以并行, 而哪些变换在本质上是顺序的,通过这种方法, 划分出任务: 一个变换对应一个任务,或者一个任务包括几个变换。

一个变换是应该成为一个独立的任务, 还是应该和其它变换一起组成一个任务, 决定的原则如下:

Ø I/O 依赖性(Dependency on Input/Output Device)

Ø 时间关键性的功能 (Time-critical functions-Hard Deadline)

Ø 计算量大的功能Heavy Computation function

Ø 功能内聚Functional relations

Ø 时间内聚Temporal relations

Ø 周期执行的功能Cyclic executing function

3.1.5.2 I/O 依赖性

如果换依赖于I/O, 那么它运行的速度常常受限于与它互操作的I/O 设备的速度在这种情况下, 变换应成为一个独立的任务。

Ø 在系统中创建多个与I/O 设备相当数目的I/O 任务

Ø I/O 任务只实现与设备相关的代码

Ø I/O 任务的执行只受限于I/O 设备的速度而不是处理器

Ø 在任务中分离设备相关性

3.1.5.3 时间关键性的功能

对于事件关键性的功能对响应的时间要求的第一重要的，所以对于这类任务的响应的优先级别比较高。

Ø 将有时间关键性的功能分离出来组成独立运行的任务

Ø 赋予这些任务高的优先级以满足对响应时间的需要

3.1.5.4 计算功能

复杂的计算功能一般运行时间比较长，所以对于这类功能的设计的原则如下：

Ø 计算功能占用CPU 的时间多

Ø 捆绑计算功能成任务赋予它们较低优先级运行, 能被高优先级的任务

Ø 抢占消耗CPU 的剩余时间

Ø 保持高优先级的任务是轻量级的

Ø 多个计算任务可安排成同优先级按时间片循环轮转

3.1.5.5 时间内聚

Ø 将在同一时间内完成的各功能，即使这些功能是不相关的组成功能组形成一个任务

Ø 功能组的各功能是由相同的外部事件驱动的，如时钟等这样每次任务接收到一个事件, 它们都可以同时执行

Ø 组成一个任务，减少了系统的开销

虽然时间内聚在结构化设计中并不被认为是一个好的模块分解原则, 但在任务级是可以被接受每个功能都作为一个独立的模块来实现, 从而达到了模块级的功能内聚, 这些模块组合在一起, 又达到了任务级的时间内聚

3.1.5.7 任务设计的误区

Ø 错误的任务划分原则

任务使用SUPSPEND/RESUME 太频繁，是由于任务划分过细任务的当成功能使用，改进的方法是将任务变成子程序使用。

当事件发生时调用子程序，任务划分的太粗将子程序划分为任务，

得到消息后又立即检查另外的信息，不要使用轮循的方式直接使用事件驱动方式

Ø 优先级倒置

当低优先级的任务向高优先级的任务发送消息时，高优先级的任务不能运行，直到低优先级的任务发送消息后才能运行。

这种情况下就没有必要分为两个任务只需要使低优先级的任务调用子程序即可。

Ø 死锁

两个任务同时相互等待对方的信号，导致它们永远不能运行。

为了避免死琐将共享资源统一排序所有的任务按序来访问多个资源。

等待的事件没有发生过或者不具备等待事件的发生条件。

3.2 同步和通信管理

在多任务的实时系统中，一项工作的完成往往要通过多个任务或多个任务与多个中断处理过程(ISRs)共同完成。它们之间必须协调动作互相配合，甚至需要交换信息进行通信。这些通信和同步的需要是：

1. 任务能和其他任务及ISRs 交换数据

2. 任务能以以下方式与其他任务进行同步

² 单向同步一个任务与另一个任务或一个ISR 同步

² 双向同步两个任务相互同步

² 与同步一个任务与几个事件同时同步

² 或同步一个任务与几个事件中的任何第一个到达事件同步

3. 任务必须能对共享资源进行互斥访问

为了满足任务间通信同步和互斥的需要，同时保证资源被安全的使用，必须对多个相关任务在执行的次序上进行协调。ITRON系统主要提供了如下一些同步机制。

ü Event Flag，任务间的协调功能。

ü Semaphore，对系统资源进行排他访问。

ü MailBox，任务之间进行的信息通信。

以下章节将针对这些系统同步方式进行详细的说明。

3.2.1 Event Flag

在多任务处理系统中，需要等到一个任务终了后，其他任务再开始启动的等候功能，这个时候，需要拥有对其他任务是否终了进行判断的能力，ITRON系统中提供了EventFlag.来实现这个机能。

ITRON系统中，一个EventFlag是ITRON工作区中的一个32 位的变量。32 位中的每一位都是表示一个事件标志，事件标志有两种状态，设置（1）和清除（0）。当一个标志处于设置状态时，表示相关的事件已经发生了，任务和ISRs 可以使用事件标志来向其他任务发送信号, 表示事件已发生。

图3.2.1-1 EventFlag示意图

上图中，人相当于任务，火把表示Event Flag，在没有得到通知之前，等待信号的人处于等待状态，当发送信号的人发送了通知之后，处于等待状态的人将被激活，便开始自己的作业了，这就是一个完整的Event Flag使用过程事例。

3.2.1.1 基本调用

ITRON系统中提供下面基本调用，实现了Event Flag的基本机能，详细描述可以参照手册：

cre_flg: Generates an event flag.

del_flg: Deletes an event flag.

set_flg: Sets a bit pattern.

clr_flg: Clears a bit pattern.

wai_flg: Checks a bit pattern.

pol_flg: Checks a bit pattern (by polling).

twai_flg: Checks a bit pattern (with timeoutsetting).

ref_flg: Acquires event flag information.

vget_flg: Acquires event flag ID number.

vset_flg1: Sets a bit.

vwai_flg1:Checks a bit.

3.2.1.2 Event Flag的应用

一般来说，Event Flag为任务之间的等待操作提供了场所，下面是其操作方法：

任务间的等候需要能够传达Event的任务和等待Event发生的任务，传达Event任务通过发行set_flag调用来传递信息，另一方面等待Event任务对事件发行等待调用，并且参照等候模式。

如果event flag的位模式与等待位模式一致时，任务可以继续进行处理，如果不一致，任务就不做继续处理，迁移到wait状态，并进入到event的等待队列中。

图3.2.1.2-1表示了两个Task通过32Bit Event Flag传递信息的范例：

图3.2.1.2-1 32Bit Event Flag使用时Task间同步方法

图3.2.1.2-2表示了4个Task利用1Bit Event Flag传递信息的执行范例：

图3.2.1.2-21Bit Event Flag使用时Task间同步方法

ü Event Flag的生成

Event Flag的生成是通过cre_flg系统调用进行的，在Itron系统中，cre_flg调用从系统工作区中创建一个32bit的事件标志组，并返回EventFlag的ID号。

ü Event Flag的删除

通过del_flg调用可以实现对EventFlag的删除，当产生删除操作的时候，该系统中存在等待本Flag操作的任务，这个时候，处于等待Eveng Flag的任务将解除等待操作，并迁移到Ready状态。

ü Event Flag的设定

通过set_flg调用，可以实现Event Flag的设定，当本调用发行后，处于等待Event Flag发行的任务的状态将由等待状态迁移到Ready状态。

ü Event Flag的清除

通过clr_flg调用，可以实现Event Flag的清除，保证Event Flag能够有初始化值。

ü Event Flag的等待

关于Event Flag的等待有三种方式，wai_flg, pol_flg, 和twai_flg，他们存在一些细微的差别。

² wai_flg：如果Event Flag已经被设置，系统将保持运行，如果没有存在满足运行条件的Flag，系统将迁移到等待状态，一直到满足运行条件的事件发生。

² pol_flg：任务直接查询EventFlag，如果满足运行条件的事件发生，系统保持运行状态不变，如果没有满足运行条件的事件发生，系统将直接返回，不进行等待操作。

² twai_flg：在制定的时间内，如果存在满足运行条件的事件发生，系统将保持运行状态不变，否则系统将按照指定的时间进行等待，Timer Out之后，系统迁移到Ready状态。

等待条件的设定：

因为Event Flag是一个32Bit的位群，所以在进行Event Flag的设定的时候可以按照条件的逻辑进行设定，主要的逻辑有And和Or两种，需要根据实际情况进行有选择的使用。

And：多个条件同时存在的时候，才满足任务的运行条件。

Or：当设定的多个条件有一个满足的时候，运行条件成立。

3.2.2 Semaphore

虽然多任务系统中的各个Task可以共享各类资源，但是有些资源却一次只能被一个任务使用，因此防止同时动作的多个任务出现资源争执的需要，ITRON系统中提供了非负计数器-Semaphore，由管理资源个数的计数器进行资源使用得调配。

一个计数信号量是ITRON工作区中的一个16 位的变量，初始值可以是0~65535，表示可以使用的资源数量，初始值为0表示资源开始处于锁住状态，一个非0的值表示有多个资源供多个任务访问。

图3.2.2 –1Semaphore示意图

上图种停车场中的停车位置相当于存在使用竞争的资源，车相当于任务，空闲的车位数量相当于Semapjore的计数，当停车场中没有空位的时候，没有进入到停车场的车处于等待状态，当停车场中有车离开的时候，表示当前有空闲的车位，这时就有车可以进入，并且空闲的位置与可以进入的车是等数量的，这个就是一个Semaphore的使用范例，可以通过这个过程来体会Semaphore的使用。

ü 基于FIFS方式的等待机制

基于上图的示例，ITRON系统提供的方法是为任务提供等待队列，并且系统分配消息的方式是基于FIFS方法的，不区分任务的优先级别。

3.2.2.1 基本调用

ITRON系统中提供下面基本调用，实现了Semaphore的基本机能，详细描述可以参照手册：

cre_sem: Generates a semaphore

del_sem: Deletes a semaphore

sig_sem: Returns a resource

wai_sem: Acquires a resource

preq_sem: Acquires a resource (by polling)

twai_sem: Acquires a resource (with timeout setting)

ref_sem: Acquires semaphore information

vget_sid: Acquiressemaphore ID number

3.2.2.2 Semaphore的应用

一般来讲，semaphore是使用在任务之间排他控制的机构，下面是其操作的方法：

首先定义semaphore关联的资源数，对资源进行使用的 task首先进行资源的查询，如果能够从semaphore中获得资源的任务，任务将继续处理，然后在不需要使用资源时，便发行释放资源使用权的调用。

另外如果不能从semaphore中获得到所要的资源，任务便不能继续执行，迁移到wait状态，并登录到semaphore的等待队列中。处于等待的过程中的Task，如果可以得到资源，任务便从等待状态中脱出，迁移到ready状态。

图3.2.2.2-1表示了三个Task共享n个资源的情况，请参照：

图3.2.2.2-1利用Semaphore实现资源的排他使用

ü 创建信号量

Itron系统提供两种创建Semaphore的方法，一种是静态注册，另一种是通过系统调用来动态创建。

动态创建是通过cre_sem的方法来实现的。

ü 删除信号量

Itron系统中通过del_sem调用实现semaphore的删除。当删除semaphore被执行的时候，如果与本资源关联的任务等待队列中存在等待资源的任务时候，这些任务的状态将自动切换到Ready状态。

ü 释放资源

Itron系统中通过sig_sem调用实现资源的释放，可以归还资源的数量由sig_sem的参数决定。

ü 资源请求

主要有下面三种方式可以实现资源的请求：wai_sem、preq_sem和twai_sem；他们虽然都实现资源的申请，但是使用时还有一些细微的差别：

² wai_sem：当系统没有满足任务需要的资源数量的时候，系统状态将迁移到等待状态，直到系统中存在可以使用的资源为止。

² preq_sem：查询系统资源，如果存在满足系统需要的资源，则申请使用，如果没有满足需要的资源，系统将不申请资源，但是运行状态保持不变。

² twai_sem：在申请资源的时候，可以指定等待的时间，如果在制定的时间内申请到资源，则系统继续保持运行，如果在制定的时间内没有申请到可用的资源，系统将解除等待状态。

3.2.3 MailBox

为了实现任务之间的通信功能，ITRON提供了邮箱，并且邮箱包含有多任务应用的等待队列和邮箱专用的信息等待队列，除了任务之间的通信功能使用，也作为任务之间的协作功能使用。

当一个任务执行发送原语时，有两种可能性，一种可能是接收者已经处于等待状态；另外一种可能是消息发送时，接收者没有处于等待收信状态；下面将针对这两种情况进行示例说明：

1. 下图表示了消息先于收信者到达的情况，这时信件被投入信箱之后，便被缓存了起来，等待收信者取得信件。同时收信者到达之后，取得信件之后，便根据信件的指示进行相关作业。

图3.2.3-1 消息先于收信者到达的示例

基于上图消息等待方式的实现在ITRON系统的实现方法是为Message提供等待队列作为缓冲，并且对于从队列中取得信息的方式提供了两种方式作为支持，一种是FIFS，即先到达的信件被优先取走，另一种是对消息进行优先级别的指定，这样就可以保证高优先级别的消息可以得到优先的取得权。

ü 基于FIFS方式的等待机制

这种机制下所有消息都是平等的，他们的取得顺序完全取决于他们到达邮箱的时间，在邮箱中等待时间长的消息有优先被执行的权力。

图3.2.3-2基于FIFS的消息等待机制

ü 基于优先级方式的等待机制

这种机制下的消息是存在优先级别的，高优先级别的消息会获得优先执行权力，但是对于拥有相同优先级别的消息，他们的等待方式还是基于FIFS的方式进行的。

图3.2.3-3基于优先级方式的消息等待机制

2. 下图表示了收信者先于发信者到达的等待方式，这时收信者开始处于等待状态，当发信者将消息投入到邮箱之后，收信者便重新处于激活状态，这时只要执行条件满足，便可以根据消息的指示进行相关作业。

图3.2.3-4收信者先于消息到达的示例

ü 基于FIFS方式的等待机制

基于上图的示例，ITRON系统提供的方法是为任务提供等待队列，并且系统分配消息的方式是基于FIFS方法的，不区分任务的优先级别。

图3.2.3-5任务等待消息的Itron实现

3.2.3.1 基本调用

对邮箱的操作，系统主要提供了如下的调用：

cre_mbx:Generates a mailbox.

del_mbx:Deletes a mailbox.

snd_msg: Sendsa message.

rcv_msg:Receives a message.

prcv_msg:Receives a message (by polling).

trcv_msg:Receives a message (with timeout setting).

ref_mbx:Acquires mailbox information

vget_mid:Acquires mailbox ID number

3.2.3.2 MailBox的应用

一般来说，邮箱是任务之间信息通信过程中的场所，下面是使用方法：

在任务之间的信息通信里，需要给邮箱分配送信的任务（发报任务）和接受这个信息的任务（接受任务）。这时如果邮箱里已经有任务被排列在队列里，信息就会被传递给等待队列里的任务中。任务专用队列的先头任务将会从Wait状态迁移到Ready状态。

但是如果邮箱中还没有任务被排列在队列中，信息就会被排列到信息专用的队列中。不过发行snd_msg调用的任务不进行状态迁移。

还有接受信息的任务，对邮箱发行rcv_msg系统调用，接受消息，这时对象邮箱中已经有信息排列在队列里时，任务就会收取排列在队列里的信息。但是如果对象邮箱中还没有信息被排列在队列中的场合，任务就不能继续处理，被排列在对象邮箱的任务专用队列中，并且迁移到wait状态。不过在处于wait状态过程中，如果从其他任务那里得到信息的话，就可以接受信息，任务同时也会从wait状态解脱出来，迁移到ready状态。

如此循环进行，任务之间的通信便不断地进行下去。

图3.2.3.2-1说明了Task之间通过MailBox传递信息的使用示例：

图3.2.3.2-1Task利用MailBox进行通信

图3.2.3.2-2说明Task之间通过MailBox传递信息时的执行过程。

图3.2.3.2-2使用MailBox实现Task之间通信的处理流程

ü 创建邮箱

系统提供两种方式创建邮箱，静态注册和动态创建。系统动态创建邮箱是通过cre_mbx调用来实现的。

ü 删除邮箱

系统提供的del_mbx功能可以实现邮箱的删除，del_mbx发行后，如果等待队列中存在任务的时候，这些任务的状态将自动迁移到Ready状态。

ü 发送Event

系统提供的snd_msg调用实现Event的发送，当snd_msg发送之后，处于等待Event的任务的状态将由Wait状态迁移到Ready状态。

ü 接收Event

Itron系统提供三种方式来实现Event的接收，rcv_msg, prcv_msg,和trcv_msg，他们的差异是：

² rcv_msg：当邮箱中存在Evnet，则任务将直接获取Event并保持执行状态，当邮箱中没有Event的时候，任务将迁移到等待状态，直到邮箱中存在Event为止。

² prcv_msg：任务查询邮箱状态，如果存在Event，则取得Event，并继续执行，如果不存在Event，则任务不进行等待，继续保持执行。

² trcv_msg：在制定的时间内，邮箱中存在Event，则任务取得Event并执行，否则任务将等待指定的时间，之后迁移到Ready状态。

3.3 内存管理

任务在运行过程中对内存的需求是不断变化的不同的任务有不同的需要，OS 将内存当作一种资源来看并且在竞争的任务之间分配，这种资源就如同在竞争的任务间分配CPU 控制权一样。

3.3.1 概述

在ITRON系统中所指的内存管理是通过对软件的内存区域进行动态的管理，也就是说在需要申请使用的时候就要确保，如果不需要的时候就进行归还的功能。

图3.3.1-1 Memory Pool示意图

在ITRON系统中，内存管理方法采用的是固定分区方式瑾形，并且对内存区域分为内核区域核用户区域两个部分，并且这两个部分是单独进行管理的。系统内存池是否生成内核管理的各个对象时候使用的内存区域，这个区域里禁止作为用户内存池使用的。用户内存池是任务对内存区域进行申请时所使用的内存区域，并且这些内存池是相互独立的，所以可以通过给每个任务分配不同的内存池来避免任务见内存领域的竞争。

分区管理采用的是静态的内存分配方法, 系统分配和回收固定大小的存储块，其优点是存储块的分配和回收时间是确定的, 因为不会出现存储碎片, 因而也不需要做回收存储碎片, 进行合并等工作。

图3.3.1-2内存分区

系统中, 可定义多个分区, 每个分区中存储块的大小可不同,且可在分区中定义分区例如一个分区可以是另一个分区中的一块这就意味着存储块，可以很容易地被分为子存储块，另外还可以为同一块存储区域定义两个分区这样就可以从同一块存储区中分配两种不同尺寸的存储块。

3.3.2 基本调用

cre_mpl: Generates a memory pool.

del_mpl: Deletes the memory pool.

get_blk: Acquires a memory block.

pget_blk: Acquires a memory block (by polling).

tget_blk: Acquires a memory block (with timeoutsetting).

rel_blk: Release a memory block.

ref_mpl: Acquires memory pool information.

vget_pid: Acquires ID information of the memorypool.

3.3.3 内存池的创建

存在两种方式来创建内存池，一种是静态注册，另外一种方式是动态创建。动态创建的方法是通过cre_mpl调用来实现的。

3.3.4 内存池的清除

del_mpl调用可以实现内存池的删除，当执行删除操作时，如果存在内存申请的任务处于等待状态的话，这些任务将直接迁移到Ready状态。

3.3.5 内存申请

Itron系统中存在三种方式来实现内存的申请，get_blk, pget_blk,和 tget_blk，这三种调用的使用方式如下：

get_blk：申请指定大小的内存块，如果申请失败，任务状态将迁移到等待状态，直到有满足任务使用的内存被释放。

pget_blk：申请指定大小的内存块，如果申请成功，任务保持执行状态，如果失败，系统也不进行等待，直接运行其他指令。

tget_blk：如果没有申请到制订大小的内存，任务将等待指定的时间，之后迁移到Ready状态。

3.3.6 内存释放

当系统发行rel_blk调用之后，内存被归还给系统。

3.4 中断处理

中断是硬件机制，它向CPU发送信号，表示外部异步事件（无时序关系的随机事件）发生，如设备发送数据请求、内部运行异常等。

对中断的管理是OS的特征之一，一般来说当发生中断时，控制会转移到中断处理程序中，而控制转移到中断处理程序中的是硬件，软件不参与。但是在ITRON系统中，为了方便管理，内核提供了进行中断的通知，并将控制权转移给中断处理程序中的功能。

3.4.1 中断处理的管理

为了提高中断的吞吐率，ITRON系统将中断分成两个处理等级来进行中断处理，一种是直接启动的中断Handler；另一种是中断任务。

1. 直接启动的中断Handler，处理时间可以在短时间内完成，并且要求响应速度的中断请求，这种中断Handler不需要通过OS的管理也能够启动的中断处理专用程序。图3.4.1-1给出这种中断处理的执行过程。

图3.4.1-1 直接启动中断Handler处理流程

2. 中断任务，需要的处理时间比较长，并且对中断响应要求不是特别严格的场合使用。所谓中断任务指被中断处理程序唤醒或启动的中断处理专用任务。图3.4.1-2给出中断任务的处理流程。

图3.4.1-2中断任务的处理流程

3.4.2 中断例程的登录

直接启动中断的登录方法需要将中断服务Handler的地址登录到中断向量表中，但是如果中断任务就不能采用这种方式来定义，否则Itron系统将无法识别，所以中断任务的登陆方法就需要使用ITRON系统提供的支持来实现。

下面图解表示了系统对中断任务的管理方式，请参考：

图3.4.2-1 IDT和ISRs管理

在Itron系统中，为了实现对中断任务的管理，在idt中登陆了缺省的中断处理程序，在调用用户注册的Isr之前，需要将中断请求登陆到Itron管理的虚拟IDT表中，这样系统就能够通过对虚拟中断向量表的管理来实现对中断任务的管理。

3.4.3 中断中的处理

因为中断例程的特殊性，所以在进行中断程序的设计和使用需要特别注意，否则会发生一些意想不到的问题，下面从几个方面进行说明。

ü 寄存器的保存和恢复；

这个部分是每个使用中断例程的系统都需要考虑的，但是这个部分需要根据实际CPU使用要求进行，本教材中仅仅提出提示，并不给出具体的限定条件。

ü 系统调用的限制；

一般说来，在中断例程中发行Itron系统调用与通常任务没有特别的区别，所以为了保证系统的安全性，在中断中，对于创建/删除Itron管理对象、有迁移到资源获取等待状态可能的调用以及可能产生tron式样中没有定义的状态迁移等，都被禁止使用，下面是否详细信息，请在、设计时候务必遵守。

不能被中断例程使用的系统调用：

sta_tsk、ext_tsk、ter_tsk、dis_dsp、ena_dsp、chg_pri、rot_rdq、rel_wai、sus_tsk、rsm_tsk、slp_tsk、tslp_tsk、dly_tsk、wup_tsk、set_flg、wai_flg、twai_flg、sig_sem、snd_msg、rcv_msg、trcv_msg、pget_blf、tget_blk、loc_cpu、unl_cpu等。