|
|
设计操作系统，有一个要求，就是不管操作系统内部怎么实现，怎么调整，都不能影响应用程序的运行结果。
许多操作系统，延时函数所用的时间单位，都是tick间隔，笔者亲见过的一个系统，使用的是VxWorks，其taskDelay函数，就是用tick间隔为单位的。当年把tick间隔设置为1/60秒，而现在，由于cpu速度提高，产品要求也提高了，想1/60秒的tick间隔，不能满足要求了。因此，想提高新产品的tick间隔到1ms，但是，老产品上有数十万行代码需要移植到新产品上，而这些代码，跟tick间隔密切相关，花了很多时间和精力去修改代码和测试代码。在移植时，长了记性了，给taskDelay及其他所有需要OS定时的函数，写了个外壳，把时间单位改为毫秒。
这也是一个可移植性的问题，操作系统的tick间隔，可以看做是软件的运行环境的一个参数。它使得应用程序不能tick间隔改变了的运行环境中正确地运行。而且，这是操作系统本身的设计造成的。
遗憾的是，大多数RTOS提供的跟时间相关的函数，都是tick间隔。从面向对象的角度，这是严重错误的，tick间隔是OS运行的内部参数，而且是非常核心的内部参数，国之利器，岂能轻易示人？因此，djyos所有与事件相关的函数，单位都是微秒，例如：
u32 djy_event_delay(u32 u32l_uS);
这个函数让事件阻塞，延时u32l_uS后恢复运行。
bool_t semp_pend(struct semaphore_LCB *semp,u32 timeout);
这个函数，请求一个信号量，请求不到则阻塞，最长阻塞时间是timeout，单位也是微秒。
这样，无论OS的tick间隔是多少，这些函数总是能正确地运行，运行结果最多只有微小的差异。这种微小差异，是tick间隔四舍五入造成的。
|
|
发表于 2012-8-11 16:30:25
楼主
