关于RTOS的全部真相。 第6条。 其他RTOS服务



先前的文章中,我们根据执行的任务以及它们之间的交互来讨论了内核的功能。 在本文中,我们将介绍内核还可以做些什么,这在许多其他可用的API调用中得到了明显体现。 我们还将回答以下问题:什么将内核变成操作系统?

该系列中的先前文章:
第5条 任务交互和同步
第4条 任务,上下文切换和中断
第3条 任务与计划
第2条。 RTOS:结构和实时模式
第1条 RTOS:简介。

任务管理


除了任务计划和它们之间的交互,RTOS将包括用于以各种方式管理任务的功能(API调用)。 让我们考虑一些可能性。

创建和删除任务

在“动态” RTOS中,有一些函数调用,可让您在需要时创建任务(和其他RTOS对象)。 此类调用包括定义任务的各种参数,例如,入口点,堆栈大小和优先级。 相应的任务删除API调用使您可以在任务完成后释放资源。

在“静态” RTOS中,任务的定义参数在组装过程中以一种配置文件进行配置。

暂停并恢复任务

如我们所见,大多数RTOS都具有任务“挂起”状态的概念。 这可以通过多种方式来实现。 其中之一是对Suspend Task API函数的显式调用。 它可能是由其自身或其他任务引起的。 相应的“恢复任务”调用允许任务再次排队进行计划。

任务睡眠状态

对于实时系统,时间控制是一项重要要求,并且可以采用多种形式。 一个简单的视图就是任务“入睡”的能力,也就是说,任务被挂起了一定的时间。 时间用完后,任务“醒来”,再次排队等待计划。 为此通常可以使用API​​调用。 当然,此功能取决于计时器的可用性。

免税

使用循环调度程序(“轮播”)时,任务可能拒绝控制处理器以处理链中的下一个任务。 为此,“发布任务” API功能将可用。 任务没有被挂起,轮到它时可以用于计划。 使用时间片调度程序时,如果任务没有立即要做的重要工作,则有可能释放一部分时间间隔。 运行“运行至完成”调度程序或“优先级”调度程序时,释放任务没有逻辑意义。

任务完成

在上一篇文章中,我们发现,除了“就绪”或“挂起”状态外,RTOS还可以支持其他任务状态。 该任务可以“完成”,这意味着它的主要功能就已保留:不需要特殊的API调用。 任务可以“终止”,这意味着该任务不可用于计划,必须将其重置才能再次启动,请参见下面的“重置任务”。 这需要特殊的API调用。 这些附加任务状态的可用性,所使用的术语及其确切定义将取决于RTOS。

任务重置

许多RTOS都提供了对“重置任务” API函数的调用,该函数使您可以将任务恢复为原始状态。 她可能处于挂起状态,需要执行“恢复任务”功能才能排队进行计划。

优先任务等

在“动态” RTOS中,API调用可用于在运行时配置多个任务参数。 示例包括优先级和时间间隔持续时间。

系统信息


在RTOS中,将有许多API调用可为系统提供有关任务的信息,包括:
有关任务的信息 。 系统中有多少个任务,它们的配置和当前状态。
有关其他内核对象的信息。 系统中每种类型有多少个对象,它们的配置以及有关当前状态的信息。 例如:

  • 当前队列的容量是多少?我可以添加更多消息吗?
  • 特定邮箱上挂起了多少个任务?
有关RTOS版本的信息 。 API调用可以提供类似的数据。

内存分配


在许多应用程序中,重要的是程序可以在需要时动态捕获一些内存,并在不再需要时释放它。 固件中也会发生相同的情况。 但是,常规方法容易出现桌面应用程序不太可能或不方便的问题,但对嵌入式系统可能是灾难性的。 但是,即使在静态RTOS中,也有实现此类服务的方法。

malloc()和free()函数的问题


在桌面C程序中,一个函数可以调用malloc() ,指示需要多少内存,并返回指向存储区域的指针。 使用内存,可以通过调用free()释放它。 内存是从称为堆的区域分配的。 这种方法的问题在于,如果对这些函数的调用序列不协调,堆区域很容易变得碎片化,那么即使有足够的可用内存,内存分配也会失败。 相邻区域不够大。 某些系统(例如Java和Visual Basic)使用复杂的“垃圾收集”方案进行碎片整理。 问题在于,这些方案可能导致运行时出现严重的不可预测的延迟,并且需要使用间接指针(在C语言中不起作用)。

如果malloc()free()以可重入的方式(通常不是)实现并由RTOS任务使用,则碎片将很快发生,并且系统故障几乎是不可避免的。 在C ++中,存在newdelete运算符,它们通常执行与malloc()和free()相同的功能。 它们受到相同的限制和问题。

内存段


为了向实时系统提供可动态访问的内存,可以使用内存管理的块方法。 这样的块通常称为“分区”。 可以从“分区池”中分配分区。

分区池包含一定数量的块,每个块具有相同的大小。 创建分区池时确定分区中块的数量和大小。 如果系统本身允许的话,这可以是动态的,也可以在组装过程中是静态的。 通常,一个应用程序可能包括几个分区池,这些分区池提供不同大小的块。

如果任务需要内存,它将调用一个API,该API向特定池请求一个块。 如果此调用成功,任务将收到指向所选块的指针。 如果呼叫失败是因为 指定的池中没有可用的分区,任务可能会收到错误响应。 或者,任务可以被阻塞(暂停),直到另一个任务释放该部分中的块为止。

通常,任务只是将指针传递给使用该块的任何代码中的内存块。 当不再需要该块时,这会导致问题。 如果代码仅具有指向块的指针,则如何通过API调用告诉RTOS,它要从哪个分区池中释放内存? 答案是,大多数RTOS在专用块中支持其他数据(通常是指针的负偏移量),以提供所需的信息。 因此,要调用API释放一个块,只需要其地址即可。

以下文章将提供有关内存分区的更多信息。

时间


与时间的使用和控制相关的功能很可能在实时OS中可用。 机会会因实时操作系统而有所不同,但我们会考虑将其公开。 无论如何,对于任何这些服务的功能来说,实时计时器都是必不可少的元素。

系统时间

简单的系统时间或“时钟计时器”几乎总是可用的。 这只是一个计数器(通常为32位),使用实时中断服务程序将其递增,并且可以通过API调用对其进行设置和读取。

服务呼叫超时

通常,RTOS允许阻止API调用,即,调用任务被挂起(阻止),直到提供所请求的服务为止。 通常,此锁含糊不清,但是某些RTOS提供了超时,如果服务继续不可用,则在超时到期时调用将返回。 所有RTOS都不支持API调用超时。

任务睡眠状态

通常,任务具有将自己暂停固定时间段的能力。 前面在“任务管理”部分中对此进行了讨论。

软件计时器

为了使程序任务执行计时功能,大多数RTOS提供了计时器对象。 这些是由实时计时器中断处理程序更新的独立计时器,可以通过API调用进行控制。 这样的调用配置,监视和监视计时器的操作。 通常,可以将它们设置为单次致动或自动重启。 通常还支持到期例程,该函数在每次计时器完成一个周期时运行。 下一篇文章将提供有关软件计时器的更多信息及其实现的描述。

中断,驱动程序和I / O


RTOS与中断和I / O关联的程度非常不同。 同样,某些RTOS的设备驱动程序结构也非常清晰,在选择特定产品时可能会增加问题。

打断

由于两个原因,中断为RTOS带来了问题。

  • 在没有任何预防措施的情况下,中断处理程序(ISR)将“窃取”处理器时间,从而破坏实时RTOS行为。
  • 如果ISR发出影响任务计划的API调用,则应对此进行监视,并且RTOS应该能够运行其计划算法。
这样的API调用的一个示例是唤醒优先级高于中断发生时启动的任务的过程。

一些RTOS完全控制所有中断。 一系列API调用可用于“注册” ISR程序。 这种方法允许调度程序查明何时启用了中断,并有助于使用ISR中的大多数API调用。

例如,Nucleus RTOS实现了“低优先级”和“高优先级”中断处理程序的概念,该中断处理程序提供了可靠的中断控制,而没有不必要的开销(即中断延迟增加)。

其他RTOS可以对中断使用自动“切换”模式,这为开发人员提供了更多选项,以确保中断处理程序正常工作。 通常,将提供附加的ISR前缀(序言)和后缀(结尾)以保护在其中进行的API调用。
Nucleus SE使用了轻量级的中断例程,这将在以后的文章中进行介绍。

车手

大多数RTOS决定设备驱动程序的结构。 详细信息可能取决于RTOS,但驱动程序通常由两个交互组件组成:嵌入式代码(API调用)和ISR。 通常,其他API调用可用于管理和注册驱动程序。

输入/输出

当前,市场上的大多数RTOS都不在乎较高级别的输入/输出,但是其中一些定义了输入/输出流,该流基本上在相应的设备驱动程序和标准C语言函数(例如printf())之间建立连接。
从历史上看,RTOS通常支持“控制台”,即通过串行通道连接RTOS的用户界面。 这主要用于诊断和调试。 使用支持RTOS调试应用程序的现代调试器可以消除对此类对象的需求。

诊断程序


通常,RTOS需要最大的性能和最小的内存占用。 因此,完整性检查不是高优先级。 借助考虑了RTOS功能的现代调试技术,大多数检查都可以在RTOS本身之外进行。

检查API调用参数


API调用可以具有许多复杂的参数。 这可能会导致错误。 如果参数不正确,许多RTOS会通过返回错误代码来检查运行时参数。 由于这需要附加代码,并且检查本身会对性能产生不利影响,因此最好在组装或配置过程中检查参数。

堆栈检查


对于大多数类型的调度程序(“运行至完成”除外),每个任务都有其自己的堆栈,堆栈的大小是分别确定的。 在某些RTOS中,内核具有单独的堆栈;在另一些RTOS中,在API调用期间“借用”了任务堆栈。 显然,堆栈完整性对于整体系统可靠性很重要。 因此,RTOS通常提供用于在运行时检查堆栈完整性的工具。 有几种选择:

  • 一个API调用,返回当前或指定任务的堆栈空间量。
  • 堆栈的边界参数。 它们被分配一个唯一的(通常是奇数和非零)值,该值会定期检查以进行重写。


应用诊断


尽管RTOS不直接支持此功能,但是可以分配应用程序任务来检查整个系统的完整性。 这样的任务可能负责重置看门狗定时器。 一个任务可以从每个关键任务接收周期性的输入数据(例如,信号参数)。 仅在所有任务的数据到达后,才执行重置看门狗计时器(这将防止系统重新启动)。

非内核服务


到目前为止,RTOS不仅仅是我们关注的核心。 该桌面操作系统与嵌入式RTOS明显不同。 通常,在台式机操作系统中,所有其他组件都是捆绑在一起或可以安装的(所有台式机都有图形用户界面,只有少数台式机没有网络访问权限)。 台式PC没有真正的资源限制:总是有可用内存,硬盘空间和未使用的CPU资源。 在资源有限的嵌入式系统世界中,可能需要其他组件,例如视频卡,网络组件和文件系统,但是它们必须是可断开连接且可伸缩的,以最大程度地减少内存占用。

联网功能

大多数嵌入式系统都与网络相关。 因此,期望对嵌入式系统的联网解决方案有极大的兴趣,因此,市场上有大量产品。

TCP / IP是一种广泛使用的标准协议,对于许多应用程序来说是显而易见的选择。 通常,TCP / IP用于以太网协议(IEEE802.3),其平均速度为10 Mb / s。 今天,100 Mb / s相当普遍,而接近1 Gb / s。 另外,TCP / IP可以用于其他协议。 例如,PPP(点对点协议)是用于串行数据传输的TCP / IP实现,已适合宽带Internet连接。

直到最近,仍使用IP协议(IPv4)的v4版本。 但是,随着可用地址用完,它已过时。 该解决方案是IPv6,可大大增加可能的地址数量,并提供用于维护和安全性的更有效的工具。 IPv6广泛可用,并在许多国家的设备以及全世界的军事系统中使用。
另一种方法是用户数据报协议(UDP)。 该协议用于最大性能。 UDP不能提供与TCP相同的可靠性和一致性,但是它是轻量级且高效的。

USB是通用串行总线,广泛用于连接台式计算机的设备中。 它提供了一个非常易于使用的即插即用界面,可以隐藏相当复杂的软件。必须将连接到PC的嵌入式设备实现为USB功能,这需要一组特定的软件组件。如果设备必须管理通过USB连接的其他设备(例如常规PC),则需要一套主机类型的软件。

IEEE1394是另一个用于串行接口的标准,用于在设备之间快速传输大量数据(例如,用于传输视频数据),也称为FireWire和i.Link。

无线协议-消费者之间各种无线技术的便利性和普遍性导致对嵌入式设备中无线功能的高要求。 Wi-Fi(IEEE802.11标准集)提供了完整的网络功能,使您能够在足够的距离处实现对等拓扑和基础结构拓扑。在这样的网络中,对数据安全性的兴趣正在增长,这意味着这将影响软件。其他无线电技术,尤其是蓝牙和ZigBee,提供了短程点对点无线通信。

协议验证

由于对交流机会的需求很高,因此有许多供应商提供他们的解决方案。客户面临着检查可用产品质量的挑战。与RTOS内核不同,全面检查协议栈的功能和性能并非易事。幸运的是,工具包可用于检查协议(尽管价格很高),潜在的买家可以从供应商那里找到他们用来检查的设置。

图形

图形界面在嵌入式设备中变得越来越普遍。它可以是一个非常简单的小型单色LCD(例如在旧手机,MP3播放器,警报器等上)。另一方面,数字电视接收机可以具有其自己的高分辨率HDTV屏幕。这种屏幕需要完全集成到RTOS内核中的软件支持。
由于屏幕通常具有某种输入设备,因此图形包中通常包含对此类设备的支持。这样的包装可以支持定点设备(例如鼠标),触摸屏,小键盘和全键盘。
图形可以以多种方式使用。它可以简单地提供信息输出(例如,像电子记分牌一样)。或者,显示内容可以是图形用户界面以及菜单,窗口,图标和类似元素的一部分。在任何情况下,都需要一套非常特定的软件,并且RTOS随附的图形包应提供必要的灵活性,而不会显着增加所使用的内存量。

文件系统

当嵌入式应用程序需要存储和处理大量数据时,很明显将这些数据组织到某种文件系统中是有意义的。数据可以在RAM,内置闪存,USB闪存驱动器,常规硬盘或光盘(CD-ROM或DVD-ROM)中。同样,这样的机会应该将软件支持完全集成到RTOS中。必须精心设计文件系统,以满足多任务系统的可重入要求。

法规遵从性对于文件系统尤其重要。例如,使用与MS-DOS兼容的磁盘格式,开发人员可以使用完善的体系结构,并提供与台式机系统的全面数据交换。

Source: https://habr.com/ru/post/zh-CN418677/


All Articles