And CAN? That's worse. I don't want to raise my blood pressure too much, so suffice it to say that CAN was invented in the 80s so it could be implemented with small amounts of code and fairly simple hardware because: 80s. It requires very careful planning of every message type. There is a limit to the # of messages you can have on any one bus. The bus is not one speed, could be many common speeds. It's a standard that needs to be put into the past ASAP.
What should we use instead? I3C is trying to supplant I2C, but SPI is clearly the simple, fast alternative. UARTs these days (e.g. the common CP2102) can do 3.8 Mbaud easily - that ain't too bad. And if you need anything approaching 'real networking' --- then, gosh, use Real Networking: Ethernet. Even poky 100 Mb/s 4-wire Ethernet is better than CAN.
(note: any technology can have a 'perfect' niche, so sure, in certain applications. I2C could be optimal, and so could CAN; but generally, I claim those are mostly legacy applications.)
https://github.com/jhallen/joes-sandbox/tree/master/hw/lined...
CAN is interesting in that the protocol is pretty complex, but from software point of view it's just send_packet() and register a handler for receive packets. The annoying thing is that MCUs don't have built-in CAN line drivers.
A new thing is 1000BASE-T1- Gigabit Ethernet over a single twisted pair. This is supposed to be the future in the auto world..
In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product).
I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...