［译者的话］物联网把FreeRTOS推到了风口浪尖，各家MCU芯片公司的开发板、SDK开发套件都移植上了FreeRTOS。著名的智能手表Pebble OS 的内核使用了FreeRTOS，博通的WICED Wi-Fi SDK也推荐使用FreeRTOS。瑞典嵌入式开发工具Atollic的副总裁Magnus Unemyr 最近采访了FreeRTOS 创始人Richard Barry，Atollic 提供嵌入式开发构建软件。两人谈论的话题涉及到了FreeRTOS的历史和未来发展，Richard Barry还特别阐述了对物联网（IoT）、RTOS和工具以及嵌入式产业未来发展的理解。
什么精神鼓励你开发了FreeRTOS？
答：开发FreeRTOS的想法来自大约10多年前我经历的一个服务的项目，我的一个任务是选择一个合适的RTOS。当时可以选择的一个RTOS已经使用在该公司的商业产品里面了，但是版税极为昂贵。 而且，我们的应用仅仅需要一个很小的RTOS解决方案， 一个大的、商业的RTOS在我们这个项目中一点也没有价值。 我转而寻找一个适合的开源的RTOS，然而令我失望的是，因为没有好的文档，开源软件的学习周期太长了，还没有技术支持，软件的质量也难以让人满意。最终我只好推荐了一个商业的、没有产品版税的RTOS。
Richard Barry －FreeRTOS的创始人
当项目结束的时候，我开始思考，有多数人会经历同样的寻找过程呢？我想只是应该有数千人计吧。 因为我是一个极客，我开始自己开发一个解决方案，从中我也找到了乐趣。 最初的FreeRTOS 版本发表了之后，很明显我的预计是正确的，的确有数千计的工程师寻找这种解决方案。
之后，我就更正式的安排和计划这个工作。首先我把使用开源的免费软件的风险列了出来，比如质量、知识产权侵权和技术支持问题，接着制定了一个可以减少以上风险的FreeRTOS开发和发行的模式。举三个例子吧，FreeRTOS遵守MISRA规范，进而保证产品的质量，使用FreeRTOS没有知识产权侵权的风险，而且通过社区和专业公司提供技术支持。可以这样说，FreeRTOS 基本上就是一个商业RTOS，但是完全免费，这也就是今天人们看到FreeRTOS如此受到欢迎的原因。
［译者的话］MISRA汽车工业软件可靠性联会，这是一家在欧洲的的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。MISRA C Coding Standard旨在帮助汽车厂商开发安全的、高可靠性的嵌入式软件。这一标准中包括了127条C语言编码标准，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。
请介绍一下目前FreeRTOS以及应用情况？
答：FreeRTOS有许多应用，我会说事实胜于雄辩。现在EE time 杂志每次的嵌入式 *** 作系统市场研究报告，FreeRTOS都是名列前茅。FreeRTOS 网址搜索和下载也呈现逐年快速递增的趋势，当然在某一段时间，它会是一个在一个高度呈现平稳增长的事态。我们很高兴地看到FreeRTOS正在进入一些新型市场，这个市场的产品过去没有采用我们的技术，毫无疑问，FreeRTOS是目前世界上最广泛使用的一种RTOS。
你对现在嵌入式和工具产业的评价是什么？
答：我本人主要关注的是物联网（IoT）市场，即使有人说这个市场是宣传的有些言过其实，但是可以肯定的是，嵌入式市场因为物联网的发展而变得越发重要起来，这样嵌入式工具市场也会更加受到重视。
事实上，即使我们不谈物联网，产品的智能化也将把产业带入快速发展的阶段。与我们过去所经历的阶段相比较，硬件设计的门槛在大大降低，这一点在ARM市场中尤为明显。工具的门槛也在降低，除非你有一个好的卖点，否则软件和硬件的价格都将受到市场的打压。
在物联网领域有许多关于物联网技术和产业缺少标准的声音，每一次当我看到一个新的方案发布，并宣称解决了物联网市场的碎片问题的时候，我不禁暗暗发笑。物联网市场还没有成熟，一个方案就可以解决碎片化的问题，这现实吗，这些方案反而会加重市场的碎片化。我相信市场发展到某个阶段，一定会有一些统一的标准，但问题是：谁将是赢家，谁将是输家还很难断定。
未来几年产业的最大挑战是什么？
答：有许多话题我可以谈，其中的许多报刊媒体已经论述过了，这里我就没有必要再重复了。我想要特别强调的是：从趋势看哪技能对于些未来一代的工程师才是最重要的呢。比如说写Java代码和掌握Linux 内核是非常重要的技能，但是这并不是嵌入式工程师所拥有的唯一的技能。 我看这样的现象，使用Linux 和Java 技术的应用解决方案，在开发中出了一点小问题就举步维艰，因为工程师根本不了解问题出在哪里。 我理解软件需要抽象化的思维，市场需要更快速的开发周期，但对我而言，仅仅是为了某一个驱动程序而使用一个很大规模的软件是一个错误决定，还不如自己开发呢。或许我与时代脱节了，我已经不再年轻。我的看法是，与其采用更大规模的处理器解决技能的落后问题，不如在设计上进行创新，这样做的化还不用增加硬件的资源。
ECLIPSE 和GNU已经是行业标准，它们给开发者带来什么好处呢？
答：GCC有优点也有缺点，互联网上总是充斥着争论，赞成和反对之声都有。但是有一点是肯定的，花时间学习GCC是值得的，因为GCC支持广泛的处理器，这样你掌握的这个技能可以应用到更多的项目和更多的硬件平台上。
市场对Eclipes广泛的认可让关于Eclipse学习争论的声音变得小了，同样的道理，你们可以继续争论下去，但是市场认可了Eclipse，让学会使用Eclipse，这项技能将在你的职业生涯中不断被使用使用。
很多见到情况是Eclipse和GCC放在一起，构成了一个来自外部世界的、你熟悉和放心的环境，让你可以开始你的开发工作。Eclipse还有几个其他的优点：第一Eclipse社区写了很多插件，比如支持管理功能。第二基于Eclipse的方案很多，可以把你的代码集成到项目里面Eclipse/GCC开发环境里，Atollic TrueSTUDIO，是个需要额外收费的解决方案。对于专业的开发者，这个额外收费的解决方案会带来效率的大幅提高。收费解决方案会提供一个软件安装包、产品的稳定性和技术支持，以及更加重要的是和一系列调试软件的接口。
许多年前，当我第一次使用Eclipse的时候，它的使用方式还让我还颇费了番周折。今天我看到新的毕业生需要使用某款不是Eclipse的IDE的时候，他们也要纠结一番，因为学生们已经习惯了Eclipse。
RTOS和嵌入式中间件的发展趋势是什么？
答：应用更加复杂、连接性和丰富的用户界面，这些将促使RTOS市场的增长。 当然市场和客户依然需要许多的教育工作－化解对RTOS根深蒂固的误解。比如上周有人告诉我的一种误解，有人认为如果他们将RTOS引入他们的设计中，RTOS将消耗许多的CPU时间。实际上正好是相反的，使用了RTOS，系统将会支持一种复杂的事件驱动的设计方式，CPU只是在处理实际的产生效率的任务的时候才运行，而其他时间没有执行任务。而在以前没有RTOS 的时候，CPU 在状态没有改变或者查询一个输入有没有改变的时候，一种处在运行的状态。
与主流的软件市场一样，在嵌入式系统中免费和开源的RTOS平台是大势所趋。这种趋势在物联网系统中尤为强烈，因为在物联网边缘网络中的设备只是整个系统价值链中很小的一个部分。
FreeRTOS是嵌入式系统开源RTOS的领导者，我们期待着随着物联网快速发展，FreeRTOS将成为其中的重要成员。 FreeRTOS不是唯一高质量的、免费和值得信赖的RTOS，但是FreeRTOS的商业模式非常清晰，完全没有知识产权和后期授权的问题。可以这样说，无论你使用那种处理器，无论它的提供者是谁，FreeRTOS是一个真正的跨平台的解决方案。
RTOS是物联网的重要支撑软件，安全问题尤为关键，构建一个安全的物联网系统对于RTOS的架构和系统应用都将带来挑战和机遇。
能就你的未来计划讲几句吗？
答：当然，我还不能告诉你我的全部计划，但是你应该已经看到，我们已经有自己的TCP／IP 协议－称为FreeRTOS+TCP和FAT 文件系统－称为FreeRTOS＋FAT。
我们的目标是将FreeRTOS的价值观也带给这些中间件模块，这样，它们也是免费的、可以获得支持，当然没有任何知识产权的风险，让你放心使用。我们选择自己提供者几个模块是有下面几个原因的：网络和存储媒介的驱动程序，它们与硬件没有直接的关联，许多RTOS的应用都会用到TCP／IP和FAT 文件系统。其他企业和个人将他们的TCP／IP 和FAT 集成到FreeRTOS的应用里面来，这已经由来已久了。长期以来一直有一个问题困扰我们，我们很愿意为FreeRTOS提供免费的技术支持，但是我们无法免费支持其他的中间件，不管它是免费的、还是商业的软件，比如它无法在FreeRTOS运行的问题就很难让我们提供免费支持。 提供我们自己的TCP/IP和FAT就避免这些问题，这些软件我们自己熟悉，也已经和FreeRTOS集成好了，我们可以提供更好的支持。当然TCP/IP软件在物联网平台中的重要意义更少不言而喻的。微型 *** 作系统（Micro Operating System，Micro OS）是指占用资源极少、适用于嵌入式设备等小型系统的 *** 作系统。常见的微型 *** 作系统有以下几种：
1Contiki：Contiki是一个开源的、基于C语言的微型 *** 作系统，适用于无线传感器网络和物联网等小型系统。它的特点是占用内存和处理器资源很少，支持IPv6和6LoWPAN等网络协议。
2TinyOS：TinyOS是另一个适用于嵌入式设备的开源微型 *** 作系统，主要用于无线传感器网络和物联网应用。它的特点是占用资源少，支持事件驱动和组件化编程模型。
3FreeRTOS：FreeRTOS是一个开源的、用于嵌入式系统的实时 *** 作系统。它的特点是占用资源较少，支持多种处理器架构和编程语言，适用于需要实时性和可靠性的应用。
4RIOT：RIOT是一个开源的、基于C语言的微型 *** 作系统，适用于物联网和嵌入式设备等小型系统。它的特点是占用资源少，支持多种网络协议和硬件平台。
5NuttX：NuttX是一个开源的、用于嵌入式系统的实时 *** 作系统，支持多种处理器架构和编程语言。它的特点是占用资源较少，支持可定制的内核配置和可插拔的驱动程序。
这些微型 *** 作系统各自有其特点，可以根据实际应用场景选择最适合的 *** 作系统。怎样使用计算机实时作业系统
小型多功能计算机都配有实时作业系统即RTOS。这样不但提高了主机的利用率,方便了使用者使用装置,更重要的是它具有对受控装置请求服务时响应时间快的特点。
多使用者同时使用计算机的作业系统多个人同时可以访问，比如Linux系统，多个人可以同时登陆（远端登入），网路上的计算机应该是联网使用者的计算机
什么是非抢先式实时作业系统？ 什么是抢先式实时作业系统？ 大体说下：一般的作业系统进行时间片轮询，换句话说，一个程式的时间片用光了就得停下来让其他的程式用，直到再次轮到这个程式的时候才能够执行，这种由系统决定中断的方式局势 抢占式 作业系统，反过来，由程式决定自己是否退出的就是 非抢占式的作业系统。
实时 *** 作是另一个概念了，一般的传统Linux并不是实时作业系统。RTOS实时作业系统的单独定义如下：
实时作业系统是保证在一定时间限制内完成特定功能的作业系统。例如，可以为确保生产线上的机器人能获取某个物体而设计一个作业系统。在“硬”实时作业系统中，如果不能在允许时间内完成使物体可达的计算，作业系统将因错误结束。在“软”实时作业系统中，生产线仍然能继续工作，但产品的输出会因产品不能在允许时间内到达而减慢，这使机器人有短暂的不生产现象。一些实时作业系统是为特定的应用设计的，另一些是通用的。
据外媒报道，谷歌在上周推出了物联网作业系统Android Things，后者是谷歌为物联网装置开发的Android分支系统。结合谷歌为物联网装置推出的通讯协议Weave，Android Things将在谷歌物联网战略中发挥重要作用。Android Things是谷歌面向物联网装置市场推出的最新系统，这让物联网市场的竞争进一步升温。目前，微软正在向发烧友和原始装置制造商(OEM)推广其Windows 10 IoT系统。
什么是实时作业系统 实时作业系统,简称RTOS(Real Time Operat-
ing System) UNIX是分时系统,定时器的优先顺序
最高以UNIX为基础,允许对中断处理的优先顺序
做些调整,使系统对外部事件的响应速度保证不大于
某一特定的时间间隔,就构成了实时系统,如Lynx,
OS-9等作业系统如果作业系统能做到不宕机,且
响应速度有保证就可以用于各种控制目的了
用于控制目的时,多工是必要的,而多使用者往
往并不需要,尤其是在嵌人式应用中因此可以将
UNIX多使用者那部分功能去掉,并根据嵌人式应用的
特点,舍弃一部分不必要的功能,以适应嵌人式应用
万方资料
学习园地 327
中要求占用记忆体少的特点,这就是嵌人式多工实时
作业系统在这里," *** 作"二字已经失去了本来的含
义
RTOS的开发工具允许使用者针对不同的应用对
象对RTOS的核心进行裁剪,压缩,以适应各类应
用,并提供应用程式的除错环境
从理论上讲,无论UNIX还是基于UNIX思想
的RTOS,都包含了计算机软体理论最精华的那一部
分从实践上说,它们亦是被无数应用系统证明是完
全成功的
实时系统是指能在确定的时间内执行其功能并
对外部的非同步事件做出响应的计算机系统其 *** 作
的正确性不仅依赖于逻辑设计的正确程度,而且跟这
些 *** 作进行的时间有关"在确定的时间内"是这个
定义的核心也就是说,实时系统是对响应时间有严
格要求的例如,一个视讯播放系统要从CD-ROM
中读取高压缩率的资料,并将其解压缩,送到显示设
备解压缩的工作必须在很短的时间(毫秒级)内完
成,否则会出现画面的不连续假设影象每帧的停留
时间为30ms,那么该系统必须在这段时间内将下一
帧从CD-ROM中读出并完成解压缩30ms就成为
一个时间限制,每次处理均在30ms内就是实时的,
一万次处理有一次处理时间大于30ms也不是好的
实时系统
一个系统具有实时性并不说明该系统的响应和
处理速度非常快;而一个高速系统也未必是实时系
统特定的实时系统有其具体的时限(或速度)要求,
该时限要求对不同系统千差万别高能粒子甄别系
统的甄别处理要求在微秒或纳秒级时间内完成;而实
时资料库查询系统仅要求在使用者键人请求后几秒内
得到查询结果所以设计实时系统之初,应该明确目
标系统的实时要求是秒级的,还是毫秒,微秒级的,避
免盲目追求高速度,造成浪费
实时系统通常分为硬实时和软实时系统前者
意味着存在必须满足的时间限制,而后者意味着偶尔
超过时间限制是可以容忍的
实时作业系统是基于计算机的,是管理计算机硬
件资源并提供人机命令或程式设计介面的系统,它能在固
定的时间内对一个或多个由外设发出的讯号做出适
当的反应与普通(分时)作业系统不同,实时 *** 作系
统强调了系统对外部非同步事件响应时间的确定性,这
已经逐渐接近嵌人式系统的设计思想了
实时作业系统和分时作业系统的另一个重要区
别在于二者的任务排程方式不同
常见的分时排程演算法有时间片轮转排程,优先顺序
排程,多重伫列,最短作业优先,保证排程演算法以及彩
票排程演算法这里不详细描述这些演算法
实时排程演算法主要有三种,比较经典的是事件发
生率单调演算法(Liu和Layland, 1993)该演算法事先
为每个任务分配一个与事件发生频率成正比的优先
级,排程程式总是排程优先顺序最高的就绪任务,必要
时将剥夺当前任务的CPU使用权,让高优先顺序的任
务先执行这种演算法被证明是最优的,也是为大部分
实时核心所采用的排程方式
另一种流行的实时排程演算法是最早截止优先算
法当一个事件发生时,对应的任务被加到就绪伫列
中,该伫列按照截止期限排序,截止期限最短的优先
级最高对周期性事件,截止时间即为事件下次发生
的时间
第三种演算法首先计算各任务的富裕时间,称作裕
度(laxity)如果一个任务需要执行200ms,而它必
须在250ms内完成,则其裕度为50ms该演算法称为
最少裕度法,即选择裕度最少的任务
尽管通过这三种演算法中的任何一个都可以将分
时作业系统转化为实时作业系统,但实际上,由于前
者的任务切换时间太长,实时效能都比较低,所以实
时系统一般都采用专用的实时作业系统这些实时
作业系统的主要特征有:
规模小,
中断被遮蔽的时间很短;
中断处理时间短;
任务切换很快
常见的实时作业系统有VxWorks, VRTX/OS,
pSOS+,RTMX,OS/9和Lynx OS等等
如何定义实时作业系统
对于什么是实时系统，POSIX 1003b 作了这样的定义：指系统能够在限定的响应时间内提供所需水平的服务。而一个由 Donald Gillies 提出的更加为大家接受的定义是：一个实时系统是指计算的正确性不仅取决于程式的逻辑正确性，也取决于结果产生的时间，如果系统的时间约束条件得不到满足，将会发生系统出错。
实时系统根据其对于实时性要求的不同，可以分为软实时和硬实时两种型别。硬实时系统指系统要有确保的最坏情况下的服务时间，即对于事件的响应时间的截止期限是无论如何都必须得到满足。比如航天中的宇宙飞船的控制等就是现实中这样的系统。其他的所有有实时特性的系统都可以称之为软实时系统。如果明确地来说，软实时系统就是那些从统计的角度来说，一个任务（在下面的论述中，我们将对任务和程序不作区分）能够得到有确保的处理时间，到达系统的事件也能够在截止期限到来之前得到处理，但违反截止期限并不会带来致命的错误，像实时多媒体系统就是一种软实时系统。
一个计算机系统为了提供对于实时性的支援，它的作业系统必须对于 CPU 和其他资源进行有效的排程和管理。在多工实时系统中，资源的排程和管理更加复杂
去网上下个定时开关机,,实时提醒就 OK;a啦 ```
供多个使用者同时使用计算机的作业系统称为B
作业系统使使用者使用计算机必备的一种什么？作业系统是使用者使用计算机必备的一种软体
嵌入式实时作业系统 嵌入式实时作业系统ucos ii的分析2010年01月06日 星期三 上午 01:15摘要：近年来，在微控制器系统中嵌入作业系统已经成为人们越来越关心的一个话题。本文通过对一种原始码公开的嵌入式实时作业系统ucos ii的分析，以51系列微控制器为例，阐述了在微控制器中使用该嵌入式作业系统的优缺点，以及在应用中应当注意的一些问题。
关键词：实时作业系统；ucos ii；微控制器
引言
早在20世纪60年代，就已经有人开始研究和开发嵌入式作业系统。但直到最近，它才在国内被越来越多的提及，在通讯、电子、自动化等需要实时处理的领域所曰益显现的重要性吸引了人们越来越多的注意力。但是，人们所谈论的往往是一些著名的商业核心，诸如VxWorks、PSOS等。这些商业核心效能优越，但价格昂贵，主要用于16位和32位处理器中，针对国内大部分使用者使用的51系列8位微控制器，可以选择免费的ucos ii。
ucos ii的特点
1．ucos ii是由Labrosse先生编写的一个开放式核心，最主要的特点就是原始码公开。这一点对于使用者来说可谓利弊各半，好处在于，一方面它是免费的，另一方面使用者可以根据自己的需要对它进行修改。缺点在于它缺乏必要的支援，没有功能强大的软体包，使用者通常需要自己编写驱动程式，特别是如果使用者使用的是不太常用的微控制器，还必须自己编写移植程式。
2．ucos ii是一个占先式的核心，即已经准备就绪的高优先顺序任务可以剥夺正在执行的低优先顺序任务的CPU使用权。这个特点使得它的实时性比非占先式的核心要好。通常我们都是在中断服务程式中使高优先顺序任务进入就绪态（例如发讯号），这样退出中断服务程式后，将进行任务切换，高优先顺序任务将被执行。拿51微控制器为例，比较一下就可以发现这样做的好处。假如需要用中断方式采集一批资料并进行处理，在传统的程式设计方法中不能在中断服务程式中进行复杂的资料处理，因为这会使得关中断时间过长。所以经常采用的方法是置一标志位，然后退出中断。由于主程式是回圈执行的，所以它总有机会检测到这一标志并转到资料处理程式中去。但是因为无法确定发生中断时程式到底执行到了什么地方，也就无法判断要经过多长时间资料处理程式才会执行，中断响应时间无法确定，系统的实时性不强。如果使用μC/OS-II的话，只要把资料处理程式的优先顺序设定得高一些，并在中断服务程式中使它进入就绪态，中断结束后资料处理程式就会被立即执行。这样可以把中断响应时间限制在一定的范围内。对于一些对中断响应时间有严格要求的系统，这是必不可少的。但应该指出的是如果资料处理程式简单，这样做就未必合适。因为ucos ii要求在中断服务程式末尾使用OSINTEXIT函式以判断是否进行任务切换，这需要花费一定的时间。
3．ucos ii和大家所熟知的Linux等分时作业系统不同，它不支援时间片轮转法。ucos ii是一个基于优先顺序的实时作业系统，每个任务的优先顺序必须不同，分析它的原始码会发现，ucos ii把任务的优先顺序当做任务的标识来使用，如果优先顺序相同，任务将无法区分。进入就绪态的优先顺序最高的任务首先得到CPU的使用权，只有等它交出CPU的使用权后，其他任务才可以被执行。所以它只能说是多工，不能说是多程序，至少不是我们所熟悉的那种多程序。显而易见，如果只考虑实时性，它当然比分时系统好，它可以保证重要任务总是优先占有CPU。但是在系统中，重要任务毕竟是有限的，这就使得划分其他任务的优先权变成了一个让人费神的问题。另外，有些任务交替执行反而对使用者更有利。例如，用微控制器控制两小块显示屏时，无论是程式设计者还是使用者肯定希望它们同时工作，而不是显示完一块显示屏的资讯以后再显示另一块显示屏的资讯。这时候，要是ucos ii即支援优先顺序法又支援时间片轮转法就更合适了。
4．ucos ii对共享资源提供了保护机制。正如上文所提到的，ucos ii是一个支援多工的作业系统。一个完整的程式可以划分成几个任务，不同的任务执行不同的功能。这样，一个任务就相当于模组化设计中的一个子模组。在任务中新增程式码时，只要不是共享资源就不必担心互相之间有影响。而对于共享资源（比如串列埠），ucos ii也提供了很好的解决办法。一般情况下使用的是讯号量的方法。简单地说，先建立一个讯号量并对它进行初始化。当一个任务需要使用一个共享资源时，它必须先申请得到这个讯号量，而一旦得到了此讯号量，那就只有等使用完了该资源，讯号量才会被释放。在这个过程中即使有优先权更高的任务进入了就绪态，因为无法得到此讯号量，也不能使用该资源。这个特点的好处显而易见，例如当显示屏正在显示资讯的时候，外部产生了一个中断，而在中断服务程式中需要显示屏显示其他资讯。这样，退出中断服务程式后，原有的资讯就可能被破坏了。而在μC/OS-II中采用讯号量的方法时，只有显示屏把原有资讯显示完毕后才可以显示新资讯，从而可以避免这个现象。不过，采用这种方法是以牺牲系统的实时性为代价的。如果显示原有资讯需要耗费大量时间，系统只好等待。从结果上看，等于延长了中断响应时间，这对于未显示资讯是报警资讯的情况，无疑是致命的。发生这种情况，在μC/OS-II中称为优先顺序反转，就是高优先顺序任务必须等待低优先顺序任务的完成。在上述情况下，在两个任务之间发生优先顺序反转是无法避免的。所以在使用ucos ii时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用讯号量。
ucos ii在微控制器使用中的一些特点
1．在微控制器系统中嵌入ucos ii将增强系统的可靠性，并使得除错程式变得简单。以往传统的微控制器开发工作中经常遇到程式跑飞或是陷入死回圈。可以用看门狗解决程式跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设定断点，耗费大量时间来慢慢分析。如果在系统中嵌入 ucos ii的话，事情就简单多了。可以把整个程式分成许多工，每个任务相对独立，然后在每个任务中设定超时函式，时间用完以后，任务必须交出 CPU的使用权。即使一个任务发生问题，也不会影响其他任务的执行。这样既提高了系统的可靠性，同时也使得除错程式变得容易。
2．在微控制器系统中嵌入ucos ii将增加系统的开销。现在所使用的51微控制器，一般是指87C51或者89C51，其片内都带有一定的RAM和 ROM。对于一些简单的程式，如果采用传统的程式设计方法，已经不需要外扩储存器了。如果在其中嵌入ucos ii的话，在只需要使用任务排程、任务切换、讯号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。由于ucos ii是可裁减的作业系统，其所需要的RAM大小就取决于作业系统功能的多少。举例来说，μC/OS-II允许使用者定义最大任务数。由于每建立一个任务，都要产生一个与之相对应的资料结构TCB，该资料结构要占用很大一部分记忆体空间。所以在定义最大任务数时，一定要考虑实际情况的需要。如果定得过大，势必会造成不必要的浪费。嵌入ucos ii以后，总的RAM需求可以由如下表达式得出：
RAM总需求=应用程式的RAM需求+核心资料区的RAM需求+（任务栈需求+最大中断巢状栈需求）·任务数
所幸的是，μC/OS-II可以对每个任务分别定义堆叠空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。但在RAM容量有限的情况下，还是应该注意一下对大型阵列、资料结构和函式的使用，别忘了，函式的形参也是要推入堆叠的。
3．ucos ii的移植也是一件需要值得注意的工作。如果没有现成的移植例项的话，就必须自己来编写移植程式码。虽然只需要改动两个档案，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植例项。另外，即使有移植例项，在程式设计前最好也要阅读一下，因为里面牵扯到堆叠 *** 作。在编写中断服务程式时，把暂存器推入堆叠的顺序必须与移植程式码中的顺序相对应。
4．和其他一些著名的嵌入式作业系统不同，ucos ii在微控制器系统中的启动过程比较简单，不像有些作业系统那样，需要把核心编译成一个映像档案写入ROM中，上电覆位后，再从ROM中把档案载入到RAM中去，然后再执行应用程式。ucos ii的核心是和应用程式放在一起编译成一个档案的，使用者只需要把这个档案转换成HEX格式，写入ROM中就可以了，上电后，会像普通的微控制器程式一样执行。
结语
由以上介绍可以看出，ucos ii具有免费、使用简单、可靠性高、实时性好等优点，但也有移植困难、缺乏必要的技术支援等缺点，尤其不像商用嵌入式系统那样得到广泛使用和持续的研究更新。但开放性又使得开发人员可以自行裁减和新增所需的功能，在许多应用领域发挥着独特的作用。当然，是否在微控制器系统中嵌入ucos ii应视所开发的专案而定，对于一些简单的、低成本的专案来说，就没必要使用嵌入式作业系统了。
RT-Thread，全称是 Real Time-Thread， 是一款主要由中国开源社区主导开发的开源实时 *** 作系统（许可证GPLv2），包含了实时、嵌入式系统相关的各个组件：TCP/IP协议栈、图形用户界面等。
相较于Linux，RT-Thread 具有体积小，成本低，功耗低、启动快速的优势。除此以外，实时性高、占用资源小等特点，使得它也非常适用于各种资源受限（如成本、功耗限制等）的场合。
在物联网设备的应用中，RT-Thread 能使用在线软件包管理工具，配合系统配置工具，实现直观、快速的模块化裁剪、无缝导入丰富的软件功能包，以及类似 Android 的图形界面和触摸滑动、智能语音交互等复杂功能。
RT-Thread 系统完全开源，可以免费在商业产品中使用，并且不需要公开私有代码。
二、RT-Thread的架构
相对于一些传统的RTOS 如 FreeRTOS、uC/OS 等，RT-Thread 架构上最大的区别在于：它是一个物联网 *** 作系统（IoT OS）。
即RT-Thread 除了包含一个实时内核外，还包括如文件系统、图形库等较为完整的中间件组件，是具备低功耗、安全、通信协议支持和云端连接能力的软件平台，如下图所示：
在这里插入描述
具体包括以下部分：
内核层：
① RT-Thread 内核：系统核心部分，包括了内核系统中对象的实现，例如多线程及其调度、消息队列、内存管理等；
② libcpu/BSP（芯片移植相关文件 / 板级支持包）：与硬件密切相关，由外设驱动和 CPU 移植构成；
组件与服务层：
组件是基于内核之上的上层软件，例如虚拟文件系统、FinSH 命令行界面、网络框架、设备框架等。采用模块化设计，做到组件内部高内聚，组件之间低耦合；
RT-Thread 软件包：
运行于 RT-Thread 物联网 *** 作系统平台上，面向不同应用领域的通用软件组件，由描述信息、源代码或库文件组成。开发者可依据自身需求，选择、组合不同软件包，打造自己想要的系统。
目前支持的软件包有且不仅有：
① 物联网相关：Paho MQTT、WebClient、mongoose、WebTerminal 等；
② 脚本语言相关：JerryScript、MicroPython ；
③ 多媒体相关：Openmv、mupdf；
④ 系统相关：RTGUI、Persimmon UI、lwext4、partition、SQLite 等。
三、RT-Thread的开发工具
Env 是 RT-Thread 的开发辅助工具，提供编译构建环境、图形化系统配置、软件包管理等功能。主要特性如下：
使用 scons 作为构建工具（根据一定的规则或指令，将源代码编译成可执行的二进制程序），提供编译环境，生成工程；
内置简单易用的配置剪裁工具——menuconfig，可对内核、组件和软件包进行自由裁剪，以搭积木的方式构建系统；
借助由 Kconfig 语法 编写的Kconfig 文件，生成系统配置文件 rtconfigh。rtconfigh 文件，负责在执行 menuconfig 命令时，指导生成 RT-Thread 系统的配置、剪裁界面；
提供多种软件包，可在线下载，各包耦合关联少，具有良好的可维护性。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）