关于RTOS的全部真相。 第1条
实时操作系统：简介本系列文章致力于全面研究实时操作系统（RTOS）的各个方面。 本文针对的是那些好奇地学习RTOS如何工作以及如何使用它们的开发人员。 起点将是对实时系统的一般性讨论，然后我们将讨论RTOS如何简化其实现并使代码更可靠。
在RTOS内部，我们将看到任务计划程序如何工作。 由于有了多线程，CPU似乎可以同时执行多个操作。 这不是魔术，即使没有经验的软件工程师也可以了解任务调度程序的原理。 我们将讨论RTOS的其他对象：关于任务和同步之间的交互，关于实时模式，关于内存管理等，所有内容都将通过代码示例准确地描述和支持。
对于开发人员而言，RTOS的一个关键方面是API，API是一组过程调用，它们提供对RTOS功能的访问。 该系列将重点介绍API的工作原理，可用的标准以及如何从一种API过渡到另一种API的文章。
以下是我们不久将考虑的主题列表：
- 程序结构和实时
- 实时操作系统
- 任务与计划
- 任务交互和同步
- 其他操作系统服务
- 核SE
- 策划人
- 任务
- 内存段
- 讯号
- 事件标志组
- 信号量
- 邮箱
- Queue列
- 频道
- 系统时间
- 软件计时器
- 打断
- 诊断和错误检查
- 初始化和启动
该系列文章与任何特定的实时操作系统无关；大多数材料适用于实现RTOS的公开可用选项。 根据作者的说法，在现有支持下使用现成的商用OS是最可靠，最有效的工作方式。 其中一篇文章将专门讨论“制造与购买”主题以及其他选择RTOS的方法。
但是，为了说明RTOS的内部设计，使用了实际产品代码Nucleus SE的示例。
资料来源：
http :
//www.embedded.com/design/operating-systems/4442729/简介-RTOS公开关于RTOS的全部真相。 第2条
RTOS：结构和实时模式程序结构和实时本系列文章是有关嵌入式系统的，尤其是有关在嵌入式系统上运行的软件的文章。 让我们从定义开始。 什么是嵌入式系统？ 1986年，当我撰写有关该主题的第一本书时，这个词并不存在。 虽然使用了“专用系统”或“微系统”的概念，但是它们并不能完全反映其本质。 几年后，“内置”一词开始使用，所有专家都开始积极使用它。
回到嵌入式系统的定义。 为了向亲朋好友解释我的工作，我提出了以下解释：嵌入式系统是指具有处理器但通常不被接受为计算机的任何电子设备。
操作系统（OS）始终在计算机上； 在现代嵌入式系统中，仅使用某些类型的OS。 尽管在高性能（32位和64位）系统中普遍使用内核，但在低功耗设备中使用内核仍然有可能受益。 这些文章的重点是一般和特定实现的操作系统。
为什么要完全使用操作系统？让我们看看为什么原则上使用操作系统。 有许多解释，其中一些取决于人为因素和技术特征。 我记得这个故事。 在我们的一间办公室里，有一个厨房角，您可以在那里煮咖啡。 在门上有一个铭文：“请不要关上门。” 在它下面，有人写道：“为什么不？”，其他人对此回答：“因为。” 短语“因为我们要告诉你这样做”的缩写。 出于相同的原因，仅在需要完成某些操作系统的情况下，才在某些系统上使用操作系统。
另一个解释是桌面应用程序的使用。 如果您为PC或Mac编写软件，从哪里开始？ 您打开计算机，启动Windows / Linux或macOS并开始编程。 拥有操作系统是一个既定条件，它提供了许多有用的服务。 对裸机进行编程时，您不太可能决定从头开始。 因此，如果工程师具有编写软件的经验，但是固件是新的，则工程师依赖于他开发的系统中操作系统的存在就不足为奇了。
值得注意的是，用户知道的桌面操作系统的关键方面是用户界面（UI）。 询问某人Windows是什么，他们会回答它们是窗口，菜单，对话框，图标，但是几乎没有提到文件系统，程序间通信以及与其他系统交互的能力。 这是台式机和嵌入式系统之间的主要区别：嵌入式系统可能没有用户界面，如果有，则非常简单。 这是许多关键区别中的第一个：
- 嵌入式系统通常从开机到关机都运行单个软件应用程序。
- 嵌入式系统的资源有限。 内存量可能很大，但事实并非可以扩展； 处理器功率有限。
- 许多嵌入式应用程序实时工作。 在下面的文章中对此有更多的了解。
- 固件开发工具是专用的，并且在主机（例如PC）上运行，而不在目标系统上运行。
- 更新固件是一个复杂的过程。 尽管存在因连接的设备而带来的机会，但操作期间的固件更新仍不是常态（与用于台式机软件的常规更新和补丁（补丁）相反）。
在考虑如何构建嵌入式应用程序之前，我们将了解计算机上使用操作系统执行程序的概念。
首先，当程序交替执行时，将以DOS方式执行程序。
每个程序都会启动，实施和终止。 例如，我们使用程序1，然后使用程序2，然后稍作休息，转到程序3，然后返回程序2。程序2的第二次使用再次开始：启动不是从我们上次中断的地方开始（除非应用程序本身不提供这样的机会）。
DOS之后，随着Windows变得司空见惯，事情变得有些复杂。 运行Windows风格的程序意味着以多线程模式运行多个程序。
在这种模式下，程序似乎同时运行，而Windows正在控制这种错觉。 首先，程序1开始，然后同时程序2开始，然后程序3。程序2结束，程序1和3仍在运行。 程序3结束，仅程序1保留下来，随后，程序2恢复，程序1结束，仅程序2保留，这是普通用户使用Windows时的现实情况。 操作系统分配资源，以便所有程序正确使用处理器。 它还提供了程序之间（例如剪贴板）之间的轻松通信并控制了用户界面。
某些便携式设备需要比DOS所能提供的更大的灵活性，但是，由于资源有限，与Windows相比，其开销较低。 结果，我们可以执行iOS风格的程序，即：
程序每次启动一次，但是它们的状态会自动保存，以便您可以在关闭时从同一位置继续。 例如，程序1启动，然后暂停以使用程序2，然后，例如，设备关闭一段时间。 恢复时，将加载程序3（程序2的状态已自动保存），然后用户返回到程序2，继续在其中工作。 我了解到，iOS应用程序的执行模型比上述模型复杂得多，但是，此描述仅是用户最初的感知的简要概述。
大多数内置应用程序与以上任何模型都不匹配。 通常，设备在打开电源时会启动程序，并且只能在不确定的时间内继续与此软件一起使用。 此类代码的结构应仔细考虑。
固件型号桌面系统几乎都是一样的。 从应用程序的角度来看，所有带有Windows的个人计算机都是相同的。 嵌入式系统是独特的：每个系统都彼此不同。 技术上的差异可能是：处理器类型，内存大小，外围设备数量。 应用程序的优先级在速度，能耗，安全性和可靠性方面也可能有所不同。 可能会有一些影响价格的商业差异：生产量以及在定制或标准硬件之间进行选择。
这些差异对于嵌入式开发人员很重要。 例如，开发工具（编译器，调试器等）的选择取决于处理器的类型。 许多因素都会影响操作系统的选择，甚至影响原则上应用该操作系统的决定。 必须为每个单独的嵌入式应用程序仔细选择软件结构（软件模型）。
根据应用程序的需求，嵌入式软件可能具有不同复杂性级别的各种结构，例如：
最简单的形式是一个封闭的结构，其中重复相同的动作序列。 如果应用程序足够简单，可以通过这种方式实现，那么这就是理想的选择：简单的代码可靠且易于理解。 但是，这种结构对可能占用过多处理器时间的那部分代码非常敏感，也就是说，某些命令的执行时间过长，以至于它们延迟了其他应用程序任务的执行。 此外，此模型的伸缩性不好：改进代码可能会成为问题，因为附加组件会影响旧代码的性能。
如果需要更复杂的内容，则可以尝试将代码的非关键部分放在主循环中，将时间敏感的部分放在中断处理程序中（中断服务例程，ISR）。 中断处理程序的动作基本上很短，仅执行关键任务并标记主循环的各个部分以尽快完成工作。 当需要在主循环和中断处理程序之间（以及在多个开发人员之间）分配工作时，可能会出现困难。
为了最大程度地提高应用程序的灵活性，有必要将其划分为几个独立的相对独立的程序（我们称它们为任务或线程），这些程序将在多线程模式下执行。 小型中断处理程序也可以包含在系统中，但是它们主要用于通知任务或触发操作。 为此，您需要一个操作系统或至少一个内核。 多线程的使用不仅提供了软件中功能的灵活分配，而且还促进了开发人员之间的工作分配。
什么是实时？之前，我写道许多嵌入式应用程序都是实时工作的。 在这种情况下，通常谈论实时操作系统，而不是简单的操作系统。 让我们定义术语。
“实时操作系统是一种系统，其中计算的正确性不仅取决于计算的逻辑正确性，还取决于获得结果的时间。
如果不满足系统的时间限制，则认为发生了系统故障。”
这种系统的一个重要特征是它的可预测性，或者正如他们常说的是确定性。
实时操作系统不一定非常快；“实时”并不总是意味着“真正快”。 这意味着任何必要的措施将及时完成。 即足够快，但同时又不能太快（即足够慢）。
RTOS（正确使用时）可以非常精确地控制任务处理器时间的分配，因此使应用程序具有完全确定性。 唯一可以破坏这张图片的是中断。 有些RTOS可以完全控制中断。 他们的工作是作为任务计划程序的一部分来管理中断服务。 尽管事实上这会导致可预测的行为，但是该机制非常复杂，并且包含高昂的间接费用。
大多数RTOS只是允许中断处理程序从中断时正在运行的任务中“窃取”时间。 反过来，这迫使程序员编写尽可能短的中断处理程序代码。 结果，我们实时存在一个允许的错误。 唯一的困难是作为处理程序任务的一部分调用RTOS服务。 有些调用可能非常无害，而另一些调用会在从中断返回时引起上下文切换。 应该特别解决这种情况，这可以在各种RTOS的帮助下实现。
资料来源：
https :
//www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time当我们开发自己的实时OSRV MAX操作系统时（此前已发表过有关此内容的文章） ，我们的团队“遇到了” Mentor Graphics的微电子学和固件专家Colin Walls的博客。 文章似乎很有趣，可以自己翻译，但是为了不“写到桌子上”，他们决定发表文章。 希望它们对您也有用。 如果是这样，那么我们计划发布该系列中所有翻译的文章。关于作者：Colin Walls在电子行业工作了30多年，大部分时间用于固件。 他现在是Mentor Embedded（Mentor Graphics的一个部门）的固件工程师。 Colin Walls经常在会议和研讨会上发表演讲，他撰写了许多技术文章并撰写了两本有关固件的书。 居住在英国。 Colin的专业博客： http : //blogs.mentor.com/colinwalls ，电子邮件： colin_walls@mentor.com
第3条在此处发布。