使用Tracealyzer跟踪FreeRTOS内核

BMRTECH2017

本文作者是德国多特蒙德工业大学（TU Dortmund）计算机科学硕士研究生Marcel Ebbrecht。作者介绍了如何对FreeRTOS内核定时器机制进行改进，并很便利的使用了Tracealyzer 工具，帮助作者发现并修复了代码中的错误。

Marcel Ebbrecht 论文的题目是：

Bucket of Ignorance: A Hybrid Data Structure for Timing Mechanism in Real-Time Operating Systems，论文全文和代码下文链接中已提供。这篇论文适合高校教师、学生、嵌入式实时操作系统研究与开发者学习参考。

众所周知，在嵌入式系统上使用 C 或 C++ 等语言时，处理内存时必须非常小心。一方面，因为多数情况下嵌入式系统中的内存是有限的；另一方面，因为这些系统通常有很长的运行时间，所以在长期运行后，内存碎片会导致系统出现问题。

在我的硕士论文“Bucket of Ignorance ”中，我想测试一种FreeRTOS 中定时器管理的改进方法。为了保持系统确定性的定时行为，实时操作系统 (RTOS) 不仅需要任务调度程序，还需要可用于周期性任务的定时机制。大多数现有的开源 RTOS 实现了基于树或列表的机制来跟踪哪个任务已就绪。我们知道，基于树的机制在复杂搜索操作方面是高效和极时的，但在处理删除和插入操作上需花费的额外工作，这个问题不应该被忽略。即使是任务数不是很多情况下，在删除和插入操作上，基于树的计数器管理与基于列表的机制在效率上相比略显一筹，这样的结果抵消其在复杂搜索上的优势。

但是这两种机制都有一个弱点：它们会直接在正确的位置插入新元素，即使要插入的值明显高于现有元素的前半部分。

我这篇论文的核心思想是：如果要插入的元素高于使用的列表或树中的现有值，则新元素将附加到第二个未排序的列表中。随着时间的推移，排序后的列表或树将变空。发生这种情况时，未排序的列表将使用合并排序算法进行排序，并且已排序元素的前半部分将移动到列表/树中。关于这个机制的更多的信息可参考以下论文 (https://ls12-www.cs.tu-dortmund.de/daes/media ... s/ebrrechttimer.pdf)

这样的改进我在理论上进行了验证，并在模拟器中测试是成功的，现在须在一个实际系统中实现，也就是说要在一个FreeRTOS 的系统运行，验证任务应该能被动态的创建和终止。代码见(https://github.com/marcelebbrecht/rbas-node-freertos)

为了实现论文中的定时器机制，必须对FreeRTOS内核进行大量修改。不幸的是，在测试运行期间，不稳定的问题一次又一次发生。我使用的是 MCUXpresso IDE，它提供了各种调试功能，但我仍然无法找到不稳定的原因。我试图使用注册的Marcel Ebbrecht账号在官网上寻求支持，或者检索NXP LPC54018 IoT Module 这个平台，信息表明内核和各个进程的内存管理存在问题，但是IDE对于解决此类问题一筹莫展。

接下来，我继续寻找一个合适的工具，希望该工具能支持我在 FreeRTOS 运行时跟踪存储器的操作。很快，我遇到了Tracealyzer。我在几分钟内将FreeRTOS支持Tracealyzer运行的必要的几个功能函数集成到代码里面，工具链的安装以及通过 J-Link 流模式连接到开发板的过程很顺利。通过使用流模式，可以跟踪单个任务和特定内核函数的内存分配和内存共享，使用这个工具，可以很方便的找到内存错误的原因。有趣的是，Tracealyzer 不仅帮助我发现并修复了我自己代码中的错误，还帮助我发现并修复了FreeRTOS现有部分代码中的错误。虽然不使用 Tracealyzer也能完成这个工作，但它或许会花费更多的时间。