如何调试复杂的实时嵌入式系统

　　随着实时嵌入式系统的复杂程度不断提高，低效率的调试方法的成本日益增加。鉴于当前嵌入式应用的复杂性还有继续上升的趋势，对这些系统的调试将成为加速产品上市和提供鲁棒性最终产品的关键因素。随着应用对多线程和中断嵌套的使用，开发商的大部分时间目前都花在调试上。应用的实时属性使得将伴随同时发生多个事件的故障问题孤立起来变得更为困难。本文将讨论常见的调试问题以及预防和检查这些故障问题的一些方法。

　　从历史角度上来看，嵌入式应用代码的调试流程可以分为两类。第一类调试流程是回答 “我的代码现在执行到哪里?” 的问题。当开发商依靠打印语句或者LED的闪烁来指示应用程序执行到某个节点的调试方法时，往往就属于这种情形。如果开发工具支持这种调试方法，可以沿着应用应当程序应当执行的路径插入断点。第二类调试流程是帮助回答“我看到的这一数值是从哪里来的?”这一问题。在这种情况下，人们往往依靠寄存器显示窗口观察变量信息、处理器内存的内容。人们还可以尝试单步执行，并且观察所有这些数据窗口以了解某个寄存器状态何时出现错误，内存位置何时得到错误的数据，抑或指针何时出现了误用。

　　当开发商写完全部代码后，如果无需了解网络基础设施，也没有操作系统的任务调度需要考虑，那么就可以利用这些调试方法使一个应用程序运行起来。然而，现在的情况并非如此。嵌入式处理器以超过600 MHz的速度运行，并且拥有可支持Ethernet和USB等协议的嵌入式外设，它们支持功能齐备的操作系统，例如uClinux，而且这些操作系统所调度的各种应用程序是由数千行代码构成。使用打印语句和利用LED来调试是不现实的，因为现在常常有如此之多的功能在执行是不可能的，或者它们会影响标准I/O口，从而造成处理器性能大幅度下降。

　　也可能发生这样的情况：处理器的工作速度是如此之快，以至于LED的亮灭速度会快到人眼无法察觉。另外现代的嵌入式系统通常支持断点的设定，但是伴随这些处理器所运行的代码数量，使得这种类型的断点调试难以驾驭。中断和多线程系统在代码的任何一点上设置一个断点，可能都无法指示系统的正确状态。由于断点设置在物理内存的某个地址上，索引不必了解线程的状态。如果使用寄存器显示方法，那么局部变量窗口和内存窗口都将有助于隔离出所载入的不恰当的量值，但是，由于这些是静态化的工具，不能给出有意义的运行中的调试信息，其适用性也常常很有限。

　　实时嵌入式系统软件最常见的调试问题可以大致划分为如下几类：