想法是好的，但是，还需要继续完善和改进。个人觉得。

楼主很有想法。

谢谢分享.

采用这中方式，如果周期任务执行时间把握不好或者及时任务时间过长，则系统刷新时间会相应被拉长了。

有几点想和楼主探讨的：
1、因为任务调度是在最低优先级的定时器中断中执行的，优先级应该是作者文中提及的3，看过《时间触发》的都知道任务调度是通过一个for循环来查询哪个任务可以执行了，然后执行之，如果某个任务占用时间很长，或有很多任务，那么可想而知，这个for循环将相当耗时，这也意味着这个定时中断的处理时间将相当长，有悖于“中断处理程序不宜过长”的言论，当然，这个问题见仁见智，也没有谁规定中断处理程序不能太长，或太长有什么人命关天的影响……因为可以无视之……但是每个周期型任务的开头竟然是“开中断”！！！SCH_Start();函数就是使能全局中断用的，其它定时器的中断使能也应该是在相应的SCH_Init();函数中实现了，理论上在循环调度的任务中不应该再涉及“开中断”的操作，否则就是多余的了……如果这个操作不是多余的，就意味着任务中肯定还有其它地方有相应“关中断”的操作，如果真有“关中断”的操作，那么这个系统的“实时性”也就无从谈起了……

2、任务刷新在另一个定时器中断中实现，也就相当于《时间触发》一书的定时器的作用。按照作者的意思，它的优先级应该是2……

3、综上所述，系统中用了优先级最低的3和次低的2，那么优先级最高的1，作者文中没有提及，我估计如果按照作者的例子来说，那么这个优先级应该分配给串口接收的中断……