完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
|
|
相关推荐
2个回答
|
|
有专家指出[1],把一个应用系统分为多少个任务且定义每一个任务各负责什么事情,这是一门艺术。对于任务的划分,并没有一个人人都要遵守的规则,不同的人来设计一个同样规格要求的系统,会有不同的方案。然而,到目前为止,很难看到有关论文对任务划分的方法有比较详细而系统的介绍。本文将深入研究划分任务的方法,并在此基础上,从实用的角度给出编写基于RTX51 Tiny实时操作系统的应用软件的指导方针。
1 任务的概念和应用软件开发过程 在嵌入式实时多任务系统开发中,用C语言代码表示的任务是一个无限的循环程序。任务不能有返回,不能有退出出口,但是任务可以被杀死,包括被别的任务杀死或自杀[2]。任务的概念与操作系统中的进程概念相同,一个任务是独立的执行进程,可以与其他的并发任务竞争CPU时间。 基于RTOS的单片机应用软件开发过程:首先是根据系统设计方案明确应用软件的功能,然后结合RTOS的并发特性(或准并发特性),对应用软件要实现的功能进行大小适当的划分,也就是把应用软件的功能按照一定的原则划分为若干个任务模块,并对各个任务间的通信和时延进行仔细的确认。 |
|
|
|
2 任务划分的原则
任务划分有3个原则,分别介绍如下。 2.1 原则1 原则1是将同一个外设的访问放在一个任务中。 对每个独立的硬件(例如串行通信端口)进行操作的驱动程序段放在一个任务中。也就是说,要想对某个设备资源进行操作,只有依靠执行相应的任务来实现。这样无论何时切换任务,都不会对任何独立的“外设”造成影响。 这样做能够避免嵌入式操作系统的特殊问题——资源冲突和重入问题,而且利于系统维护与升级。各个任务之间要实现通信,可以调用os_send_signal函数及全局变量来实现。 所谓“资源冲突”,就是任务A在访问某个资源时,恰好发生了任务切换——由任务A切换到任务B,任务B也访问这个资源且改变了它的状态,这样当再次执行任务A时,就可能发生冲突或带来不确定性。而所谓“重入”,是指假设任务A在运行某个函数,发生任务切换后,任务B也运行这个函数,这样就会破坏任务A执行这个函数时的现场,从而可能导致任务A执行函数时结果不正确。这种问题尤其容易出现在串行接口器件的操作中,例如串口,串行的A/D、D/A器件等。 2.2 原则2 原则2是要通过任务分割提高系统的实时性。 在嵌入式多任务实时系统中,任务是指一个程序分段。这个程序分段***作系统当作一个基本单元来调度。典型地,每个任务都是一个无限的循环。 RTOS本质上就是嵌入的实时内核,它负责管理各个任务,或者说是为每个任务分配CPU时间,并且负责任务之间的通信。实时内核可分为可剥夺型和不可剥夺型两类。因此,按照所使用内核的不同,嵌入式实时系统也可分为两类:使用不可剥夺型内核的嵌入式实时系统和使用可剥夺型内核的嵌入式实时系统。 2.2.1 长任务的定义 在RTOS中,长任务就是指整个任务的执行时间较长,超出了RTOS中其他某一个或某几个任务的实时要求容限,而对整个RTOS的实时性构成威胁的那些任务。需要注意的是,长任务与复杂任务不能混淆,复杂任务的执行时间不一定长,简单任务也可能会构成长任务。 2.2.2 长任务对RTOS的影响 当使用可剥夺型实时内核时,长任务由于执行的时间较长,因而更容易被高优先级的任务打断;一旦高优先级的任务进入了就绪状态,当前任务的CPU使用权就被剥夺了,或者说任务被挂起了,那个高优先级的任务立刻得到了CPU的控制权。这样会出现两个问题:一是长任务可能在一次执行的过程中被频繁打断,长时间得不到一次完整的执行;二是长任务被打断时,可能要保存大量的现场信息,其目的是为了保证在高优先级任务执行完返回后,长任务能得以继续执行。然而,这样做要占用一定的系统资源,同时保存现场本身也是要占用CPU时间的,因此,实时性也会下降。 当使用不可剥夺型实时内核时,长任务对RTOS的影响更为明显,因为在这种内核中,任务的响应时间取决于最长的任务执行时间。也就是说,由于长任务的存在,任务的响应时间要变长。其结果是CPU长时间停留在长任务中,其他任务得不到实时的响应,甚至根本得不到执行,系统的实时性势必要下降。 总之,无论是使用可剥夺型内核,还是使用不可剥夺型内核,长任务都会对RTOS构成严重的威胁。 2.2.3 长任务问题的解决方法 解决长任务问题最有效的途径是进行任务分割。所谓“任务分割”是指将影响系统实时性的长任务分割成若干个小任务。这样单个任务的执行时间变短,系统的任务响应时间变短,实时性得以提高。 (1) 对任务的分析与计算 当然,长任务的分割必须结合系统中所使用的内核,以及各任务对实时性的要求等情况,进行必要的分析与计算,才能保证分割的合理性和有效性,具体的步骤如下。 ① 分析系统共有多少个任务,这些任务对实时性的要求有多高,求出各个任务所要求的最低执行频率(f1,f2,…,fn)。 ② 计算目前各任务的实际执行时间(t1,t2,…,tn) ③ 确定系统中的长任务。如果max(t1,t2,…,tn)≤min(1/f1,1/f2,…,1/fn),则此系统中不存在长任务。如果max(t1,t2,…,tn)>min(1/f1,1/f2,…,1/fn),则存在长任务,而且执行时间为max(t1,t2,…,tn)的那个任务就是要找的长任务。 ④ 分析此长任务是否需要分割,分析一下是什么原因导致执行的时间过长,这个时间是否能够通过程序的优化来缩短?如果能,则不需要进行任务分割;否则,要对这个长任务进行分割。 |
|
|
|
只有小组成员才能发言,加入小组>>
818 浏览 0 评论
1162 浏览 1 评论
2537 浏览 5 评论
2872 浏览 9 评论
移植了freeRTOS到STMf103之后显示没有定义的原因?
2720 浏览 6 评论
keil5中manage run-time environment怎么是灰色,不可以操作吗?
1115浏览 3评论
198浏览 2评论
465浏览 2评论
382浏览 2评论
M0518 PWM的电压输出只有2V左右,没有3.3V是怎么回事?
463浏览 1评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-29 11:51 , Processed in 1.061036 second(s), Total 83, Slave 63 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号