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

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

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

@@ -364,36 +364,6 @@ CosyOS则分为两种情况：<br>
 32B/s64B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 **静态创建** 了64Bytes。<br>
 32B/m64B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 **malloc** 分配了64Bytes。<br>
 32B/r40B，系统采用每调度监控计算出的在概率上必然存在的最大任务栈占用为32Bytes，任务栈已 **realloc** 分配了40Bytes。<br>
- **每调度监控：** <br>
-每次任务调度时都会监控，并假定本次会切换任务、需要现场保护，计算当前任务需要多大的任务栈。<br>
-这种假定在概率上必然早晚都会发生，但不一定是什么时候（也许是即将发生、也许是一万年以后、也许是时间的尽头），从而提前预判任务栈溢出的风险。<br>
- **每调度监控应用技巧：** <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、在开发测试阶段，用户应尽量设法模拟各种情况的发生，最好是频繁发生，包括中断的发生。只要你的产品支持的功能、情况，都要设法模拟到。<br>
-2、通过足够时间的测试，统计出各任务在任务管理器当中的“RAM”项中，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用，而后在此值的基础上，再累加一个补偿增量，再重新定义任务栈size。<br>
-示例：经过长期的测试以后，某任务的任务栈为：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>
- **每调度监控的启用条件：** <br>
-CosyOS启用“每调度监控”的充分必要条件是启用任务管理器，即系统配置中，“DEBUG接口设置”必须打勾。<br>
 
 * **PSVFIFO**：中断挂起服务缓存（PendSV_FIFO）的深度，如果您已开启PendSV_FIFO监控，会显示此项，历史最大值/设置值。<br>
 
@@ -466,6 +436,43 @@ MSP模式虽然在任务切换时会保存并恢复现场，导致效率较低
 1、对于8051，当任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制。<br>
 2、对于80251，当任务栈模式为MSP模式、任务创建模式非静态创建时，CosyOS将自动启用任务栈重分配机制。<br>
 
+### 任务栈监控
+CosyOS的任务栈监控包括每调度监控、入栈监控、线程入口监控等。
+ **每调度监控：** <br>
+每次任务调度时都会监控，并假定本次会切换任务、需要现场保护，计算当前任务需要多大的任务栈。<br>
+这种假定在概率上必然早晚都会发生，但不一定是什么时候（也许是即将发生、也许是一万年以后、也许是时间的尽头），从而提前预判任务栈溢出的风险。<br>
+ **每调度监控应用技巧：** <br>
+任务调度包括定时调度与临时调度，对于定时调度来说，就是系统滴答中断触发的，所以，用户在开发测试阶段可适当定义一个较小的 **系统滴答周期**，可提升“每调度监控”提前预判任务栈溢出风险的机率。<br>
+ **每调度监控的启用条件：** <br>
+CosyOS启用“每调度监控”的充分必要条件是启用任务管理器，即系统配置中，“DEBUG接口设置”必须打勾。<br>
+
+### 任务栈定义
+ **任务栈初定义：** <br>
+1、对于51及251的MSP模式，当任务创建模式非静态创建时，任务栈的初始定义可以小（因为有重分配机制），而后根据监控及报警情况再增大。<br>
+2、对于251的PSP模式及Arm的MSP+PSP模式，任务栈的初始定义一定要够大，否则可能会运行不起来或死机，而后再根据测试情况重新调整任务栈。<br>
+3、对于251的PSP模式，由于中断入栈也入任务栈，所以需要用户自己根据中断的使用情况来计算一个中断嵌套入栈的最大size（不必包括最低优先级的中断入栈），累加到“前面的字节数”中，看是否会大于 “后面的字节数”，再行调整。<br>
+
+ **任务栈调整：** <br>
+1、当任务栈重分配发生时，就需要重新调整任务栈的size了。<br>
+如：32B/r40B，此时就需要重新调整任务栈的大小为至少32个字节。<br>
+当这种情况发生时，还会有相应的报警提示用户，rts：任务栈重分配发生，虽然成功了，但仍要提醒用户任务栈定义小了。<br>
+2、当 “前面的字节数” 大于 “后面的字节数” 时，就需要重新调整任务栈的size了。<br>
+如：56B/m32B，此时就需要重新调整任务栈的大小为至少56个字节。<br>
+当这种情况发生时，还会有相应的报警提示用户，ots：在概率上、在未来必然会发生的任务栈溢出（虽然现在可能并未发生）。<br>
+
+ **任务栈重定义（任务栈补偿）：** <br>
+1、在开发测试阶段，用户应尽量设法模拟各种情况的发生，最好是频繁发生，包括中断的发生。只要你的产品支持的功能、情况，都要设法模拟到。<br>
+2、通过足够时间的测试，统计出各任务在任务管理器当中的“RAM”项中，系统采用每调度监控（假定入栈）计算出的在概率上必然存在的最大任务栈占用，而后在此值的基础上，再累加一个补偿增量，再重新定义任务栈size。<br>
+示例：经过长期的测试以后，某任务的任务栈为：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>
+
 ## 附  录、调用服务注意事项
 
 ### CosyOS-II 在临界区中或关闭总中断时调用服务注意事项