社论
成员自2015年以来
KINGSTAR Soft Motion在自动配置的EtherCAT环境中提供运动控制软件解决方案的所有优点，具有“即插即用”兼容性。凭借预集成和预测试的运动库的最高质量和性能，KINGSTAR以传统硬件平台一半的成本提供运动控制。KINGSTAR Soft Motion是一个开放的、基于标准的、纯软件的解决方案，简化了电机控制和自动化。Soft Motion直接在PC上运行，使用NIC卡进行I/O，并使用强大的EtherCAT协议将您从专有和昂贵的硬件桎梏中解放出来。通过Soft Motion，运动控制工程师可以在一个“即插即用”的环境中设计、开发和集成基于pc的机器控制器，以实现统一的、廉价的、可扩展的运动和视觉控制。
下内容提交:
工业:
航空航天和汽车航空航天，汽车，汽车，消费品/家电，军事/国防，半导体
应用程序:
电弧焊，装配，装配电弧焊，组装，组装，自动涂胶，点焊
查看更多
使用traceanalyzer进行性能分析
发布02/07/2017
| By: Terri Hawker, Vice President Product Management
在使用实时操作系统(RTOS)开发固件时，您如何衡量软件性能?性能分析的一个重要方面是响应时间，即代码中从A点到B点的时间，例如，从任务被激活到任务完成。这可以通过许多方法来测量，例如，通过切换I/O引脚并用逻辑分析仪进行测量，或者通过添加一些额外的代码来测量两点之间的时钟周期数。但是基本的测量方法只是测量这些点之间的处理器时间总量，而没有任何相关因素的信息，比如中断例程或其他由于抢占式调度而产生干扰的任务(参见RTOS 101:任务调度和Tracealyzer分析)。
性能分析的另一个重要性能方面是执行时间，即特定代码段使用的实际处理器时间。您可以使用对程序计数器进行抽样的解决方案，并提供使用最多处理器时间的解决方案的高级概述。这得到了一些通用ide的支持，并且大多数基于arm的mcu都为此提供了硬件支持。然而，这是典型分布的平均测量，对于不太频繁的功能或任务是不准确的。此外，这并没有揭示可能导致超时等问题的异常长执行的零星情况。
为了获得RTOS行为的确切图像，您需要一个RTOS跟踪的解决方案。用于此目的的工具已经存在多年了，但只适用于某些操作系统，而且每种工具通常只支持特定的操作系统。它们通常会显示一个水平甘特图，显示任务随时间的执行情况。然而，这对于RTOS跟踪并不理想，因为很难同时显示其他事件，比如RTOS API调用。
IntervalZero的RTOS(实时操作系统)平台是一个标准的预集成应用程序开发平台，允许公司专注于交付增值应用程序。IntervalZero的RTX和RTX64软件取代了fpga和dsp来满足硬实时需求，从根本上降低了开发成本，并显著提高了嵌入式系统的质量。
Tracealyzer可用于IntervalZero的RTX64 3.0产品，并提供了复杂的可视化，使其更容易理解跟踪。
TaceAlyzer（图1）的主视图使用垂直时间线，允许不仅显示RTOS调度和中断，还可以使用水平文本标签等其他事件，例如RTOS调用或自定义“用户事件”。这些标签“浮动”并均匀地展开以避免重叠。调度跟踪中的矩形对应于不间断执行的间隔。这些被称为“碎片”在TaceAlyzer中。术语“Actor”用于表示跟踪系统中的所有执行上下文，例如任务和中断处理程序。任务调度可以以不同的方式呈现，或“查看模式”，其中包含在缩放按钮下找到的关联按钮。在此模式下，片段在多个列中排序，每个actor一个。
Tracealyzer有一个在其他RTOS跟踪工具中找不到的“实例”概念，这意味着Actor的特定执行，也就是说，从“job”被触发到它完成。实例概念在Tracealyzer中非常重要，因为它既用于跟踪可视化，也用于提供计时统计信息。在Tracealyzer主视图中单击actor片段时，actor实例会用蓝色矩形突出显示，如图1所示。
此外，为每个实例计算诸如执行时间和响应时间的性能度量，并且可以被视为显示随时间变化的详细图（上面的图2）和显示分布的直方图。后者如图3（下面）所示，我们可以看到“控制任务”的最高响应时间在这条轨迹中为3255，而最高执行时间仅为1087，这意味着大多数响应时间到期从其他任务或中断干扰。
Tracealyzer中的所有视图都是相互关联的，因此通过单击绘制的数据点或直方图条，您可以在主跟踪视图中找到相应的位置，并可以看到统计数据背后的详细RTOS行为。
很好，但是任务调度事件流如何分组到任务实例中呢?对于循环的RTOS任务来说，这并不明显，因为一个实例对应于主循环的迭代，由一个阻塞的RTOS调用分隔，例如，在循环中的某个地方的“QueueRecieve”或“DelayUntil”。但是一个任务可能执行多个这样的调用，那么Tracealyzer知道在哪里结束当前实例并开始一个新实例吗?
为此目的，Tracealyzer有一个“实例完成事件”的概念，它以两种方式定义。在大多数情况下，用户不需要为此烦恼，因为有一组标准规则指定哪些RTOS调用通常应该被计算为IFEs，比如Delay调用和QueueRecieve调用。这不需要额外的配置，而且通常是正确的。但是，对于不适合这些隐式规则的情况，可以通过调用记录库中的某个函数来生成显式事件(IFEs)，将实例标记为已完成。如图4所示，其中深绿色的控制任务被划分为多个实例，尽管在这些点上没有发生任务切换。通过这种方式，您可以手动决定如何将事件分组到实例中，从而控制计时统计的含义。
使用TraCeAlyzer，您可以获得一个精湛的解决方案，用于验证基于RTOS的嵌入式软件的性能分析，调试和验证。您可以确切地图示RTOS如何执行应用程序，包括许多性能统计信息，例如任务的执行时间和响应时间。并且您还会获得详细的跟踪视图，该视图解释了影响时间的时间。这为运行时的世界提供了宝贵的洞察力，促进了基于RTOS的嵌入式软件的开发，验证和调试。TraCeAlyzer还可用于分析Linux系统。
我们在开发中有几个新的、令人兴奋的分析特性，允许更好的性能分析，所以请继续关注!