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

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

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

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