国内用uC/OS-II的人很多，最近uC/OS-III也开源了，实在是广大RTOS爱好者之福。我也曾经用uC/OS-II开发过一些东西。当时是用uC/OS-II在windows平台上的模拟。跑了一个“Hello World!!!”;大致感觉这种虚拟方式还不错，能结合Visual C++这样强悍的工具，或者Linux平台下的gdb这样的工具，对uC/OS-II的代码做单步跟踪;深入的了解RTOS内核的执行过程。我觉得非常的好。然而在我深入了解了RTOS内核，了解了uC/OS-II在windows上的移植后，发现这种虚拟方式简直是害人不浅……
那问题究竟在哪呢?首先 RTOS 区别于Windows、Linux、uCLinux这种系统，主要是其调度算法不同。使用的是Rate Monotonic(RM 单调速率)调度算法。这种算法的最大特点是基于优先级别的时间分配，如果有一个高优先级别任务不放弃对CPU的占有，那么连操作系统的内核也得不到时间执行。Windows、Linux下是绝对不会出现这种情况的。即使一个任务占了CPU 100%，用户的操作只是反应慢了，还没到什么都动不了的程度。
那uC/OS-II在Windows平台上的移植，是怎么做得呢?uC/OS-II的任务采用Windows的线程实现，使用OSTaskCreate即是创建一个Windows的线程，入口是用户指定的任务。那们这里就有一个问题，uC/OS-II更核心的OS_ENTER_CRITICAL和OS_EXIT_CRITICAL是怎么实现的?利用Windows里的二值信号量实现的。这个二值信号量只是用于进程内部的，但可以用于同一个进程内部的多个线程。那么上下文切换没有什么实际性的内容，只是调用Windows的API将高优先级的任务恢复执行(对Windows来讲是一个线程)，而低优先级的任务挂起。上下文内容Windows会为RTOS保存。 |
