uC/OS-II是最早进入国内的一款开源RTOS，因为代码开源，又有配套的书籍，加上不大的代码量，在嵌入式群体中最为流行。在写“实用单片机系统”第一版之后，就接触了uC/OS-II，虽然大致的明白其工作原理，但一直似懂非懂，尤其有太多的宏定义，严重的干扰了源码的阅读，加上RTOS带来太多的概念，而这些概念都没有实际用过，不知道如何应用，并且听说有很多陷阱，所以心里有些空，把握不住风险，一直都回避RTOS。高频机开发的后期，菜单界面编程的复杂性严重的干扰了业务逻辑，逼迫我设计msOS的时候，考虑把业务逻辑与菜单界面分离开，这必须要引入RTOS，而uC/OS-II因为广为人知又相对简单一些，所以选择了uC/OS-II。

这一次正式选用uC/OS-II，必须要深入理解透彻每一个细节，否则因为自己对uC/OS-II的理解不到位，尤其是任务之间的通讯等细节问题引起的缺陷可能让自己的项目失败，这是不可接受的，所以参考书籍仔细的阅读源码，然而一接触这个源码，就让我犯晕，uC/OS-II为了实现可配置、可裁减，运用了大量的宏定义，考虑到各种情况，这严重的干扰了我的阅读，同时也有很多网友向我反应类似的问题，因为要了解uC/OS-II的核心原理，却经常被很多没用的源码干扰，他们迫切需要一份简单、清晰的源码，于是我决定先弄出一份可以清晰阅读的源码来。

第一步，去掉了绝大部分跟内核无关的事件管理功能，比如信号量、互斥型信号量、事件标志组、消息邮箱、内存管理这几个功能，只保留了msOS今后需要用到的时间管理、消息队列功能，这样一来，几乎就剩下内核部分源码，阅读大大简化了，系统基本上没有什么宏定义了，下图为uC/OS-II的头文件，非常简单，只需要定义三个宏定义：任务数、事件数和消息队列数，对于msOS来说，默认就是2、1、1，模式化了，不需要改变。

第二步，进一步去掉用不上的功能函数，比如时间管理中只保留OSTimeDly函数，消息队列中只保留创建队列、发送消息、等待消息三个必须要用的函数。任务管理中只保留了普通的创建任务函数，其它的删除任务，挂起任务等都删除了，因为msOS中不可能用到删除任务，挂起任务这些函数，放着除了干扰我之外，没有别的作用。这样一来，基本上就没有多少宏定义了，代码较容易看懂了，下图为前两步精简后的uC/OS-II接口函数。

第三步，因为能够看懂代码，就越觉得msOS不需要uC/OS-II这么多复杂的功能，比如msOS一般来说只需要两个任务即可，uC/OS-II却支持64个任务，因为支持64个任务，需要一个8*8bit的就绪表，为了实现快速查找最高优先级任务，需要一个算法和一个256字节的查找表，虽然这些不是很复杂，但却把很多人搞的稀里糊涂的，比较绕，严重的干扰了内核的阅读理解，所以要降低任务，只需要支持8个即可，对于msOS来说，8个都已经太多了，完全满足了，而实际的项目，一般都是几个任务即可，不建议大家开太多的任务，这样严重影响效率，并且各个任务之间通讯，访问资源等都容易引起很多冲突，理解不准确会导致一系列问题。

下图为msOS双任务查找表，数组中只有4个数据。实际上因为msOS只有两个任务，MenuTask是永恒最低任务存在，只要LogicTask激活，就马上执行LogicTask，处理完后再退到MenuTask，所以只需要识别LogicTask即可，根本不需要算法中的查找表，只是为了保留与uC/OS-II统一，预留扩展8个任务，所以还保留了任务查找表风格。

第四步，因为只有8个任务，而uC/OS-II默认有两个内部任务：统计任务与空闲任务，所以需要去掉这两个任务，msOS中必须要有业务逻辑与菜单界面两个任务，优先级最低的任务是菜单界面，这样还有6个任务可以供额外使用，6个已经足够了，非特别情况下，不建议用。

第五步，uC/OS-II的任务块和事件块是采用链表结构的，可以动态增删，但这一点对于绝大部分项目来说，没有意义，尤其是对msOS来说，根本就不需要动态的，于是把链表结构改成数组结构，这样非常容易看懂，也节省资源。

第六步，按C#语言风格标准化，跟msOS统一编程风格。

通过以上六步操作操作之后，uC/OS-II非常简单明了，只有os.c、os.h和os_a.asm三个文件，os.c中只有寥寥15个函数，os_a.asm中只有4个汇编函数。考虑到扩展性，还是保留了uC/OS-II的一些影子，其实若再精简下去，可能就只剩下一个内核切换，msOS只需要两个任务即可，完全可以精简到跟uC/OS-II无关了。