µC + 2x MCP2515 for filtering

Hi!

I'm a bit puzzled right now.

I got myself an STM32 (specifically a Nucleo F303K8)) and connected two MCP2515s to it. So far, sending and receiving are working perfectly.

What I actually want to achieve is to connect a head unit to one MCP2515 and the corresponding display to the other. What one receives, the other transmits, and vice versa.
I want to be able to see, for one thing, which device each message originates from, and also be able to filter out individual IDs. That's the theory. It works fine in principle, BUT: As soon as a large amount of data arrives in quick succession (for example, when opening a large menu), messages are dropped, and of course, the menu fails to open.
It seems like he might not be able to retrieve the RX buffer fast enough. No matter how I try to optimize it (creating a custom TX buffer, giving higher priority to receiving, disabling serial output, etc.), nothing seems to help. It's running so unreliably .

Before I continue trying to optimize every little detail to get this working: Is my plan even feasible? What I'm doing right now would only be a "nice-to-have" for me, and I don't necessarily need it to be 100% functional, but I thought that if I could filter out specific data for the target device, it might simplify future actions. Ideas?

Regards,
Sven.

Have you connected each interrupt pin of the MCP2515 to a separate input pin of the STM?
Each MPC reports its hardware status, indicating whether there is any data in the buffer.
I haven't lost a single frame.

Hello,

"What you're planning to do, my FIS blocker does the same thing; it sits between (in my case) the radio and the car's infotainment system on the CAN bus. It's based on an STM32F4, which has 2 built-in CAN interfaces." So, you save yourself all the SPI hassle.

I have never experienced dropped frames. The STM32 runs at 186MHz, and the CAN interfaces are polled using interrupts.

Do you use polling, any wait statements, or possibly unnecessary and slow serial outputs?
Take a look at an STM32F4 Discovery board.

The STM32 is actually fast enough that, with proper programming, no messages should be lost.

I think I found the problem last night, late in the evening. It was probably not a software problem, but rather a connection problem between a transceiver and its MCP2515... a breadboard, you know . I'll keep an eye on that.

I observed with a Saleae Logic analyzer that there was complete chaos on the SPI bus at a random point in time, but no new interrupts were coming from the MCP, which suggested that my microcontroller was repeatedly requesting free TX buffer slots, but apparently, none were available.

But thank you for the suggestions .

Breadboards are so often the problem.

Just a tip: Take a look at the Teensy 3.6. It's Arduino compatible, has 2 CAN interfaces, an SD card slot, is small, and very, very fast. You can simply connect two 3.3V CAN transceivers to it and load the software for dual CAN functionality. It's hard to make it any simpler.

The Nucleo board also has a CAN interface, but I'm not entirely clear on how to get the timing right with it. I need something quite unusual for the Opel infotainment system, specifically 95.238 kbps.