10 syswatch 的时间参数设置
syswatch低功耗下模式下的表现形式
想请教一下syswatch组件运行后，当MCU分别进入睡眠模式 和 停止模式 以及standby模式后，syswatch组件分别有什么影响。也就是进入低功耗模式时syswatch的表现。
进入低功耗模式后，看门狗会不会停止计数
另外，还有几点不是很明白，文档中提到，当检测到有线程发生异常阻塞时，是指该线程阻塞MCU吗，不是线程进入阻塞态吧，感觉上应该理解为是一旦有线程一直抢占住CPU长达一定时间就判断该线程异常。这儿的发生异常阻塞还有别的什么情况异常阻塞吗。
另外，下面这三个参数，1-是指当线程一直抢占住CPU运行60s（一直被调度器调度进入运行态持续运行了60s）就判断它时异常了吗？2-这个超时时间是指再延迟个15s确定他为异常线程，也就是总共经过75s这个抢占住CPU的线程会被杀死或者重新载入。
综合来看，即使是用户的最高优先级线程，也不能一直抢占住CPU运行超过75s。也就是即使有其他低优先级线程运行时，高优先级线程也不能抢占低优先级线程运行超过75s？
那么就有个疑问，如果是一个最低优先级的线程，当其他高优先级都在等待条件阻塞时，这个低优先级执行了75s怎么办？它会被杀死吗？
对低功耗模式的行为不太清楚
感觉上应该理解为是一旦有线程一直抢占住CPU长达一定时间就判断该线程异常
是这样理解的，但这个阻塞的概念要明确，如某个线程调用while(1){}死循环执行代码，会一直阻塞该线程，导致优先级低于该线程的其他线程一直得不到运行；其他调用类似rt_sem_take实现“阻塞”的操作为主动让出CPU，内核的延时函数也会让出CPU，内核会转而调度其他就绪态的线程，不属于异常阻塞
IDLE为最低优先级线程，IDLE一直运行为正常情况，IDLE一直得不到运行才需要考虑是否发生异常阻塞
可以简单认为是个软件看门狗吧，在低优先级里面【喂狗】，如果低优先级线程IDLE 一直得不到执行，就咬狗。
建议在深睡眠、StandBy模式，冻结硬件看门狗，STM32的硬件看门狗，在 STOP、StandBy模式下默认不关闭，造成咬狗重启，这个需要修改STM32 的 option byte【选项字节】
软件看门狗，在 STOP、StandBy模式下，系统都停掉了，不会咬狗，tick 不改变。
对于低功耗模式下syswatch的表现不太清楚。
个人理解：这个组件作用是通过赋予最高优先级和获得看门狗定时器的操作权限（其它线程就不要用看门狗了，统一由syswatch接管），syswatch因为有最高权限，所以可以中断其它所有线程的能力；通过监视其它线程的属性（与时间有关的超时参数）当其违反了，就采取一些措施（暂停/杀死线程,软重启/硬重启）。个人认为，因为操作系统层面一个线程对其它线程的处理除了信号，完成量之外的手段较少（挂起和恢复系统不推荐，直接杀死可能没有考虑其它相关的资源等待），如果这块能完善，无论是syswatch还是自己设计一个监护线程都是大有裨益的！
撰写答案
相关问题
推荐文章
最新文章
有点明白了，就是任何一个线程不能一直被调度器调度霸占MCU运行，它要么让出给低优先线程运行一会儿，要么让出给IDLE线程运行一会儿，反正就是不能它一直被调度运行，即使比它高优先级的线程全部处在等待条件执行，这时它也必须出让给IDLE线程运行一会儿。
IDLE为最低优先级线程，IDLE一直运行为正常情况，IDLE一直得不到运行才需要考虑是否发生异常阻塞理论上讲，这儿的IDLE一直得不到运行也可能是正常的情况，比如比IDEL优先级高的两个线程来回切换运行，导致IDEL得不到执行，这时也属于正常运行。