使用一个实际项目的案例来引出使用RTOS的必要性，然后总结出μCOS的核心内容以及理解这些内容需要的前提知识，做出专栏的详细章节目录。
WHY RTOS ???
真正理解使用RTOS的好处还得是经历过实际的Project，说一个我工作以后接触到的第一个Project吧。该项目是一个嵌入式控制器，需要做的工作有：读取A/D数据、根据读取到的A/D数据计算结果、和上位机通讯、显示、用户按键。详细一点的技术要求，对实时性要求比较高的一个任务是读取A/D数据，需要精确的10ms 级别interval的读取。这样的系统从直觉上来看，有很多任务要去做，而且任务之间从重要性、紧迫性方面比较的话还不能一视同仁。如果不使用RTOS的话，经典的做法是使用 前后台系统 设计方法，后台系统作为一个大的Loop检测各种Event，前台是各种外部事件的中断，比如读取到A/D数据、检测到外部按键等等。这种系统要想实现特定事件的实时响应和不同事件的紧急度管理还是需要很多的额外工作需要做。其实说的直白点，一个小型嵌入式系统的核心控制器一般都是一个综合了CPU和外设的片上系统。这个核心控制器一般CPU是单core的，只能提供一个执行流，再加上Interrupt，可以说整体就有了两个可管理的执行流，且中断的执行流优先级要大于CPU提供的执行流。这就是前后台系统设计的自然性，硬件提供了两个执行流，我就利用这两个执行流设计了前后台系统。前台是各种中断事件，后台利用CPU提供的计算资源做逻辑处理。
如果利用软件管理手段能把CPU上的执行流管理起来，势必能加速整体的吞吐量和实时响应能力。因为CPU上的执行流从宏观上来看利用CPU进行运算的时间是间隔的，这个也很好理解，因为CPU运算能力是很强的，但是一个任务一般会涉及到等待外部事件，外部事件发生后才去做逻辑处理或者数值运算。在等待外部相对于CPU运算来说慢的多的多的事件时，如果能把CPU让给其他任务来用，那CPU的整体利用率就很高了。真是不错的想法。一个嵌入式产品不可能不与外部交互，毕竟科技产品是为人服务的。
使用RTOS后，设计上述Project就可以比较轻松地管理各个任务，还能很容易根据任务的紧迫性、实时性来区分对待。这样一来，对降低嵌入式软件的设计复杂度很有帮助，后期调试、维护也比较容易。这样也比较自然，本来不同的任务被划分出来也是根据这个任务做的工作具有高内聚的特点，和其他任务交互具有低耦合的特点，把一个任务作为一个管理单元确实比较自然。使用RTOS后，每一个任务都认为自己独占一整个CPU，实际上只是各个任务分时复用CPU资源。各个任务既然划分出来了，必然涉及到各个任务之间通讯的问题，RTOS也提供了各种IPC通讯的方法。这样设计出来的嵌入式软件确实符合“高内聚、低耦合”的设计原则。
RTOS核心就是管理CPU，管理CPU的意思就是能抽象出多个执行流(Task/Thread)。RTOS提供的其他服务都和外部IO有关系，你像FS(File System)、Device Manegement等等。
RTOS提供了一个对程序员来说更好用的抽象的计算机，这个抽象的计算机屏蔽了底层硬件细节并提供了很多基础服务。这就是使用RTOS的原因，相信你使用过RTOS设计产品后，你就不会再使用前后台系统设计产品了。
需要理解的几个基本概念
何为操作系统？何为实时操作系统？
RTOS 中硬件平台无关性代码和硬件平台有关性代码
既然都有了高级语言，为什么汇编语言还存在？RTOS源代码中汇编语言的作用主要是什么？
程序员编写的程序从源代码到实际运行都经历了什么？(源代码—目标映像—实际运行)
重新认识下栈[Stack]。(栈和C语言的关系、栈和Thread运行环境的关系)
目录
感谢μCOS的作者Jean J.Labrosse
硬件运行环境和μCOS版本说明
基于Docker环境开发、调试嵌入式软件
依赖的知识点
操作系统&&实时操作系统
硬件平台有关&&平台无关
汇编语言存在的意义
程序的生老病死
(源代码—目标映像—实际运行)
重新认识下栈[Stack]
(栈和C语言的关系、栈和Thread运行环境的关系)