update 说明文档/CosyOS原理与应用.md.

Signed-off-by: 零中断延迟的RTOS <cosyos@139.com>

说明文档/CosyOS原理与应用.md

@@ -121,9 +121,9 @@ CosyOS的任务调度策略可最大程度的实现尽可能实时高效的任
 ### 八、任务栈模式
 
 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>
@@ -146,7 +146,8 @@ MSP模式虽然在任务切换时会保存并恢复现场，导致效率较低
 开发调试时，还是要配置够用的任务栈，保证测试阶段不会溢出（不会发生重分配）。<br>
 任务栈重分配次数多了会导致内存碎片，如果过分依赖的话，反而会导致内存更加不够用。<br>
 任务栈重分配机制，就是为了当万一哪一天任务栈溢出了呢？能够满血复活。<br>
-任务栈重分配机制的启用条件：<br>
+
+* **任务栈重分配机制的启用条件** <br>
 1、对于8051，当任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制。<br>
 2、对于80251，当任务栈模式为MSP模式、任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制。<br>
 
@@ -155,7 +156,7 @@ MSP模式虽然在任务切换时会保存并恢复现场，导致效率较低
 ![任务管理器](../images/taskmgr.png "任务管理器")<br>
 —————————— CosyOS-任务管理器 ——————————
 
-相关名词解释<br>
+* **相关名词解释** <br>
 **Name**：任务名称<br>
 **TID**：任务ID<br>
 **PRI**：任务优先级<br>
@@ -163,14 +164,13 @@ MSP模式虽然在任务切换时会保存并恢复现场，导致效率较低
 **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>
+* **RAM项说明** <br>
+示例1：32B/s64B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 静态创建 了64Bytes。<br>
+示例2：32B/m64B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 malloc 分配了64Bytes。<br>
+示例3：32B/r40B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 realloc 分配了40Bytes。<br>
 
 **每调度监控**：是每次任务调度时都会监控，并假定本次会切换任务、需要现场保护，计算当前任务需要多大的任务栈。这种假定在概率上必然早晚都会发生，但不一定是什么时候（也许是即将发生、也许是一万年以后、也许是时间的尽头），从而提前预判任务栈溢出的风险。<br>
-
-每调度包括定时调度与临时调度，对于定时调度来说，就是系统滴答中断触发的，所以，用户在开发测试阶段可适当定义一个较小的“系统滴答周期”，可提升“每调度监控”提前预判任务栈溢出风险的机率。<br>
+任务调度包括定时调度与临时调度，对于定时调度来说，就是系统滴答中断触发的，所以，用户在开发测试阶段可适当定义一个较小的 系统滴答周期，可提升 每调度监控 提前预判任务栈溢出风险的机率。<br>
 
 1、当任务栈重分配发生时，就需要重新调整任务栈的size了。<br>
 如：32B/r40B，此时就需要重新调整任务栈的大小为至少32个字节。<br>
@@ -186,28 +186,22 @@ MSP模式虽然在任务切换时会保存并恢复现场，导致效率较低
 3、对于251的PSP模式，由于中断入栈也入任务栈，所以需要用户自己根据中断的使用情况来计算一个中断嵌套入栈的最大size（不必包括最低优先级的中断入栈），累加到“前面的字节数”中，看是否会大于 “后面的字节数”，再行调整。<br>
 
 * **任务栈之重定义** <br>
-1、在开发测试阶段，用户应尽量设法模拟各种情况的发生，最好是频繁发生，包括中断的发生。只要你的产品支持的功能、情况，都要设法模拟到。
+1、在开发测试阶段，用户应尽量设法模拟各种情况的发生，最好是频繁发生，包括中断的发生。只要你的产品支持的功能、情况，都要设法模拟到。<br>
 2、通过足够时间的测试，统计出各任务在任务管理器当中的“RAM”项中，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用，
-而后在此值的基础上，再累加一个补偿增量，再重新定义任务栈size。
+而后在此值的基础上，再累加一个补偿增量，再重新定义任务栈size。<br>
 
-示例：经过长期的测试以后，某任务的任务栈情况如下：
-56B/m64B，
-此时，可重新定义任务栈的size为：56 + X；X为补偿增量。
-原因是无论 每调度监控 如何的假定入栈，也可能会存在着更大的任务栈需求，只是未能测试到。所以必须增加一定的补偿。
-而这个补偿量的大小，每个任务都可根据剩余内存的大小而灵活配置，最好能尽量大一些，尤其是对于没有任务栈重分配机制的情况来说。
+示例：经过长期的测试以后，某任务的任务栈为：56B/m64B，此时，可重新定义任务栈的size为：56 + X；X为补偿增量。<br>
+原因是无论 每调度监控 如何的假定入栈，也可能会存在着更大的任务栈需求，只是未能测试到。所以必须增加一定的补偿。<br>
+而这个补偿量的大小，每个任务都可根据剩余内存的大小而灵活配置，最好能尽量大一些，尤其是对于没有任务栈重分配机制的情况来说。<br>
+没有任务栈重分配机制的情况：<br>
+1、任务创建模式为静态创建。<br>
+2、251的PSP模式。<br>
+3、ARM。<br>
+这个补偿增量对于51来说可描述为2的整数倍：2 x N，N为每调度监控未能监测到的N次的函数嵌套调用。<br>
+对于251、ARM来说则无法描述。<br>
 
-没有任务栈重分配机制的情况：
-1、任务创建模式为静态创建。
-2、251的PSP模式。
-3、ARM。
-
-
-这个补偿增量对于51来说可描述为2的整数倍：2 x N，N为每调度监控未能监测到的N次的函数嵌套调用。
-对于251、ARM来说则无法描述。
-
-
-再有，CosyOS启用“每调度监控”的充分必要条件是：启用任务管理器，即系统配置中，“DEBUG接口设置”必须打勾。
-“每调度监控”属于“任务栈监控”，是CosyOS任务管理器的标配选项。
+再有，CosyOS启用“每调度监控”的充分必要条件是：启用任务管理器，即系统配置中，“DEBUG接口设置”必须打勾。<br>
+“每调度监控”属于“任务栈监控”，是CosyOS任务管理器的标配选项。<br>
 
 **PSVFIFO**：中断挂起服务缓存（PendSV_FIFO）的深度，如果您已开启PendSV_FIFO监控，会显示此项，历史最大值/设置值。<br>