虹科分享 | 平衡速度和优先级：为多样化的实时需求打造嵌入式网络(4)——从理论到实践：CANopen源代码配置

正如前文所述，CANopen的适应性在满足实时应用需求方面发挥着至关重要的作用。本系列文章的最后一部分将向您展示 CANopen 源代码配置的技术细节，以及实现高效实时性能的优化方法。

前文回顾：
虹科分享 | 平衡速度和优先级：为多样化的实时需求打造嵌入式网络(1)——选择正确的实时范围
虹科分享 | 平衡速度和优先级：为多样化的实时需求打造嵌入式网络(2)——实时通信系统的需求
虹科分享 | 平衡速度与优先级：为多样化的实时需求打造嵌入式网络（3）——CAN与CANopen的实时能力与局限性

本文将基于虹科CANopen源码来研究具体示例，从而阐明配置、优化和微调CANopen协议栈的过程，以满足高级时间要求和可能的系统约束。

无论您是经验丰富希望提高优化技能的CAN系统设计人员，还是希望了解实时CANopen 配置的细微差别的新手，本部分都旨在提供全面的见解和指导，将我们获得的理论知识转化为实际实施。

1. 不同的CANopen PDO配置及其对响应时间的影响

CANopen PDO（过程数据对象）的配置在确定各种应用中的响应时间方面起着至关重要的作用。根据所需的响应时间和跨多个节点同步信号的必要性，可以应用不同的PDO触发机制。

1）100ms响应时间

对于所需响应时间为100毫秒或更长的应用，通常有两种运行良好的配置方法（也可以组合使用）：

• PDO按事件时间触发（循环传输）：这里，PDO以指定的时间间隔循环传输，例如每50ms。这种周期性传输确保了一致的响应时间。
• 带禁止时间的状态变化(COS)检测：此配置根据状态变化传输PDO，传输之间具有最短时间（禁止时间）。该禁止时间确保切换输入不会产生back-to-back消息。
  

2）更短的响应时间或跨多个节点的同步信号

对于需要较小响应时间或需要跨多个节点同步信号的应用，SYNC 模式成为首选方法。

SYNC模式：在此配置中，一个SYNC生成器以稳定的重复间隔（例如每10毫秒）生成SYNC CANopen消息。此SYNC消息用作触发机制，网络中的所有设备使用它来同时同步应用数据。

高级SYNC：使用CANopen SYNC模式时，您可以利用两个高级功能。首先，大多数SYNC消费者允许使用SYNC CAN消息标识符的配置。因此，您可以将系统配置为使用多个SYNC触发消息，并选择哪些设备对哪个触发做出反应。其次，最新版本的CANopen支持使用带有集成可配置计数器的SYNC。例如，可以将其配置为计数到4。在SYNC使用者端，您可以配置每个使用者侦听的计数值，再次提供对设备进行分组以对系统上的特定SYNC做出反应的选项。

选择正确的PDO配置对于实现最短的响应时间至关重要。虽然循环传输和具有禁止时间的COS检测适用于更宽松的响应时间要求，但在处理更严格的时间限制或需要同步多个设备时，SYNC模式变得至关重要。

2. CANopen协议栈中的数据流

下图说明了CANopen系统中的数据流。在最低硬件级别，CAN控制器将接收CAN帧（此处通过连接的收发器从左开始）。根据过滤器的不同，它们可能会被放入预先选择的缓冲区或队列中，并且将生成中断信号。实现处理CAN控制器代码的处理器（通常是“驱动程序”）开始处理“CAN接收中断服务”。更通用的驱动程序可以实现另一个软件队列以供以后处理。每当CANopen协议处理代码被触发处理接收到的消息时，它就会从驱动程序获取消息并更新对象字典。

反之亦然，应用程序可能随时更新对象字典中的一些过程数据以通过CANopen传输。这是由CANopen协议处理程序检测到的，如果触发条件正确，将触发传输PDO并传递给驱动程序，驱动程序会将其放置在适当的传输缓冲区或队列中。

请注意：通常这不是单个连续的代码流。CAN接收通常在中断级别进行处理，而CANopen协议栈处理则不然。

为了保持CANopen协议栈处于活动状态，通常需要频繁调用协议栈函数，（例如在“main while(1)”后台循环中）。该类函数通常会首先检查是否接收到 CANopen消息；如果是，则对其进行处理。如果数据涉及更新过程数据，则通常有一个回调函数来通知应用程序新的过程数据已到达。

当处理完所有接收到的CANopen消息后，该函数会检查是否有任何内容需要传输。它可以检测到传出的过程数据被应用程序修改，并根据定时器的配置和传输模式，启动相应的CANopen消息的传输。

此类传输通常会传递到驱动程序级别，可能会传递到传输队列中，并且具体何时将此CANopen消息传递到CAN控制器进行传输取决于驱动程序配置。

1）基本配置和控制选项

除非所需的处理和响应时间小于100毫秒，否则这样的数据流对于大多数应用程序来说已经足够好了。如果所需的响应时间变短，您应该开始考虑可能的优化。在查看上面的通用数据流时，可能的优化包括：

• 针对接收的CAN驱动程序优化：芯片制造商（甚至CANopen协议栈提供商）提供的许多默认驱动程序可能无法充分利用CAN控制器的特定功能。第一个可能的优化检查之一是确保在可能的情况下利用硬件接收过滤和硬件接收缓冲区或队列，从而消除对长延迟软件接收队列的需要。
• 针对传输的CAN驱动程序优化：在优化之前，请考虑该设备是否可以连续传输尽可能多的CAN帧，或者是否应该对传输进行某种程度的节流以确保没有任何单个设备可能会产生太长时间的高优先级back-to-back流量。如果应该对其进行限制，请考虑实施基于计时器的传输触发，例如需要每毫秒传输一个CAN帧，则我们可以使用1ms定时器中断来执行此操作，通过相应Check函数检查传输队列中是否有内容。如果是，则在此调用周期中仅将一个报文帧传递到传输缓冲区，从而将传输频率限制为每毫秒最多一次。如果需要更快的吞吐量，则可以使用更快的中断，或可以考虑使用前文提到的协议栈处理函数"Process()"的方法。

2）协议处理函数

有关协议栈处理的一个典型问题是，应该多长时间调用一次，最坏情况下的执行时间是多少。有些人喜欢从固定的定时器中断而不是后台循环中调用它。这些问题没有通用的答案。常见做法是：

while (Process());

这将不断重新调用该函数，直到所有待处理的CANopen任务都已执行完毕。

3）直接任务触发

协议栈处理函数主要是为那些不想深入了解从内部执行的所有CANopen任务的详细信息的人提供服务。当然为了进一步优化，我们也可以直接实现更具体的协议栈功能函数，比如RxPDO和TxPDO，或者是基于毫秒计时器实现的计时触发函数等，从而可以更精确地调整性能和响应能力。

3. CAN驱动程序、CANopen协议栈和应用

在大多数基于32位的微控制器上，到目前为止讨论的增强功能适合将总响应时间降低到10毫秒到“几毫秒”的范围。这可以在不需要优化的情况下实现，而优化可能会导致完全自定义的实现，而这种实现可能难以维护。这些优化仅限于在需要时利用单独触发的CANopen堆栈进程。
一般来说，这可以进一步进行。然而，在系统的这种内在级别上进行更改可能会使维护或在必要时移植到不同的体系结构变得更具挑战性。因此，以下内容更多的是说明“理论上可能的情况”，将优化推向超出系统易于测试、维护和移植的范围。

在最低硬件级别，检查您的CAN控制器是否配置为通过接收SYNC消息直接创建CAN接收中断，以及您是否可以轻松检测到与任何其他CANopen消息（例如自己的过滤器/接收缓冲区）的差异。

为了进一步提高实时性，唯一合理的CANopen PDO通信模式是CANopen SYNC模式。如果使用它并且我们集中精力优化它，那么之前的其他优化可能会变得多余。

专注于SYNC优化需要我们修改CAN接收中断服务例程，以便在收到SYNC信号时直接调用负责SYNC处理的CANopen堆栈函数。当从中断服务程序中执行此操作时，请记住：

• 不要将此SYNC存储在常规接收队列中（我们已经处理过它）。
• 对于SYNC相关的发送和接收数据，将调用应用程序的回调函数——仍然在中断服务级别执行。
• 当使用RTOS时，更好的解决方案是在收到SYNC的中断中设置触发信号，随后在中断完成后立即触发执行任务。

通过这样的修改，可以实现毫秒内的响应时间。如果参与SYNC通信的所有设备都以相同的优化来实现SYNC处理，则设备之间的变化（例如，当它们各自同步应用其输出时）可以低至几微秒。

然而，这些都是在测试和实验室环境中观察到的极端值。对于要求如此短响应或同步时间的实际应用程序，需要仔细测试以确保在所有实际情况下都能达到这些目标。

全文总结：通过战略选择来应对复杂性

• 硬件选择：所需的响应时间决定了所需的硬件功能，影响对模块、可能是微控制器和其他重要组件的决策。
• 操作系统注意事项：无论是使用 RTOS还是实现更具体的定制系统，响应时间都会严重影响操作系统的配置方式。
• 网络技术：根据所需的吞吐量和速度，必须考虑不同的网络协议和技术。作为一个例子，本系列研究了CANopen及其配置的细节，说明了满足不同应用需求所需的细微选择。
• 优化选择：也许最深刻的见解之一是认识到优化并不是一种万能的方法。根据所需的响应时间，某些优化变得至关重要，而其他优化则可以绕过。这是一个微调的问题，了解哪些内容需要利用，哪些内容可以在不影响性能的情况下保持不变。
• 战略无知：与利用一切可能的优势的本能相反，在某些情况下，时间框架允许故意忽略某些优化。并非网络控制器提供的每个寄存器都需要被利用；这是性能和特定应用程序的需求之间的平衡。