《嵌入式操作系统史话》之四：μ C/OS的故事（一）
时间：2014-01-27 10:40:34
手机看文章
扫描二维码
随时随地手机看文章
[导读]μC/OS也叫MicroC/OS，它是在国内具有广泛影响力的RTOS之一，这主要得益于作者Jean Labrosse 的几本介绍μC/OS原理和使用的中文版图书在国内的广为流传。与其他商业RTOS不同的是，μC/OS内核的源代码是开源的，对于非
μC/OS也叫MicroC/OS，它是在国内具有广泛影响力的RTOS之一，这主要得益于作者Jean Labrosse 的几本介绍μC/OS原理和使用的中文版图书在国内的广为流传。与其他商业RTOS不同的是，μC/OS内核的源代码是开源的，对于非商业客户（比如大学老师和学生们）也是免费的，据笔者统计，累计至今已有数十本以μC/OS命名的中文版图书出版，数百所学校院系和专业开设的嵌入式开发设计相关课程使用μC/OS作为嵌入式OS 案例，数千篇研究μC/OS相关技术的论文发表。本文摘自北京航空航天大学出版社出版的《嵌入式实时多任务操作系统μC/OS-III》一书的前言，笔者有改编和删减。
μC/OS的故事起始于1989年。那时，我（注：即Jean Labrosse先生）加入到位于美国佛罗里达州劳德代尔堡市的Dynalco控制公司，并开始为大型工业往复式发动机设计全新的、基于微控制器的点火控制系统。由于有实时内核的使用经验，我相信使用操作系统可有强力地推动该项目以及Dynalco公司其它在研项目的进展。
对于该点火控制系统而言，进入市场的时间至关重要。并且，我知道实时内核的使用能够帮助我实现既定目标。我也知道将来还要为这款产品增加一些新的功能，而使用可剥夺型（注：也称为可抢占式）的操作系统将允许在不破坏系统响应特性的情况下做这些升级。我最初考虑使用的内核是一个过去我用过且很熟悉的内核。不过，该内核非常昂贵，而我的经费却不是很充足。备选的是用一个过去我没有用过的内核，其价格只有最初选择内核的五分之一。
最终，考虑到节省经费，我选择了使用不熟悉的那个操作系统。然而，我很快意识到需要为这个看起来更便宜的操作系统付出我更多的时间。在拿到内核后的两个月，我不停地联系对方的技术支持人员，徒劳无益地做各种尝试，想知道为什么连一个最简单的应用程序都跑不起来。这个操作系统说是用C语言写的，却要求用汇编语言初始化所有的内核变量。后来发现，我是最先购买这个操作系统的那批用户之一，是在不知情的情况下充当了这个操作系统的试用版测试员。
实在是受够了，我转而使用最初放弃的那个较昂贵的操作系统。眼看项目要延期，钱就再不是问题了。不到两天，简单的应用程序就跑起来了，这在之前那个便宜的操作系统上好像是不可能做到的事。内核相关的问题似乎解决了。然而，很快我发现自己又进入了另外一个僵局。有一天，我的一个工程师向我汇报这个新的操作系统好像有毛病（bug），从此，一系列的问题就开始了。我很快把这个工程师发现的问题转发给软件厂商，暗想他们会对此感兴趣。但是，没有收到他们修正bug的保证，取而代之的是，我接到通知说90天的担保期已过。除非支付给他们一笔维护费，否则，他们不会修正这个bug，对我来说这种要求简直是不可理喻。按照软件厂商的希望，我支付了这笔维护费用。想不到的是，软件厂商竟然花费了6个月才去掉了这个bug。最终，在拿到第二个操作系统的一年以后，才利用该操作系统完成了我的点火控制系统。很明显，我需要一个更好的解决方案。
两次失望后，我开始开发自己的内核。我想得很简单，认为一个内核真正需要做的事情就是保存和恢复CPU寄存器，写一个内核应当不是一件很有挑战性的事情。大约花了一年时间，我果真写完了我的第一个操作系统。也正是有了新操作系统在手，开发多任务应用程序就如鱼得水了。该操作系统主要由一个C文件构成，一个应用中允许创建多达64个任务。每个任务有独一无二的优先级。每次调用任务调度器时，CPU总是运行处于就绪态的优先级最高的任务。μC/OS是可剥夺型内核，在任意时刻都可能发生任务调度。高效的任务调度实际上只是μC/OS提供的众多服务之一。此外，该操作系统还会提供任务间通信（通过消息队列和邮箱）和任务间同步（通过信号量）相关的服务。μC/OS所有元素的设计都考虑了高可靠性以及简便易用。
在我的职业生涯中，自始自终都很注重代码的一致性和文档说明。从1984年开始，我就使用规范的代码标准，μC/OS代码的一致性可以很好地证明这一点。在Dynalco工作时，我创造并推广了一套严格的代码编写规范。μC/OS就是根据这套规范设计的。μC/OS源代码的特点包括：大量的空行、字斟句酌的注释和统一的命名。μC/OS内核还具有极好的可移植性，这也进一步证实了这种严谨的代码编写规范的优势所在。虽然μC/OS跟它的先驱者一样也有少量的与处理器相关的函数，但是，这些函数代码与操作系统中的其它代码很清楚地分开了。工程师们能够非常简单地把μC/OS移植到一个新的CPU架构上。
我是知道μC/OS优点的人，为了把我的新软件介绍给其他人，我写了一篇很长的文章，详细解释了μC/OS的内部工作原理。因为有太多东西要说，最终我的文章长达约70页。我把文章投给《C语言用户日记》（C User’s Journal），文章被拒载了，原因有二，一是文章太长了，二是文章主题不够新。该杂志已经出版了多篇关于内核的文章，而这只是又一篇关于实时内核的文章。但我坚信我的文章是独一无二的，我又把它投给《嵌入式系统编程》（Embedded Systems Programming）。该杂志的编辑给我的答复和《C语言用户日记》是一样的，但我最终还是使他相信了μC/OS是一个非常值得关注的操作系统。我向他解释μC/OS在质量上可以与主流嵌入式软件公司提供的商业RTOS媲美（并且至少比其中两个操作系统要好）。我还解释说，μC/OS的源代码可放到该杂志的电子留言板上（BBS）。《嵌入式系统编程》分两部分连载了经过删减的文章。发表的两部分文章都反响强烈。工程师们非常高兴地看到，高质量内核的内部工作原理被揭露出来了，他们争相下载了μC/OS的源代码。另一方面，内核厂商则对该文章的发表非常不安。实际上，那个廉价内核厂商尤其不安，竟声称我抄袭了他们的工作。试想一下，我怎么可能基于一个不能运行的软件来开发μC/OS！
很快，令RTOS厂商更加不安的事情出现了。我的文章被《嵌入式系统编程》杂志刊登后不久，《C语言用户日记》的出版商，R&D出版社，主动联系我，表示想出版一本μC/OS的书。起初，这本书只是计划把我最早提交给《C语言用户日记》的材料打印出来。如果采用这种思路，这本书也就80页左右。为了充分利用这次机会，我计划写一本深入介绍μC/OS的书。经R&D出版社的同意，在接下来的几个月，我开始写作。到1992年的下半年，我的第一本书《μC/OS，The Real-Time Kernel》出版了（见图1）。最开始，这本书的售出速度并不令人满意，但R&D出版社每个月都会在《C语言用户日记》上给这本书做广告。与此同时，我渐渐被大家认可，成为一个内核专家。1993年的春天，我接受邀请，参加了在乔治亚州亚特兰大市举办的嵌入式系统会议（ESC），为超过70位嵌入式爱好者讲述了操作系统的基本原理。在接下来的几年中，我一直参加ESC年会，每次都会对几百个工程师讲述我的内核。逐渐大家对我写的书的兴趣也提高了。过了最初缓慢发售阶段，《μC/OS，The Real-Time Kernel》最终销量超过15,000本。
μC/OS的故事起始于1989年。那时，我（注：即Jean Labrosse先生）加入到位于美国佛罗里达州劳德代尔堡市的Dynalco控制公司，并开始为大型工业往复式发动机设计全新的、基于微控制器的点火控制系统。由于有实时内核的使用经验，我相信使用操作系统可有强力地推动该项目以及Dynalco公司其它在研项目的进展。
对于该点火控制系统而言，进入市场的时间至关重要。并且，我知道实时内核的使用能够帮助我实现既定目标。我也知道将来还要为这款产品增加一些新的功能，而使用可剥夺型（注：也称为可抢占式）的操作系统将允许在不破坏系统响应特性的情况下做这些升级。我最初考虑使用的内核是一个过去我用过且很熟悉的内核。不过，该内核非常昂贵，而我的经费却不是很充足。备选的是用一个过去我没有用过的内核，其价格只有最初选择内核的五分之一。
最终，考虑到节省经费，我选择了使用不熟悉的那个操作系统。然而，我很快意识到需要为这个看起来更便宜的操作系统付出我更多的时间。在拿到内核后的两个月，我不停地联系对方的技术支持人员，徒劳无益地做各种尝试，想知道为什么连一个最简单的应用程序都跑不起来。这个操作系统说是用C语言写的，却要求用汇编语言初始化所有的内核变量。后来发现，我是最先购买这个操作系统的那批用户之一，是在不知情的情况下充当了这个操作系统的试用版测试员。
实在是受够了，我转而使用最初放弃的那个较昂贵的操作系统。眼看项目要延期，钱就再不是问题了。不到两天，简单的应用程序就跑起来了，这在之前那个便宜的操作系统上好像是不可能做到的事。内核相关的问题似乎解决了。然而，很快我发现自己又进入了另外一个僵局。有一天，我的一个工程师向我汇报这个新的操作系统好像有毛病（bug），从此，一系列的问题就开始了。我很快把这个工程师发现的问题转发给软件厂商，暗想他们会对此感兴趣。但是，没有收到他们修正bug的保证，取而代之的是，我接到通知说90天的担保期已过。除非支付给他们一笔维护费，否则，他们不会修正这个bug，对我来说这种要求简直是不可理喻。按照软件厂商的希望，我支付了这笔维护费用。想不到的是，软件厂商竟然花费了6个月才去掉了这个bug。最终，在拿到第二个操作系统的一年以后，才利用该操作系统完成了我的点火控制系统。很明显，我需要一个更好的解决方案。
两次失望后，我开始开发自己的内核。我想得很简单，认为一个内核真正需要做的事情就是保存和恢复CPU寄存器，写一个内核应当不是一件很有挑战性的事情。大约花了一年时间，我果真写完了我的第一个操作系统。也正是有了新操作系统在手，开发多任务应用程序就如鱼得水了。该操作系统主要由一个C文件构成，一个应用中允许创建多达64个任务。每个任务有独一无二的优先级。每次调用任务调度器时，CPU总是运行处于就绪态的优先级最高的任务。μC/OS是可剥夺型内核，在任意时刻都可能发生任务调度。高效的任务调度实际上只是μC/OS提供的众多服务之一。此外，该操作系统还会提供任务间通信（通过消息队列和邮箱）和任务间同步（通过信号量）相关的服务。μC/OS所有元素的设计都考虑了高可靠性以及简便易用。
在我的职业生涯中，自始自终都很注重代码的一致性和文档说明。从1984年开始，我就使用规范的代码标准，μC/OS代码的一致性可以很好地证明这一点。在Dynalco工作时，我创造并推广了一套严格的代码编写规范。μC/OS就是根据这套规范设计的。μC/OS源代码的特点包括：大量的空行、字斟句酌的注释和统一的命名。μC/OS内核还具有极好的可移植性，这也进一步证实了这种严谨的代码编写规范的优势所在。虽然μC/OS跟它的先驱者一样也有少量的与处理器相关的函数，但是，这些函数代码与操作系统中的其它代码很清楚地分开了。工程师们能够非常简单地把μC/OS移植到一个新的CPU架构上。
我是知道μC/OS优点的人，为了把我的新软件介绍给其他人，我写了一篇很长的文章，详细解释了μC/OS的内部工作原理。因为有太多东西要说，最终我的文章长达约70页。我把文章投给《C语言用户日记》（C User’s Journal），文章被拒载了，原因有二，一是文章太长了，二是文章主题不够新。该杂志已经出版了多篇关于内核的文章，而这只是又一篇关于实时内核的文章。但我坚信我的文章是独一无二的，我又把它投给《嵌入式系统编程》（Embedded Systems Programming）。该杂志的编辑给我的答复和《C语言用户日记》是一样的，但我最终还是使他相信了μC/OS是一个非常值得关注的操作系统。我向他解释μC/OS在质量上可以与主流嵌入式软件公司提供的商业RTOS媲美（并且至少比其中两个操作系统要好）。我还解释说，μC/OS的源代码可放到该杂志的电子留言板上（BBS）。《嵌入式系统编程》分两部分连载了经过删减的文章。发表的两部分文章都反响强烈。工程师们非常高兴地看到，高质量内核的内部工作原理被揭露出来了，他们争相下载了μC/OS的源代码。另一方面，内核厂商则对该文章的发表非常不安。实际上，那个廉价内核厂商尤其不安，竟声称我抄袭了他们的工作。试想一下，我怎么可能基于一个不能运行的软件来开发μC/OS！
很快，令RTOS厂商更加不安的事情出现了。我的文章被《嵌入式系统编程》杂志刊登后不久，《C语言用户日记》的出版商，R&D出版社，主动联系我，表示想出版一本μC/OS的书。起初，这本书只是计划把我最早提交给《C语言用户日记》的材料打印出来。如果采用这种思路，这本书也就80页左右。为了充分利用这次机会，我计划写一本深入介绍μC/OS的书。经R&D出版社的同意，在接下来的几个月，我开始写作。到1992年的下半年，我的第一本书《μC/OS，The Real-Time Kernel》出版了（见图1）。最开始，这本书的售出速度并不令人满意，但R&D出版社每个月都会在《C语言用户日记》上给这本书做广告。与此同时，我渐渐被大家认可，成为一个内核专家。1993年的春天，我接受邀请，参加了在乔治亚州亚特兰大市举办的嵌入式系统会议（ESC），为超过70位嵌入式爱好者讲述了操作系统的基本原理。在接下来的几年中，我一直参加ESC年会，每次都会对几百个工程师讲述我的内核。逐渐大家对我写的书的兴趣也提高了。过了最初缓慢发售阶段，《μC/OS，The Real-Time Kernel》最终销量超过15,000本。
图1：《μC/OS，The Real-Time Kernel》和书后附的1.1版软件
下载文档
