rtos安装需求（几种基于RTOS的实用工具）

rtos安装需求（几种基于RTOS的实用工具）▪ 动态内存/外设访问（读写）ARM Cortex-M内核配备了强大的调试硬件。CoreSight提供了非侵入性的功能，允许工具在不停止CPU的情况下监视和控制实时系统，例如：大多数商业RTOS都是抢占式调度方式，内核总是运行就绪的最重要的任务。抢占式内核也是事件驱动的，任务被设计为等待事件发生后才能执行。如果任务等待的事件没有发生，内核将运行其它任务。等待状态的任务不消耗CPU时间。通过内核API调用来完成事件的发生和等待操作，避免轮询操作，提高CPU时间的利用率。典型的任务实现示例，如下所示：实时内核提供了许多服务，如多任务处理、中断管理、任务间通信与同步、资源管理、时间管理、内存分区管理等。RTOS可以用于少量任务的简单应用，在需要复杂和耗时的通信的应用中，如TCP/IP、USB（主机和/或设备）、CAN、蓝牙、Zigbee应用等，RTOS是一个必备工具。当应用程序需要文件系统来存储

越来越多的嵌入式系统依赖于实时操作系统(RTOS)的使用，以满足实时需求，减少上市时间，简化开发，增加代码可移植性。尽管RTOS有许多好处，但它也有其缺点，如可能引入分配不当的任务优先级、堆栈溢出、饥饿、死锁、优先级反转等bug。

一些专门设计的工具，可以帮助基于RTOS的程序开发人员发现一些难以发现的错误。

RTOS是什么？

实时操作系统(RTOS或实时内核)是有效地管理CPU时间的软件。大多数内核使用C编写，仅需汇编语言编写小部分代码，使内核适配不同的CPU体系结构。在使用RTOS内核设计应用程序时，只需将工作分成任务，每个任务负责工作的一部分。任务（也称为线程）是一个简单的程序，认为自己完全拥有CPU。在单核CPU上，在任何给定时间内只能执行一个任务。应用代码还需要根据任务重要性为每个任务分配优先级以及任务堆栈(RAM)。一般来说，增加低优先级任务不会影响系统对高优先级任务的响应。任务实现通常是一个无限循环，内核负责任务的管理，称为多任务处理。多任务处理是在几个顺序任务之间调度和切换CPU的过程。多任务处理提供了具有多个CPU的错觉，最大化地使用CPU，如图1所示。多任务处理还有助于创建模块化的应用程序。使用实时内核后，应用程序更容易设计和维护。

大多数商业RTOS都是抢占式调度方式，内核总是运行就绪的最重要的任务。抢占式内核也是事件驱动的，任务被设计为等待事件发生后才能执行。如果任务等待的事件没有发生，内核将运行其它任务。等待状态的任务不消耗CPU时间。通过内核API调用来完成事件的发生和等待操作，避免轮询操作，提高CPU时间的利用率。典型的任务实现示例，如下所示：

实时内核提供了许多服务，如多任务处理、中断管理、任务间通信与同步、资源管理、时间管理、内存分区管理等。RTOS可以用于少量任务的简单应用，在需要复杂和耗时的通信的应用中，如TCP/IP、USB（主机和/或设备）、CAN、蓝牙、Zigbee应用等，RTOS是一个必备工具。当应用程序需要文件系统来存储和检索数据，以及当产品配备了图形显示（黑白、灰度或彩色）时，也强烈推荐使用RTOS。

硬件调试端口

ARM Cortex-M内核配备了强大的调试硬件。CoreSight提供了非侵入性的功能，允许工具在不停止CPU的情况下监视和控制实时系统，例如：

▪ 动态内存/外设访问（读写）

▪ 指令跟踪(芯片需包括一个执行跟踪宏单元，ETM)

▪ 数据跟踪

下图显示了Core Sight调试端口、CPU和内存外设之间的关系简化框图。

系统测试/调试工具

下图显示了CoreSight如何连接到开发环境：

1、嵌入式开发通常使用集成开发环境(IDE)，IDE中通常包含代码编辑器、编译器、汇编器、链接器、调试器等工具。

IDE内置的调试器只提供了最基本的功能：下载代码、启动/停止应用、设置断点等功能。一些调试器允许在目标运行时显示和更改变量(如Live Watch)，但这些功能仅限于数值。许多调试器内置RTOS插件，但通常需要停止应用程序才能检查RTOS的状态（对于调试实时系统不太实用）。

2、通过调试器，例如Segger J-Link，将代码下载到目标系统。

3、J-Link连接到CoreSight调试端口，启动/停止CPU，下载代码，编程板载Flash等。即使目标系统正在执行代码，J-Link也可以读写内存。

4、Micrium的μC/Probe是一个独立的、与CPU无关的Windows应用程序，它读取工具链生成的ELF文件。ELF文件包含下载到目标系统的代码以及所有全局变量的名称、数据类型和内存位置。

5、μC/Probe允许用户在运行时显示或更改连接的嵌入式目标上的变量或内存位置(包括I/O端口)的值。用户只需在μC/Probe图形环境填充量规、数字指示器、表格、图表、虚拟LED、条形图、滑块、开关、按钮等控件，并将控件与嵌入设备中的变量或内存位置相关联，即可在运行时显示或更改变量。通过μC/Probe图形界面中添加的虚拟滑块或开关，你可以轻松地更改运行系统的参数（如过滤系数和PID回路增益）或启动设备并测试I/O端口。

6、μC/Probe向J-Link发送读取或写入内存的请求。

7、J-Link请求将转换为CoreSight命令，获取变量值并显示到μC/Probe图形界面。

8、测试/调试实时嵌入式系统的另一个非常有用的工具是SEGGER的SystemView。此工具通常与RTOS一起工作，按时间顺序显示任务和ISR的执行，可以查看每个任务需要执行的时间（最小/平均/最大），任务何时就绪，每个任务实际开始执行时间，ISR何时执行等。SystemView可以帮助你发现不易发现的错误。但SystemView需要向目标系统添加记录RTOS事件和ISR的驻留代码(由SEGGER免费提供)，SystemView还会消耗少量的RAM来缓存这些事件。

9、J-Link允许多个进程同时访问CoreSight，因此你可以同时使用这三个工具。

基于RTOS应用中的问题

堆栈溢出

在基于实时内核的应用中，每个任务都需要自己的堆栈。任务所需堆栈的大小取决于应用程序。如果堆栈大于任务要求，则会浪费内存。如果堆栈太小，堆栈可能溢出。我们可以通过分配更多内存来减少堆栈溢出的机会，通常需要25-50%的额外堆栈空间。一些CPU，比如基于ARMv8M架构的CPU，内置了堆栈溢出检测机制。然而，该特性并不能帮助确定合适的堆栈大小，它只是防止堆栈溢出的负面后果。

堆栈分配时，首先为任务堆栈分配更多空间，然后在已知最坏情况下运行应用程序，监视实际堆栈使用情况。

下图显示了μC/Probe对测试应用程序的μ/OS-III内核感知的截图。Stack Usage列显示每个任务在给定时间的最大堆栈使用情况。μC/Probe将更新并实时显示堆栈使用信息，无需停止目标应用。绿色表示最大堆栈使用量一直保持在70%。黄色表示堆栈使用量在70%到90%之间。红色表示堆栈使用量已超过90%。显然，使用92%堆栈的任务应该增大堆栈，使其回到70%以下。

中断响应

在临界代码处理时，RTOS和应用程序代码通常必须禁用中断。关中断会影响系统对事件的响应，RTOS应用中尽量减少中断禁用时间。

μC/OS-III会监测每个任务最坏情况下的中断禁用时间，下图所示。如果应用需要满足实时截止时间，这些信息非常有用。

中断被禁用的时间很大程度上取决于CPU、其时钟速率、应用程序和调用的RTOS服务。禁用中断最长的任务用红色高亮显示，帮助用户快速识别潜在的异常值。

如果最大中断禁用时间是由RTOS引起的，可以：

查找并使用中断禁用时间较低的RTOS API。

增加CPU的时钟速率。

使用非内核感知中断来处理高度时间敏感的代码。

优先级反转

优先级反转发生在低优先级任务持有高优先级任务需要的资源时。当中等优先级的任务抢占占用资源的低优先级的任务时，问题就会加剧。“优先级反转”一词指的是，低优先级任务似乎比高优先级任务具有更高的优先权，至少在共享该资源时是如此。

优先级反转是实时系统中的一个问题，当使用基于优先级的抢占式内核时会发生。如下图所示，SystemView展示了一个优先级反转场景。

App HPT具有最高优先级，App MPT 具有中优先级，App LPT优先级最低。

可以使用RTOS的互斥量机制来解决上面描述的优先级反转问题。优先级反转被限定为LPT访问共享资源所需的时间，下图所示。LPT和HPT都使用互斥量而非信号量来获得对共享资源的访问权。如果没有SystemView这样的工具，优先级反转将很难识别和校正。

注意，如果LPT只是HPT的下一个优先级级别，则可以使用信号量。在这种情况下，RTOS不需要更改LPT的优先级，信号量是首选项，它比互斥信号量快。

死锁

死锁是至少两个任务相互等待另一个任务拥有的资源。死锁可能不会立即发生，它很大程度上取决于两个任务何时需要彼此的资源。如图8所示，μC/Probe的内核感知视图有一列，显示每个任务的执行频率（RTOS切换任务的频率）。通过监视此列可以检测死锁。如果至少两个任务的计数已停止（μC/Prboe在CPU运行时更新这些计数器），则可能存在死锁。对于这种情况，不需要使用μC/Probe等工具也可以判定锁定行为，该工具使它更加明显。

可以通过以下方法来避免死锁：

1、任务先获取所有必需的资源，以相同的顺序获取它们，以相反的顺序释放它们。

2、在RTOS API调用中使用超时机制，以避免永远等待资源可用。检查RTOS API返回的错误代码，以确保对所需资源的请求成功。

任务饥饿

饥饿指高优先级任务消耗了所有CPU带宽，低优先级任务没有CPU时间或很少。饥饿的影响是响应性和产品特性的下降，例如嵌入式目标的显示更新缓慢、通信堆栈中的数据包丢失、操作界面响应迟缓等。为解决饥饿问题，可以：

1、优化消耗大多数CPU带宽的代码。

2、提高CPU的时钟速度。

总结

IDE内置的调试器通常不足以调试基于RTOS的实时系统。

幸运的是，有专门为调试基于RTOS的系统而设计的工具。其中一个工具是Segger的SystemView，它会按时间顺序显示ISR和任务的执行，收集运行时统计数据，如最小和最大执行时间、ISR与任务之间的关系、CPU负载等。

另一个可以补充SystemView的工具是Micrium的μC/Probe，这是一个通用工具，它允许开发人员在不干扰CPU的情况下，可视化和改变正在运行的嵌入式目标的行为。μC/Probe可以用于裸机或基于RTOS的应用中。对于基于RTOS的应用程序，μC/Probe包括非侵入性的、实时内核感知以及TCP/IP协议栈感知功能。SystemView和μC/Probe可以在整个开发周期中使用，提供关于嵌入式目标的运行时行为的反馈。

免责声明：本文素材来源网络，版权归原作者所有。如涉及作品版权问题，请与我联系删除。