Embedded STM32中CAN外围设备的操作是否等待ISR例程代码的执行?

Embedded STM32中CAN外围设备的操作是否等待ISR例程代码的执行?,embedded,interrupt,stm32,can-bus,Embedded,Interrupt,Stm32,Can Bus,我正在微控制器STM32L433上开发一个使用CAN协议的堆栈层;堆栈的一个基本部分是设备的身份验证。 在身份验证期间,可能会出现两个或多个设备开始发送具有相同标识符和不同有效负载真实随机值的can消息身份验证消息的情况。在这种情况下,每个设备都应该能够检测此消息是否首先从另一个设备发送 我已经研究过这个案例,可能出现3种情况: 设备同时开始发送消息;在这种情况下,只有一个设备能够发送消息,因为所有其他设备检测到一个错误,然后中止传输。 在所有其他设备加载CAN外围设备的传输邮箱之前,或者在其他

我正在微控制器STM32L433上开发一个使用CAN协议的堆栈层;堆栈的一个基本部分是设备的身份验证。 在身份验证期间,可能会出现两个或多个设备开始发送具有相同标识符和不同有效负载真实随机值的can消息身份验证消息的情况。在这种情况下,每个设备都应该能够检测此消息是否首先从另一个设备发送

我已经研究过这个案例,可能出现3种情况:

设备同时开始发送消息;在这种情况下,只有一个设备能够发送消息,因为所有其他设备检测到一个错误,然后中止传输。 在所有其他设备加载CAN外围设备的传输邮箱之前,或者在其他设备的CAN外围设备将要发送的消息设置为预定状态之前,只有一个设备能够发送消息并占用总线。 在这种情况下,无法发送消息的设备将接收接收中断;在ISR接收例行程序中,我可以中止传输。 只有一个设备能够发送消息并占用总线,所有其他设备的外围设备都可以使消息处于预定状态并等待总线空闲。 在这种情况下,无法发送消息的设备将接收接收中断。同样在这种情况下,我想在接收的ISR例行程序中停止传输,如情况2,但我不确定这对所有消息都有保证,因为如果CAN外围设备在执行ISR内部代码之前将要发送的消息设置为传输状态,则中止操作将无效。
我的问题与情况3有关:在接收ISR例程中的代码被执行后,处于计划状态的传输邮箱中的消息被设置为传输状态,或者这件事没有得到保证?

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

您的身份验证听起来也有点麻烦,因为外部没有人能够真正确定哪个ECU是赢得仲裁并实际发送该特定消息的ECU

我们在车辆中安装了ECU,这些ECU在运行时根据某些方法进行决定,它们通过pin和一些CAN接收安装,但仅在侦听模式下,TX实际上处于禁用的堆栈中。检测完成后,我们切换配置,重新启动通信堆栈,并进一步初始化软件。 但是,这些设置通常是预先定义的,例如,由于主/从车辆/专用总线通信,或者可能是一些连接到GND/OPEN/UBAT的连接器引脚,或者可能是一些总线消息,告知它在哪条总线上


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

1。不,这不可能发生,因为繁忙的总线不是错误。有效负载中有更多隐性位的节点将退出,并在下一个总线可用时再次尝试发送。这将由CAN控制器处理,在消息成功发送之前,tx缓冲区将保持忙碌/占用。此外,我不熟悉此特定CAN控制器,但通常邮箱寄存器只是单独rx和tx缓冲区之上的一个程序员接口。也就是说,一旦您将数据写入缓冲区,它通常会被转移到实际的tx缓冲区,该缓冲区没有内存映射,您无法直接访问。@Lundin非常感谢。如果发生错误,我可以中止传输,但我的问题与情况3有关。谢谢你的回答。关于您的认证建议:在我们的系统中,我们无法定义先验主设备或从设备。主/从系统的定义是先验的,因为系统定义包含:a系统中有哪些ECU,b每个ECU安装在车辆中。如果这是由软件编译器开关等预先确定的,则通常有单独的零件号,但对于一个零件号,软件必须通过某种方式检测设置/ECU安装位置。当ECU组装在车辆上时,您希望ECU在设置中定义的位置准确响应700h DiagRequest消息,708h DIagResponse,而不是由赢得第一次仲裁的人随机检测到。