Raspberry vs microcontroller as master for multinode system by CAN bus FD.

[luiHS]

Hi.
I have to do a design of a system with nodes (master, slaves), I have decided to use CAN Bus FD.
In this design I need to play videos, so I am going to use a Raspberry pi 4 for these tasks, I have not yet decided if it will be a CM4 because the two 100-pin connectors have a very fine pitch.

There will be a master and at least 5 or 6 slave nodes, all must respond to the master's commands instantly, there can be no lag.

All nodes will work with NXP RT1064 microcontrollers (Cortex M7 600Mhz), and as master I was also planning to use the same microcontroller or an RT1171 (Cortex M7 1Ghz). The master communicates with the Raspberry by serial port to send it commands with which to play videos and output texts and data on the screen.

My question now is if I could do without the microcontroller in the master and let the Raspberry manage it all by communicating with the slave nodes via CAN bus FD using an MCP2517 or MCP2518.

What worries me is that the Raspberry causes some kind of lag when processing CAN bus communications, since it does not have this bus, it has to be implemented with an SPI controller, such as the aforementioned MCP2517 or MCP2518.

[Siwastaja]

Of course the Raspberry, by running standard Linux, has non-deterministic timing and lag easily in tens of ms, and worst-case lag in seconds (or of course it can completely crash), but adding another layer does not solve this. If the Raspberry does something based on messages on CAN, or generates messages on CAN, what can you do except accept the lag?

If you can use the intermediate microcontoller to perform some part of the tasks Raspberry would otherwise need to do, specifically all the timing critical ones, without the Raspberry, then it would make sense to add that layer. Otherwise, I don't see the point.

The usual SPI CAN bridges have some buffer memory, like 2KB, and this should handle the delays of linux kernel in 99.9999% of cases but be aware that using linux, it's impossible to absolutely guarantee the timing so buffer overrun is always a theoretical possibility, but I think adding another excess layer just to add more buffer memory is more risky bug-wise.

Likely, the SPI-based CAN controller directly on the Raspberry SoCs SPI, using the kernel driver module, is quite fast and reliable. I don't think you can do any better with any other interface on the Raspi.