大家好，
我在配置通过中断接收 CAN 消息时遇到了问题。我认为问题与硬件对象有关，我正在分享配置的图片以便更好地理解。
重点是我已经配置了 3 个 CANbus 来发送和接收数据，因此我配置了 6 个 CAN 硬件对象，如下所示。
因此其中 3 个用于传输（此时没有问题），3 个用于接收。正如上图所示，每个hw对象的最后一个参数是“Can Hw Object Count”。在这里，我配置了每条总线的预期消息数量，具体取决于它们是 TX 还是 RX。
这似乎与 TX 消息配合良好，但不与 RX 消息配合良好，因为我在 Tresos 收到下一个错误。
因此根据该描述，“Can Hw Object Count”必须设置为 1，这是我原来的配置。问题是，使用该配置我根本没有收到任何消息，我推测是因为消息缓冲区仅限于单个消息。
我的问题是，是否真的有必要为每个 RX 消息定义一个 CAN 硬件对象？对象计数参数不能声明除 1 之外的值吗？否则，我必须定义至少 56 个 hw 对象，这除了效率低下之外，还会造成混淆，因为无法知道哪个对象对应哪个消息（从而对应哪个总线）。
提前致谢，如果需要更多信息，请告诉我。
Hello,
如果您指的是此 EBtreos 设置：
这是为 Rx 消息缓冲区分配的内存区域的大小。这并不反映传入 CAN 消息的实际数据大小，它更像是一个上限。
您可以使用 CanIf_RxIndication 中断回调块的第 5 个输出端口提取 CAN 消息的实际数据长度：
你好，Adrian，
它确实有效！现在消息接收正确并且总线管理运行良好。
然而有些事情我不太明白。每次设置 RX 接收标志时，IRQ 处理程序都会从 CAN MB 获取数据。此 CAN 数据大小在 Tresos 中配置为 8 个字节，并且考虑到 IRQ 本身没有数据或大小，除非您指定正确的数据长度（已在 Tresos 中配置），否则怎么可能只取一个字节呢？
感谢您的支持，
BR
Hello,
您在第 236 行突出显示的是一个重要线索。
与变量“长度”进行比较的值表示 CanIf_RxIndication 中断回调块的第 4 个输出的大小。
在这种情况下，“数据”的大小看起来是 1，这意味着只有一个字节的数据通过该输出传输。
为了修复这个问题。我建议您查看工具箱中的 s32k344_can_fd_echo_ebt 示例：
经过一些测试后，我更新了新信息。
我注意到接收到的数据总是在消息的第一个字节，因此分析生成的代码这就是我所看到的。
因此，首先清除数据数组，然后根据中断处理程序中获得的数据对该数组进行内存复制。这里的问题是，即使消息的有效负载是 8，也只有 1 个字节被复制到数据数组。
之后我检查了中断处理程序，得到了以下结果。
正如您在第 236 行看到的，有一个 if 将数据的有效载荷限制为 1 个字节。现在我的问题是，为什么会发生这种情况？这可能是一个配置错误，但我确定我在 Can_43_FLEXCAN 驱动程序上将有效载荷定义为 8。
BR
你好，Adrian：
抱歉回复晚了，最近比较忙。我没有做太多测试，但我注意到即使删除每个总线子系统的条件触发器，消息也无法正确接收。
这很奇怪，因为对于给定的 CAN 消息，有些信号被正确处理，而其他信号则被省略。CANalyzer 软件显示的数据正确，所以我可以保证问题出在 VCU 上。
我恢复了触发的子系统并将它们配置为原子，因为这可能是执行问题，但行为与非原子相同（至少我没有看到区别）。
我不确定这是配置问题（Tresos）还是软件问题，但在我看来代码是正确的。
如果您觉得有用，我可以分享与 CAN 接收或 Tresos 配置相关的块，但我需要一个安全的链接才能这样做。
BR
你的说法是正确的。
抱歉，我的意思是硬件中断回调是接收和发送中断处理所需的块，它可以为 CanIf_TxConfirmation 以及 CanIf_RxIndication 配置。
你好，Adrian：
谢谢您的回复，新年快乐！我没有正确解释过滤器掩码，我的意思是我没有配置默认设置，所以所有传入的消息都被接受了。这基本上就是您所说的，所以我想这没问题。
我不太确定CanIf_RxIndication 的含义。配置 ISR 模块时，有一个用于发送消息的选项（CanIf_TxConfirmation），另一个用于接收消息的选项（CanIf_RxIndication）。这种说法有误吗？
我的想法是，一旦收到消息，CanIf_RxIndication 就会触发 ISR，并且根据 HW 对象 ID，我可以知道哪个总线导致了中断。然后我可以处理相应块内的数据，如我之前的帖子图片所示。
这周和下周我会很忙，但只要我能做一些测试，我就会回复你。
BR
如果您尚未配置它们但仍然接收 CAN 消息，则可能是每个接收 CanHardwareObject 的过滤器掩码设置为忽略过滤器代码的所有位（过滤器掩码 = 0），从而导致接受所有传入消息 ID。
如果您提到的子系统未执行，请检查触发中断回调的通信类型（接收/发送），因为 CanIf_RxIndication 在接收和发送时均会执行。
还要检查 CanHwObject 的处理类型（轮询、中断）和消息 ID 类型（标准、扩展）。
感谢 Adrian 的详细解释。
这更有意义，也与我的想法一致。只是为了确定，我从未在 Simulink 程序中使用过过滤器掩码，在当前运行的程序中也没有使用过过滤器掩码，所以我认为即使建议使用它也不是强制性的，对吗？
关于这个问题，我发现中断没有进入相应的子系统，这取决于硬件对象。
因此，子系统根据 hw 对象的值触发，但即使单个总线运行，子系统也不会触发。
禁用触发器（常规子系统）即可正确接收消息。圣诞假期回来后我会调查此事。
BR
你好，AsierMaser，
每个 Tx 消息都需要一个专用的硬件缓冲区，因为传输是一个主动过程，其中控制器必须确保消息仲裁、定时和必要时的重新传输。
CanHwardwareObject 是用于传输的物理 CAN 消息缓冲区的描述，您可以根据应用程序的需要拥有此描述的多个实例。
Tx 的 CAN HW 对象计数指定了传出消息所需的专用 Tx 硬件消息缓冲区（CanHwardwareObject 的实例）的数量。
对于正常的 Rx 对象，CAN 控制器使用过滤机制将传入的消息定向到公共缓冲区或直接发送到软件，而不需要为每个 Rx 消息设置专用的硬件缓冲区。
这降低了硬件的复杂性，因为传入的消息通常在应用程序中的软件管理队列中处理和存储。
必须最佳地设置来自每个 CanHwardwareObject 的过滤机制，以便能够正确、及时地处理每个消息缓冲区上的负载。这样就无需拥有多个 CanHwardwareObject（消息缓冲区）实例。因此，Rx 对象的 CAN HW 对象计数只能为 1。
我建议阅读这篇文章（重点关注第 2.3.2 节）。我们团队编写的过滤机制（CanHardwareObject）可以阐明过滤机制的工作原理：
通过 CAN 总线进行通信。
增强型或传统 FIFO 是例外，其中硬件队列用于 Rx，需要计数。对于这些类型的对象，可以增加 CAN HW 对象计数。