网站建设专业公司哪家好,北京网站制作公司清远,黑马程序员教程,深圳专业做网站电话正如前文所述#xff0c;CANopen的适应性在满足实时应用需求方面发挥着至关重要的作用。本系列文章的最后一部分将向您展示 CANopen 源代码配置的技术细节#xff0c;以及实现高效实时性能的优化方法。
前文回顾#xff1a; 虹科分享 | 平衡速度和优先级#xff1a;为多样…正如前文所述CANopen的适应性在满足实时应用需求方面发挥着至关重要的作用。本系列文章的最后一部分将向您展示 CANopen 源代码配置的技术细节以及实现高效实时性能的优化方法。
前文回顾 虹科分享 | 平衡速度和优先级为多样化的实时需求打造嵌入式网络(1)——选择正确的实时范围 虹科分享 | 平衡速度和优先级为多样化的实时需求打造嵌入式网络(2)——实时通信系统的需求 虹科分享 | 平衡速度与优先级为多样化的实时需求打造嵌入式网络3——CAN与CANopen的实时能力与局限性
本文将基于虹科CANopen源码来研究具体示例从而阐明配置、优化和微调CANopen协议栈的过程以满足高级时间要求和可能的系统约束。
无论您是经验丰富希望提高优化技能的CAN系统设计人员还是希望了解实时CANopen 配置的细微差别的新手本部分都旨在提供全面的见解和指导将我们获得的理论知识转化为实际实施。
1. 不同的CANopen PDO配置及其对响应时间的影响
CANopen PDO过程数据对象的配置在确定各种应用中的响应时间方面起着至关重要的作用。根据所需的响应时间和跨多个节点同步信号的必要性可以应用不同的PDO触发机制。
1100ms响应时间
对于所需响应时间为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及其配置的细节说明了满足不同应用需求所需的细微选择。优化选择也许最深刻的见解之一是认识到优化并不是一种万能的方法。根据所需的响应时间某些优化变得至关重要而其他优化则可以绕过。这是一个微调的问题了解哪些内容需要利用哪些内容可以在不影响性能的情况下保持不变。战略无知与利用一切可能的优势的本能相反在某些情况下时间框架允许故意忽略某些优化。并非网络控制器提供的每个寄存器都需要被利用这是性能和特定应用程序的需求之间的平衡。
