《嵌入式实时操作系统µC/OS-II》学习笔记(一)

引子
这本书，早在两年前毕业，一位一起进公司的好友就买了，不过一直没看，翻了翻目录，似乎工作中根本用不到，抱着一种若不能学以致用，则学了也很难深入的想法，一直也就没看。直到在上期《程序员》上看到推荐，才忽然提起兴趣，两年嵌入式开发以后，再回过头来看此书，确实还说不好合适不合适，也许随着了解的深入，不保证某天就中断了。另外笔记中主要提到的是自己平时工作中感觉用的较少或者没有注意的地方，不涉及任何所谓的重点难点，勿怪！

第一章 范例
真的基本上是范例了，列举了一些常用的线程使用情况，和整天打交道的代码有浅没深，没什么可记。不过开篇介绍了一些uC/OS-II的文件结构，也许某一天还会回过头来再看看。

第二章 实时系统概念
说来惭愧，在所谓的一个使用实时操作系统的领域摸爬滚打了两年有余，还真没深刻的感觉到所谓的实时，也许是因为在消费产品中，更多的是软实时吧。或者CPU越来越快，这方面需要关注的就越来越少？抑或早在不知不觉中形成了习惯？
硬实时和软实时：一个是硬指标，必须达到；一个只是越快越好，达不到也只是性能的降低。
前后台系统：无OS内核的系统，理解为后台是一个无限循环顺序处理各种事件，在中断响应程序中做某些标记表示某个事件出现过。与此相比，我们现在常用的方式叫加载一个内核，来管理任务这些东西，其本质可以说就是主线程，一会儿调下这个任务，一会儿又调下那个。如此说来常用的ST OS20跟Linux倒还真一样了。总是觉得ST OS20比较诡异，现在看来不过它少了一个shell任务而已了。
不可/可可剥夺内核：无论是哪种内核，中断服务程序都只能把任务由挂起状态变为就绪状态，是否进行调度，还是内核说了算。而不是直接的抢占。



不可剥夺型内核



可剥夺型内核

不可重入函数：用信号量来保护全局结构用的到多，用来保证函数不可重入确没经验了。细细想一下，似乎差不多？不过这种提法显然是值得记下来的。
时间片轮番调度法：很熟悉的概念啊，居然只在当两个或两个以上任务有同样优先级出现，而且还有部分操作系统如µC/OS-II不支持，必须保证所有的任务优先级不同。
优先级反转：三个任务，低的那个先得到了信号量，高的那个只好等着，这个时候确被中优先级的抢走了CPU，于是出现了高的等中的的现象。而这个问题得靠信号量的实现来解决，信号量的实现居然还要管这种事情？
禁止任务切换来做互斥：使用信号量做互斥用的已经滥到不能再滥，关中断也见过，用个变量（访问是关中断）在控制曾经也想过，唯一禁止做任务切换比较诡异。中断还是照来，高优先级任务还是照就绪，可我就是不理你，高优先级也得等着，可剥夺内核变成了不可剥夺内核。不过禁止任务切换显然与内核的初衷相违，难怪用的也就很少了。
信号量被用过头了：推荐说处理简单的共享变量用关中断来的更快更直接，使用信号量需要花费较多额外的时间。在任务优先级都不相同的情况下，所有的任务切换都是由中断引起的吗？存在时间片轮番调度的情况下呢？也许吧，至少乍的一想是这样的，从后来的内容来看，时钟节拍也是中断，那应该就是这个中断造成了那些一时想不通的切换吧。我们的程序大多数情况下对效率还没有敏感到这种程度，不过敏感的也有，细想起来似乎也是这么处理的。
信号量做同步：如果有一个以上的任务在等这个信号量来同步，问题就出来了，也许这正是Event存在的道理吧。跟信号量与互斥量的区别仅仅在同任务时，前者不能过，后者能过一样。
中断服务程序中不能使用信号量，要共享，就只能关中断了。
事件标志：没用过东东，不过思路很不错，用各个位表示不同的事件，要等待多个事件实际上就是等待特定的几个位置1。可惜大多数OS不支持。
中断响应：在可剥夺的型内核中，调用中断响应程序以前，还要先调一个内核的函数，通知内核。虽然这种方法已经用滥了，不过也出现在这个位置，倒还真没想到。同样，推出中断服务程序时，也有相应的函数要调用。
非屏蔽中断（NMI）：不能被关掉的中断，不过可以用硬件来关。关心的较少。
时钟节拍：特定的周期性中断，估计任务切换、时间片等很多东西都是由这个触发或者作为单位的吧。内核经常提供延时若干时钟节拍的功能，但这个延时并不准确，基本上可以把延时一个时钟节拍理解为等到下一个时钟节拍开始时运行。不过要受中断服务程序和高优先级任务的限制，不准确大体由此而产生。