EEPW论坛

1。为什么每秒的tick越多，系统负担越重？
答：因为T0中断占用的时间就多了，用户任务的时间就少了。系统的时间资源全被用来做任务调度了，所以负担为加
重。
另外，有些时候每秒的tick数应当取一个折中的值：比任务的最短时间长一些（使得短时间任务可以一次执行完毕）
，按照工程经验，取3～5倍的最短任务时间即可。
 


2。ucos环境下中断的编写？与普通的前后台有何差别？
其实可以将ucos的内核（就是任务调度）和所有的用户任务都看成一个大的T0中断服务程序，其他的中断服务与之是
并行的。这样中断程序(ISR)的编写就简单了。可以这样理解:ucos走自己的阳关道，ISR走自己的独木桥，二者可以
通过全局变量或者ucos的API来通信。
举个例子，用户需要AD转换中断（姑且称之为AD_isr），其实完全可以按照常规的编写方法来处理。程序的具体流程也和前后台差不多——可以专门建立一个任务等待AD_isr的数据。
当然，这涉及到中断优先级的问题。一般建议将T0的优先级设定得高一些。
另外，ucos教材不建议这样做——其实这样做不一定不好，权衡一下任务调度的复杂度与直接编写中断服务的复杂度，说不定直接编写中断服务性能还优越一些。
 


3。为什么ucos没有全部用C编写？
ucos号称是最清晰的源程序。可见其结构是比较好的。问题是里面程序不全是由C写成的。
ucos中有三个os_cpu_xx的程序，为什么要用汇编编写呢？书上说因为C编译器不支持直接操作CPU的寄存器。
这样的话，如果编译器能够操作CPU的寄存器的话，所有的程序都可以用C语言编写了。
实际上在KEIL环境下，就可以将所有的程序用C来改写了。
是不是呢？望大虾指点迷津。
 
4。为什么选用ucos？
一般而言对于简单任务的程序用ucos反而会得补偿失——除非你对ucos理解的比较深入得心应手了。
有资料上说硬件成本会增加一些，其实未必——选择合适的带有XRAM的处理器，运行一个ucos根本没有任何问题。
 
 
5。ucos中内部看门狗如何复位？
在任务中复位其实是不科学的--其效果与在中断中复位看门狗是一样的。
不知各位大虾有何高级的办法？