UIP-Kernel RTOS 内核解析（一）（原创）

uipkernel

        前言（原创，转载或引用请注明出处）       作者：王保进（uipkernel）
      
      （1）分析RTOS源代码时，可以采用“动静结合”的方法。即，利用Sourceinsight、Understand或者ultraedit，静态分析代码执行线索；同时还可以利用硬件开发板（或者设备电路板）、仿真器、集成开发环境，动态调试代码的运行，从而更直观地观察、理解RTOS的执行线索。因为系统软件在运行过程中，除了因函数调用构成的执行路径外，还包括异步发生的中断而引起的中断处理程序执行路径（这里所说的执行路径都是相对于CPU而言的，因为CPU要在这两种执行路径之间来回切换）。中断处理程序构成的执行路径往往在静态分析时容易被忽略，或者不易被理解。特别是像RTOS这样的系统软件，调度内核要处处考虑中断造成的影响，而且中断也是引起现场切换的重要时机（另一时机就是在应用软件中主动调用RTSO的API引起的）。因此，动态运行是分析RTOS的重要方法。
       我们知道：熟能生巧；卖油翁也说过："无他，但手熟尔"。因此，当大家分析过大量系统软件、协议栈软件之后，就能逐渐将自己的大脑当成CPU，可以“动态”地在脑海里“运行”程序，且能全面考虑到中断在各种时机下触发时对系统的影响，以及系统软件处理的是否合理。这是系统软件开发人员追求的目标，建议大家朝着这个目标努力。当大家训练到一定程度后，可以达到如下境界：经过严格设计、严密思考后写出的程序，基本上不用调试就可以稳定、正常运行了。而且，随着你的经验值的递增，程序的复杂度也可以越来越大。当然，按照软件工程的的要求，我们写出的软件还是要经过完备测试的。

     （2）UIP-Kernel当前发布的版本采用了静态构建应用程序的方法，非常适合物联网等资源有限的深嵌入式应用，以及对可靠性、安全性要求很高的工控、汽车电子、航电等领域。未来发布的版本将同时支持动态构建方式，用户可根据需要选择使用。未来还将持续发布一系列的版本。

     （3）设计UIP-Kernel的一个重要理念是：以极简的内核为基础，支持上层构建更为复杂的API类型，既可以是私有API也可以是不同RTOS标准的API。因此，没有定义过多的任务状态，将等待某一“资源就绪”、“事件到达”、“消息到达”、“延迟时间到”等，以及主动放弃CPU的使用权（挂起）都定义为阻塞状态。其实，这些情况的处理方式都是类似的：将等待的任务设置为阻塞状态（非运行态），并切换出CPU，当等待的条件满足后，再被调度内核置为就绪状态，当优先级是目前就绪任务（包含正在运行任务）的最高优先级时，再被置为运行状态，切换入CPU。
       要注意的是：1）主动挂起自身等价于延迟无限长时间；2）若挂起其它任务，则将挂起行为等价为延迟等待无限长时间，作为该任务等待的诸多条件之一，该任务只有在所有这些条件都满足后，才会被置为就绪状态；而被挂起时所需要等待的条件，就是有其它任务利用Resume API将其置为非挂起。可见，将这种挂起情况细化为一个挂起状态是可以的，但不扩展定义该挂起状态也是没有问题的，因为上述各种情况都是可以统一处理的，只定义一种阻塞状态是够用的，且系统描述更为简洁。3）挂起自身，或者挂起其它任务都需要有对应的 Resume 操作，且只能由非被挂起方的任务来调用执行。

     （4）在分析一种RTOS之前，无论先前有无分析过RTOS，都可以设想：若自己设计一个RTOS，该实现什么、如何实现。若已经具备一定的经验，则可首先思考：如何入手，对比其它RTOS的哪些方面，如何理解其实现技巧。

     （5）RTOS是一个大程序，在微处理器硬件和上层软件之间构建了一个中间管理层，起到承上启下的作用：向上为应用程序开发人员提供编程模型与统一的编程接口，向下管理各种计算、存储、软件资源；提供的编程模型能模拟现实世界的运行特征，使得应用软件能解决现实世界的功能性问题。RTOS同时也是整个软件的“非功能方面(Non-function Aspect)”，即，不能直接解决应用环境的功能性问题（由应用层软件解决），但离开RTOS，应用软件不能稳定、可靠、实时运行，且应用软件不易开发。