如前所述,CANopen的适应性对于满足实时应用的需求起着至关重要的作用。本系列的最后一部分将向您展示CANopen 源代码配置和优化方法的技术细节,以实现高效的实时性能。
本文将基于虹科CANopen源代码研究具体示例,以说明配置、优化和微调CANopen协议栈以满足高级时序要求和可能的系统约束的过程。
无论您是希望提高优化技能的经验丰富的CAN 系统设计师,还是希望了解实时CANopen 配置的细微差别的新手,本节旨在提供全面的见解和指导,将我们获得的理论知识转化为实际实施。
01/
不同的CANopen PDO 配置及其对响应时间的影响
CANopen PDO(过程数据对象)的配置在确定各种应用中的响应时间方面起着至关重要的作用。根据所需的响应时间和跨多个节点同步信号的必要性,可以应用不同的PDO 触发机制。
100毫秒响应时间
对于需要100 毫秒或更长响应时间的应用程序,有两种通常效果很好的配置方法(也可以组合使用):
由事件时间触发的PDO(循环传输):这里,PDO以指定的时间间隔循环传输,例如每50ms。这种周期性传输确保了一致的响应时间。
带禁止时间的状态变化(COS) 检测:此配置根据状态变化传输PDO,传输间隔时间最短(禁止时间)。该禁止时间确保切换输入不会生成连续的消息。
使用CANopen Architect 进行PDO 配置
上面的屏幕截图显示了使用100ms 事件触发和25ms 禁止时间相结合的TPDO1 设置。如果TPDO中的数据不变,则每100ms传输一次。如果确实发生更改,传输速度会更快,但永远不会快于25 毫秒。同样,TPDO2 和TPDO3 每200ms 传输一次。在状态更改(COS) 时,它们的传输会更频繁,但速度不会超过50 毫秒。
更快的响应时间或跨多个节点的同步信号
对于需要较小响应时间或需要跨多个节点同步信号的应用,SYNC 模式成为首选方法。
SYNC 模式:在此配置中,SYNC 生成器以稳定的重复间隔(例如每10 毫秒)生成SYNC CANopen 消息。该SYNC消息用作触发机制,网络中的所有设备使用该消息来同时同步应用程序数据。
高级同步:使用CANopenSYNC 模式时,您可以利用两个高级功能。首先,大多数SYNC 消费者允许使用SYNC CAN 消息标识符进行配置。因此,您可以将系统配置为使用多个SYNC 触发消息并选择哪些设备对哪个触发做出反应。其次,最新版本的CANopen 支持使用带有集成可配置计数器的SYNC。例如,您可以将其配置为计数到4。在SYNC 使用者端,您可以配置每个使用者侦听的计数值,再次提供对设备进行分组以对系统上的特定SYNC 做出反应的选项。
选择正确的PDO 配置对于实现最短响应时间至关重要。虽然循环传输和具有禁止时间的COS 检测适合更宽松的响应时间要求,但在处理更严格的时间限制或需要同步多个设备时,SYNC 模式变得至关重要。
02/
CANopen协议栈中的数据流
下图说明了CANopen系统中的数据流。在最低硬件级别,CAN 控制器将接收CAN 帧(此处通过左侧连接的收发器)。根据过滤器的不同,它们可能会被放入预先选择的缓冲区或队列中,并且将生成中断信号。实现处理CAN 控制器代码的处理器(通常是“驱动程序”)开始处理“CAN 接收中断服务”。更通用的驱动程序可以实现另一个软件队列以供以后处理。每当CANopen 协议处理代码被触发来处理接收到的消息时,它就会从驱动程序获取消息并更新对象字典。
反之亦然,应用程序可以随时更新对象字典中的某些过程数据,以便通过CANopen 进行传输。这是由CANopen 协议处理程序检测到的,如果触发条件正确,将触发传输PDO 并将其传递给驱动程序,驱动程序会将其放置在适当的传输缓冲区或队列中。
CAN设备中的数据流
请注意,通常这不是单个连续的代码流。 CAN 接收通常在中断级处理,而CANopen 协议栈处理则不然。
为了保持CANopen协议栈活跃,通常需要频繁调用协议栈函数,(例如,在“main while(1)”后台循环中)。此类函数通常首先检查是否已接收到CANopen 报文;如果是,则对其进行处理。如果数据涉及更新过程数据,通常有一个回调函数来通知应用程序新的过程数据已经到达。
处理完所有收到的CANopen 消息后,此函数检查是否有任何内容要传输。它可以检测到传出过程数据已被应用程序修改,并根据定时器配置和传输模式启动相应CANopen 消息的传输。
此类传输通常会传递到驱动程序级别,可能会传递到传输队列中,并且此CANopen 消息何时传递到CAN 控制器进行传输取决于驱动程序配置。
基本配置和控制选项
除非所需的处理和响应时间小于100毫秒,否则这样的数据流对于大多数应用程序来说已经足够了。如果所需的响应时间变短,您应该开始考虑可能的优化。查看上面的通用数据流时,可能的优化包括:
针对接收CAN 驱动程序进行优化:芯片制造商(甚至CANopen 堆栈提供商)提供的许多默认驱动程序可能无法充分利用CAN 控制器的特定功能。第一个可能的优化检查之一是确保尽可能利用硬件接收过滤和硬件接收缓冲区或队列,从而消除对长延迟软件接收队列的需要。
针对传输的CAN 驱动程序优化:在优化之前,请考虑设备是否能够连续传输尽可能多的CAN 帧,或者是否应该对传输进行某种程度的节流,以确保没有单个设备可能会产生太长的高优先级后台时间。来回流量。如果应该限制,请考虑实施基于计时器的传输触发。例如,如果需要每毫秒传输一个CAN帧,我们可以使用1ms定时器中断来完成此操作,并通过相应的Check函数检查传输队列中是否有任何内容。如果是这样,则在此调用周期内仅将一个消息帧传送到发送缓冲区,从而将发送频率限制为每毫秒最多一次。如果需要更快的吞吐量,可以使用更快的中断,或者可以考虑使用前面提到的协议栈处理函数‘Process()’方法。
协议栈处理功能
关于协议栈处理的一个典型问题是应该多久调用一次以及最坏情况下的执行时间是多少。有些人喜欢从固定定时器中断而不是后台循环中调用它。这些问题没有普遍的答案。常见做法是:
while (进程());
这将不断重新调用该函数,直到执行完所有挂起的CANopen 任务。
直接任务触发
堆栈处理函数主要适用于那些不想了解从内部执行的所有CANopen 任务的详细信息的人。当然,为了进一步优化,我们还可以直接实现更具体的协议栈功能,比如RxPDO和TxPDO,或者基于毫秒定时器的定时触发功能,这样可以更准确地调整性能和响应能力。
03/
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 及其配置的细节,说明了满足不同应用需求所需的微妙选择。
优化选择
也许最深刻的见解之一是认识到优化并不是一种万能的方法。根据所需的响应时间,一些优化变得至关重要,而另一些则可以绕过。这是一个微调的问题,了解需要利用什么以及可以在不影响性能的情况下保持不变。
战略无知
与利用一切可能的优势的本能相反,在某些情况下,时间框架允许故意忽略某些优化。并非网络控制器提供的每个寄存器都需要使用;它是性能和特定应用程序的需求之间的平衡。
鸿科是一家在工业自动化领域,特别是工业总线通讯行业拥有超过15年经验的高科技公司。在CAN、CAN FD、CANopen通讯领域,鸿科可提供CAN卡、中继器、路由器、总线记录仪等。网关、IO模块、热电偶模块、芯片及软件等一站式解决方案。欢迎联系鸿科了解更多信息!