工具/软件:TI C/C++编译器
大家好、
我 对 CAN 通信有疑问。 我有两个具有 TM4C123AE6PM 的电路板、其中 PA0和 PA1用于 CAN 并连接到 CAN 收发器、我 已在一个方向上设置通信。 现在、我希望板2也将信息发送回板1。 我是否能够通过创建另一个消息对象(tCANMsgObject)(类型为 MSG_OBJ_TYPE_TX)并让电路板将其发回来实现此目的? 和电路板1中的中断、按 ID 检查消息对象? 这是正确的、还是我遇到了问题?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:TI C/C++编译器
大家好、
我 对 CAN 通信有疑问。 我有两个具有 TM4C123AE6PM 的电路板、其中 PA0和 PA1用于 CAN 并连接到 CAN 收发器、我 已在一个方向上设置通信。 现在、我希望板2也将信息发送回板1。 我是否能够通过创建另一个消息对象(tCANMsgObject)(类型为 MSG_OBJ_TYPE_TX)并让电路板将其发回来实现此目的? 和电路板1中的中断、按 ID 检查消息对象? 这是正确的、还是我遇到了问题?
[引用 user="Djedjica">我 对 CAN 通信有疑问。 我有两个具有 TM4C123AE6PM 的电路板 、其中 PA0和 PA1用于 CAN 并连接到 CAN 收发器、我 已在一个方向上设置通信。 现在、我希望板2也将信息发送回板1。 我是否能够通过创建另一个消息对象(tCANMsgObject)(类型 为 MSG_OBJ_TYPE_TX)并让电路板将其发回来实现此目的?[/引用]
是的。 不过、请确保仲裁值(通常称为 ID)不同。
虽然我有一种感觉、但你可能会抓住斗杆的错误端。 尽管您可以将 CAN 设置为回复/响应、但在这样做时、您会错过它的大部分实用程序。
从根本上说、CAN 是一个控制网络。 尽管有几个 HLP (高级协议)会将其插入 ISO 网络堆栈模型、但它并不能完全适合 ISO 网络堆栈模型。
与 CAN 基本性质的相似之处是发布/订阅或反射性存储器。 其理念是每个节点发送信息/命令、而其他节点仅"监听"它们所关注的那些节点。 例如、您可以使用电机控制设置、其中有两个通过单独的 HMI 和互锁控制器的速度控制来控制的机械连接电机。
很明显、这是一个简化的演示、但认为它可以为您提供想法。 请注意、这些都不涉及查询/响应设置。 您可以通过 RMA (Rate Monotonic Analysis、不要让名称吓到您、它真的很简单)来设置这些消息的时间表、并确保您不会使网络过载。 完成设置工作后、您最终会得到一个相当容易扩展和性能良好的东西。
Robert
[报价用户="Djedjica"]我想设置它,就像一个芯片出现故障一样,而这个监听系统可以发送给控制器以重置某些外设。
这是一种答复/答复不是最好的形式的情况。 这是一种非常适合的方法。
您真正需要的是一组看门狗信号。 每个板发送一条持续的看门狗消息。 如果不是定期收到该消息、则接收方会知道出现了错误、并可能尝试恢复或关闭消息。 请注意、这还捕获查询响应不会发生的网络故障。
您可以按类似的格式设置每封邮件
如果接收到的消息的计数在30mS 内没有变化、您可能会每10ms 发送一次这些消息并声明故障。 您的时间会因系统而异。
[引用 user="Djedjica">但我们需要在多个节点之间进行查询/响应通信,因此我认为应该使用其他通信。 [/报价]
您不理解。 问题不是查询/响应不能与 CAN 一起使用、而 是不应将查询/响应用于控制协议。 您的故障响应是控制消息的一个示例。 您确实需要对检索故障历史记录或详细信息等项目进行查询/响应、您可以在 CAN 上执行此操作。 只是不要构建查询/响应协议、然后使用它进行常规控制、基本 CAN 协议更适合这种情况。
Robert
正如承诺的那样、书架有几个参考
首先 、请访问 https://www.kvaser.com/can-protocol-tutorial/ 、了解 CAN 的一般性介绍。
[引用 user="CAN-protocol-tutorial"]注1:值得注意的是、总线上存在确认位并不意味着任何目标地址都已收到消息。 我们知道的唯一一点是总线上的一个或多个节点已正确接收到它。
注2:仲裁字段中的标识符尽管具有名称、但不一定标识消息的内容[/引述]
[引用 user="CAN Kingdom Standard">例如,您将不会发现与 ISO 开放系统互连(OSI)参考模型有任何相似之处。 其主要原因是 OSI 模型不支持实时网络! OSI 七层模型的一个基本概念是,设计人员只需考虑两个级别:工作级别和接口到下面的级别。 但是、在设计实时系统时、您始终需要注意从 一个节点到另一个节点的所有层传输一段信息所需的时间。 CAN 协议已经给出了这种传输方式、这种方式与 OSI 层不符。 可以主要处理较低的 OSI 层、但仲裁方案会产生报文优先级、这属于 应用层(参考文献[3])! OSI 中使用的"客户端/服务器"模型也往往会将思想导向信息流的一个点对点、这与具有广播和多播功能的 CAN 协议的信息导向概念相矛盾。 这些可能性是 CAN 的一大优势、因为它们可以减少系统中所需的通信量。 更多的是、所有节点将与 CAN 协议同时获得相同的信息、而此功能在控制器局域网中非常有用、因为在控制器局域网中、节点必须以同步方式工作。 在 OSI 模型中,您没有发现这方面的任何内容。 因此、它不能为有效利用 CAN 协议或使 CAN 网络易于理解提供任何真正的帮助。 这就是为什么这里不使用 OSI 模型的原因。[/引述]
请注意、此注释同样适用于其他控制网络、例如 TTP (时间触发协议)、Flexray 和 TT/E (时间触发以太网)
Kvaser 还发表了许多文章、介绍了各种 HLP 的基础知识以及与实时网络通信相关的其他项目。
https://www.kvaser.com/about-can/higher-layer-protocols/
Robert