通过仪器提高固件质量 ，如何以及何时添加代码仪器

如何以及何时添加代码仪器

成功代码仪器的关键是找到适当的平衡。有必要收集足够的信息以有效，而不会显着影响性能或代码复杂性。

仪器不仅应视为调试工具，还应将仪器视为验证和优化嵌入式系统及其环境的一种手段(例如，其内置的设备)。它确保系统按预期工作。就像将测试点添加到硬件一样，仪器应嵌入固件中。项目越复杂，专注于测试的需求就越大。开发人员应确保日志捕获相关数据，例如可变值，状态和错误消息，以快速识别问题。解决症状而不了解根本原因可能导致反复出现的问题。固件模块的仪器可以是多个项目的宝贵长期投资，因为它可以加快调试和测试。

通常，代码应不迟于集成阶段的仪器，以尽早发现错误或效率低下，并减少在最后阶段的严重问题，重新设计和延迟的风险。在计划仪器时，必须确定以下内容。

1。应该仪器进行仪器的哪些部分(任务/应用程序代码，RTO，驱动程序，异常处理程序等)以及应记录哪些数据和事件?在代码部分中包括仪器可能会引起问题，因此当问题以后发生时，当我们不再使用调试探测器访问嵌入式系统时，它将存在。

2。圆形缓冲区对记录数据的大小(历史的长度取决于我们可以专用于其的内存量)?

3。应该包装数据以在相同数量的内存中获得更长或更详细的历史记录吗?

4。减少数据泛滥：实时系统生成大量数据。仅能激活那些对于特定类型的测试很重要的数据集很重要。否则，要么历史记录太短，要么由于主机带宽不足而导致数据丢失。

5。如何记录致命错误和系统异常，重置/重新启动原因以及其他与系统相关的信息?

6。应该支持哪些记录方法?流媒体模式，将数据连续传输到主机;验尸模式，数据覆盖圆形缓冲区中最古老的条目;单杆模式，缓冲区线性填充直到完整为止;还是以上所有?

7。当调试探针断开连接时，如何将记录的数据传输到主机?

8。开发人员是否应该能够通过确定捕获哪些数据以及何时捕获数据来控制数据记录?鉴于圆形缓冲区的大小有限，并且数据传输速度有限，因此使用过滤器和触发器捕获特定数据是非常有益的。

9.应该监视哪些资源(例如，内存池)?

结论

代码仪器对于复杂的嵌入式系统非常重要，应成为固件可靠性和可检验性策略设计的一部分。正确测试和有效调试的关键是可观察性，系统影响最小。仪器的目的不仅应该是查找错误，而且主要是要验证代码应尽其所能，包括实时正时约束。我们必须衡量想要改进的东西。代码质量和可靠性对于所有嵌入式系统，而不仅仅是高融合系统都很重要。由于不经常发生和缺乏历史数据，因此在测试或现场试验期间可能会随机驳斥难以释放的问题，但它们经常浮出水面，尤其是随着系统部署的增加。所以，在实验室测试期间，一旦产品进入现场，必须提供性能历史记录。

该软件生成的跟踪不需要任何特殊的硬件，可以在实验室和部署的产品中使用，例如在航空中的黑匣子。它捕获任何数据，例如本地变量，功能参数或异常转储，而硬件跟踪通常仅限于控制流和全局数据，需要高速跟踪端口和专门的调试探测器。仪器可以通过对导致断点或系统例外的历史的细粒度看待传统调试来补充传统调试。

以下文章将介绍一个新的最小侵入性和高度灵活的开源工具包，用于从资源受限到大型RTO的所有类型项目的仪器。

附录1：当前代码仪器解决方案的缺点

不同的项目有不同的仪器需求。例如，由于执行缓慢，对于一个项目而言，对另一个项目的执行缓慢可能完全适合另一个项目，而并非所有嵌入式系统都具有严重的内存限制。使用最简单的方法获得所需的测试结果很重要。随着项目变得更加复杂和实时要求，测试问题和工具要求也会增加。

这篇评论是针对对现有解决方案局限性感兴趣的人。仪器方法在功能和资源使用方面差异很大，每种方法都有不同程度的缺点。此说明适用于在将其发送到主机之前在RAM中缓冲数据的解决方案。 printf()方法很简单，但通常非诱因，缓慢且内存密集型(使用大量程序内存和堆栈空间)。即使是有限的功能版本的printf()也需要字符串和高带宽的内存，以将数据传输到主机。更好的解决方案与printf字符串记录应用程序数据，并脱机地将它们解码。但是，将字符串复制到圆形缓冲区会添加CPU开销，并消耗RAM和程序内存。单个数据记录解决方案具有或多或少的以下缺点。

•日志记录功能的缓慢执行 - 例如，日志记录一次一次处理数据8位，对于现代32位嵌入式系统而言，这很慢。

•非伦敦记录功能，无法记录多任务或中断/异常。

•阻止功能 - 例如，如果在较低的优先级功能将数据写入缓冲区时发生中断，则中断程序无法捕获数据，因为捕获被阻止，直到较低的优先级功能完成编写事件数据。

•记录RTOS事件很快，但是记录应用程序特定的事件和数据很慢，因为它依赖于printf样功能。这种方法要求将printf字符串复制到圆形缓冲区中，该缓冲区消耗了宝贵的空间，并限制了可以存储的历史数据量。

•必须手动分配特定于应用程序的事件代码。

•过度使用程序内存通常是由嵌入式系统中printf字符串的相对较大的数据记录功能和/或存储引起的。

•对于基于RTOS的应用程序，过多的堆栈使用尤其有问题。这是因为必须为调用记录功能的每个任务分配其他堆栈空间。此外，现有项目的仪器可能导致堆栈溢出。

•某些解决方案需要在数据写入圆形缓冲区期间被禁用。在受MPU保护的RTO中，任务不能禁用中断，从而使高融合应用程序不可能进行数据记录。

•数据不能导出或只能手动导出。数据解码不能轻易自定义，并且输出以多种格式分类为多种格式，以使用最合适的工具进行有效分析。更好地了解大量未排序数据需要复杂的自定义工具。

•无法记录所有类型的数据。但是，重要的是记录任何可以帮助识别或诊断问题的数据。

•使用动态分配的缓冲区和/或不一致的边界检查，这不适用于高融合系统。

•数据没有时间戳(无法定时分析)。

•缺少或有限的过滤功能：通常仅在编译时间而不是在系统操作期间进行消息过滤(如果主机的带宽不足或需要更长或更详细的历史记录)。

•所有数据都写入单个日志文件，由于数据泛滥，该文件对于手动检查变得太大。

•可移植性差(不可携带的记录库代码或缺乏对特定CPU核心或硬件的支持)，因此不能用于所有系统。

•解决方案不适合高融合项目(例如功能安全)。

•有限的范围：某些仪器解决方案可能会集中在特定方面，例如性能或调试，而无需提供系统的整体视图。

•高许可成本或将解决方案与特定的调试探针，IDE或工具链联系起来。

•具有大量数据记录功能/宏和陡峭学习曲线的复杂解决方案。