STM32中CAN外设的操作是不是等待ISR例程代码的执行？

Posted 2023-02-19

【中文标题】STM32中CAN外设的操作是不是等待ISR例程代码的执行？

【英文标题】：Does the operation of the CAN peripheral in STM32 wait for the execution of the ISR routine code?STM32中CAN外设的操作是否等待ISR例程代码的执行？

【发布时间】：2019-07-19 18:55:01

【问题描述】：

我正在使用 CAN 协议的微控制器 STM32L433 上开发堆栈层；堆栈的一个基本部分是设备的身份验证。

在身份验证期间，可能会出现两个（或更多）设备开始发送具有相同标识符和不同有效负载（真实随机值）的 CAN 消息（身份验证消息）。在这种情况下，每个设备都应该能够检测到此消息是否首先从另一个设备发送。

我研究过这个案例，可能会出现三种情况：

设备同时开始发送消息；在这种情况下，只有一台设备能够发送消息，因为所有其他设备都检测到一个错误，然后中止传输。 在所有其他设备加载 CAN 外设的传输 MAILBOX 之前，或在其他设备的 CAN 外设设置将要发送到 SCHEDULED 中的消息之前，只有一个设备能够发送消息并占用总线状态。 在这种情况下，无法发送消息的设备将收到接收中断；在接收的 ISR 例程中，我可以中止传输。 只有一个设备能够发送消息并占用总线，其他设备的所有其他 CAN 外围设备的消息处于 SCHEDULED 状态并等待总线空闲。 在这种情况下，无法发送消息的设备将收到接收中断。同样在这种情况下，我想在接收的 ISR 例程中停止传输（如情况 2）），但我不确定这是否能保证所有消息，因为如果 CAN 外设设置将要发送的消息在ISR内部代码执行前处于TRANSMIT状态，abort操作无效。

我的问题是（与情况3有关）：发送MAILBOX中处于SCHEDULED状态的消息是在执行接收ISR例程中的代码之后设置为TRANSMISSION状态还是这个东西不保证？

【问题讨论】：

1.不，这不可能发生，因为繁忙的总线不是错误。有效载荷中具有更多隐性位的节点将退出并在总线下次可用时再次尝试发送。这将由 CAN 控制器处理，并且 tx 缓冲区将保持忙碌/占用，直到消息成功发送。

我也不熟悉这个特殊的 CAN 控制器，但通常邮箱寄存器只是单独的 rx 和 tx 缓冲区之上的程序员接口。也就是说，一旦您将数据写入缓冲区，它通常会被转移到没有内存映射且您无法直接访问的实际 tx 缓冲区中。

@Lundin 非常感谢。如果错误发生正常，我可以中止传输，但我的问题与情况 3）有关。

【参考方案1】：

首先回答您的第三种情况，不，不能保证您的消息在接收时不在总线上。因为中断也可能有一些延迟，在这段时间内，邮箱可能能够继续传输。

您的“身份验证”听起来也有点麻烦，因为外部的任何人也无法真正确定哪个 ECU 实际上是赢得仲裁并实际发送了该特定消息的那个。

我们在车辆中有 ECU，它们在运行时根据某些方法决定它们通过引脚和一些 CAN 接收安装在哪里，但仅限于侦听模式。 TX 实际上在堆栈中被禁用。之后，检测完成，我们切换配置并重新启动通信堆栈，并进一步初始化软件。

但是这些“设置”通常是事先定义好的，例如由于主/从（车辆/专用总线通信），或者可能是一些连接到 GND / OPEN / U_BAT 的连接器引脚，或者可能是一些告诉它在哪条总线上的总线消息。

这似乎比你的方法更可靠。

【讨论】：

感谢您的回答。关于您的认证建议：在我们的系统中，我们无法定义先验的主设备或从设备。

主/从系统的定义是先验的，因为系统定义包含：a) 系统中有哪些 ECU，b) 每个 ECU 安装在车辆中的哪个位置。如果这是通过例如 SW 编译器开关先验确定的，那么您通常具有单独的部件号，但是对于一个部件号，SW 必须通过某种方式检测设置/ECU 安装“位置”。当 ECU 组装在车辆中时，您希望 ECU 在设置中定义的位置准确地响应 700h DiagRequest 消息和 708h DIAgResponse，而不是由谁赢得第一个仲裁随机检测到。