mirror of
https://gitee.com/cosyos/cosyos.git
synced 2026-02-05 19:39:42 +08:00
@@ -118,13 +118,12 @@ CosyOS的任务调度时机分为 **定时调度** 与 **临时调度** 。<br>
|
||||
|
||||
CosyOS的任务调度策略可最大程度的实现尽可能实时高效的任务切换,使CosyOS的实时性更为优异。<br>
|
||||
|
||||
### 八、任务栈
|
||||
### 八、任务栈模式
|
||||
|
||||
* **任务栈模式** <br>
|
||||
CosyOS把任务栈的处理方式称之为任务栈模式,共包括三种类型,MSP模式、PSP模式、MSP+PSP模式。<br>
|
||||
**1.MSP模式** 任务切换时,先拷贝主栈内容至当前任务栈(保存现场);再拷贝新任务栈内容至主栈(恢复现场)。<br>
|
||||
**2.PSP模式** 每个任务的任务栈都是主栈,哪个任务运行时,哪个任务的任务栈(当前任务栈)就是当前主栈。<br>
|
||||
**3.MSP+PSP模式** 中断时为Handler模式,入栈入的是主栈;任务时为Thread模式,入栈入的是当前任务栈。<br>
|
||||
* **1.MSP模式** 任务切换时,先拷贝主栈内容至当前任务栈(保存现场);再拷贝新任务栈内容至主栈(恢复现场)。<br>
|
||||
* **2.PSP模式** 每个任务的任务栈都是主栈,哪个任务运行时,哪个任务的任务栈(当前任务栈)就是当前主栈。<br>
|
||||
* **3.MSP+PSP模式** 中断时为Handler模式,入栈入的是主栈;任务时为Thread模式,入栈入的是当前任务栈。<br>
|
||||
对于51来说,CosyOS采用了搬栈这一传统方案,也就是MSP模式。<br>
|
||||
对于Arm来说,CosyOS所采用的方法当然是主流的双栈指针了,也就是MSP+PSP模式。<br>
|
||||
对于251来说,CosyOS支持MSP模式、PSP模式,这两种栈模式供用户选择。<br>
|
||||
@@ -151,11 +150,98 @@ MSP模式虽然在任务切换时会保存并恢复现场,导致效率较低
|
||||
1、对于8051,当任务创建模式非静态创建时,CosyOS将自动启用任务栈重分配机制。<br>
|
||||
2、对于80251,当任务栈模式为MSP模式、任务创建模式非静态创建时,CosyOS将自动启用任务栈重分配机制。<br>
|
||||
|
||||
* **任务栈之初始定义** <br>
|
||||
### 九、任务管理器
|
||||
在您配置好相关硬件和软件后,任务管理器便可以使用了。您可使用某一款串口调试助手,作为任务管理器的输出窗口。
|
||||
<br>
|
||||
—————————— CosyOS-任务管理器 ——————————
|
||||
|
||||
相关名词解释<br>
|
||||
**Name**:任务名称<br>
|
||||
**TID**:任务ID<br>
|
||||
**PRI**:任务优先级<br>
|
||||
**STA**:任务状态<br>
|
||||
**CPU**:CPU使用率<br>
|
||||
**RAM**:任务栈大小(字节数)<br>
|
||||
|
||||
其中,RAM项需着重说明一下。<br>
|
||||
示例1:32B/s64B,系统采用每调度监控(假定入栈)计算出的在概率上必然存在的最大任务栈占用为32Bytes,任务栈已“静态创建”了64Bytes。<br>
|
||||
示例2:32B/m64B,系统采用每调度监控(假定入栈)计算出的在概率上必然存在的最大任务栈占用为32Bytes,任务栈已“malloc”分配了64Bytes。<br>
|
||||
示例3:32B/r40B,系统采用每调度监控(假定入栈)计算出的在概率上必然存在的最大任务栈占用为32Bytes,任务栈已“realloc”分配了40Bytes。<br>
|
||||
|
||||
**每调度监控**:是每次任务调度时都会监控,并假定本次会切换任务、需要现场保护,计算当前任务需要多大的任务栈。这种假定在概率上必然早晚都会发生,但不一定是什么时候(也许是即将发生、也许是一万年以后、也许是时间的尽头),从而提前预判任务栈溢出的风险。<br>
|
||||
|
||||
每调度包括定时调度与临时调度,对于定时调度来说,就是系统滴答中断触发的,所以,用户在开发测试阶段可适当定义一个较小的“系统滴答周期”,可提升“每调度监控”提前预判任务栈溢出风险的机率。<br>
|
||||
|
||||
1、当任务栈重分配发生时,就需要重新调整任务栈的size了。<br>
|
||||
如:32B/r40B,此时就需要重新调整任务栈的大小为至少32个字节。<br>
|
||||
当这种情况发生时,还会有相应的报警提示用户,rts:任务栈重分配发生,虽然成功了,但仍要提醒用户任务栈定义小了。<br>
|
||||
|
||||
2、当 “前面的字节数” 大于 “后面的字节数” 时,就需要重新调整任务栈的size了。<br>
|
||||
如:56B/m32B,此时就需要重新调整任务栈的大小为至少56个字节。<br>
|
||||
当这种情况发生时,还会有相应的报警提示用户,ots:在概率上、在未来必然会发生的任务栈溢出(虽然现在可能并未发生)。<br>
|
||||
|
||||
* **任务栈之初定义** <br>
|
||||
1、对于51及251的MSP模式,当任务创建模式非静态创建时,任务栈的初始定义可以小(因为有重分配机制),而后根据监控及报警情况再增大。<br>
|
||||
2、对于251的PSP模式及Arm的MSP+PSP模式,任务栈的初始定义一定要够大,否则可能会运行不起来或死机,而后再根据测试情况重新调整任务栈。<br>
|
||||
3、对于251的PSP模式,由于中断入栈也入任务栈,所以需要用户自己根据中断的使用情况来计算一个中断嵌套入栈的最大size(不必包括最低优先级的中断入栈),累加到“前面的字节数”中,看是否会大于 “后面的字节数”,再行调整。<br>
|
||||
|
||||
### 九、任务管理器
|
||||
* **任务栈之重定义** <br>
|
||||
1、在开发测试阶段,用户应尽量设法模拟各种情况的发生,最好是频繁发生,包括中断的发生。只要你的产品支持的功能、情况,都要设法模拟到。
|
||||
2、通过足够时间的测试,统计出各任务在任务管理器当中的“RAM”项中,系统采用每调度监控(假定入栈)计算出的在概率上必然存在的最大任务栈占用,
|
||||
而后在此值的基础上,再累加一个补偿增量,再重新定义任务栈size。
|
||||
|
||||
示例:经过长期的测试以后,某任务的任务栈情况如下:
|
||||
56B/m64B,
|
||||
此时,可重新定义任务栈的size为:56 + X;X为补偿增量。
|
||||
原因是无论 每调度监控 如何的假定入栈,也可能会存在着更大的任务栈需求,只是未能测试到。所以必须增加一定的补偿。
|
||||
而这个补偿量的大小,每个任务都可根据剩余内存的大小而灵活配置,最好能尽量大一些,尤其是对于没有任务栈重分配机制的情况来说。
|
||||
|
||||
没有任务栈重分配机制的情况:
|
||||
1、任务创建模式为静态创建。
|
||||
2、251的PSP模式。
|
||||
3、ARM。
|
||||
|
||||
|
||||
这个补偿增量对于51来说可描述为2的整数倍:2 x N,N为每调度监控未能监测到的N次的函数嵌套调用。
|
||||
对于251、ARM来说则无法描述。
|
||||
|
||||
|
||||
再有,CosyOS启用“每调度监控”的充分必要条件是:启用任务管理器,即系统配置中,“DEBUG接口设置”必须打勾。
|
||||
“每调度监控”属于“任务栈监控”,是CosyOS任务管理器的标配选项。
|
||||
|
||||
**PSVFIFO**:中断挂起服务缓存(PendSV_FIFO)的深度,如果您已开启PendSV_FIFO监控,会显示此项,历史最大值/设置值。<br>
|
||||
|
||||
**Task-PC**:任务PC监控,如果您已开启任务PC监控,会显示此项。<br>
|
||||
当任务管理器被调度运行时,上一个被切换的任务入栈的PC值。当有任务出现代码运行卡死或死循环时,此功能可用来帮助用户锁定具体位置,以便查找BUG。注意,PC值为下一条汇编指令的地址。<br>
|
||||
某任务出现代码运行卡死或死循环的表现:任务始终为就绪状态,且占用较高的CPU使用率,比它优先级低的任务一直都没有机会运行。
|
||||
|
||||
**SysTick**:系统滴答时间统计,如果您已开启系统滴答时间统计,会显示此项。<br>
|
||||
注意:系统滴答时间是SysTick_Handler运行的平均时间,并非是任务切换时间。
|
||||
|
||||
**Alarm**:报警信息,如果有报警,会显示此项。<br>
|
||||
omq:消息队列溢出。<br>
|
||||
otq:任务队列溢出;<br>
|
||||
osr:安全运行时超时。<br>
|
||||
otp:任务优先级超出范围。<br>
|
||||
rts:任务栈重分配发生,虽然成功了,但仍要提醒用户任务栈定义小了。<br>
|
||||
任务栈重分配机制被设计用来在正式的产品中抵御任务栈溢出的风险,用户在开发测试阶段应避免这种情况的发生。<br>
|
||||
ots:在概率上、在未来必然会发生的任务栈溢出(虽然现在可能并未发生)。<br>
|
||||
|
||||
**Fault**:故障信息,如果有故障,会显示此项。<br>
|
||||
mmn:消息节点内存分配失败;<br>
|
||||
mtn:任务节点内存分配失败;<br>
|
||||
mts:任务栈内存分配失败;<br>
|
||||
rts:任务栈内存重分配失败;<br>
|
||||
ots:任务栈溢出;<br>
|
||||
fst:启动任务失败;<br>
|
||||
erm:中断中接收消息错误(中断中不可接收来自动态消息队列的消息)。<br>
|
||||
opd:中断挂起服务缓存溢出。<br>
|
||||
|
||||
任务管理器现支持如下命令:<br>
|
||||
1. taskmgr,启动任务管理器。<br>
|
||||
2. exit,退出任务管理器。<br>
|
||||
3. taskmgr /s=...,任务管理器更新速度,取值范围:[50~5000]ms。<br>
|
||||
注意:命令仅支持小写字母,结尾必须加回车换行(\r\n)。
|
||||
|
||||
## 第二章、中断篇
|
||||
|
||||
|
||||
Reference in New Issue
Block a user