The CAN-bus has a real cool feature: It has the ability to check that the data sent actually compares to the data that was requested to be sent.
But CAN-bus is limited to 1 MHz only, because it has to stay within the specs.
Recently, I had to find a way of communicating fast with other devices.
At first, I designed a parallel-bus, only to find out that it was a lot slower than using the SSP on NXP's LPC1768.
The SSP is a vast improvement of the SPI, because it allows for higher clock rates and any bit width between 4 and 16 bits.
The LPC1768 allows me to set the speed to 50MHz, thus I will get 5MB/sec.
But it does not allow me to share the bus with multiple devices, like CAN-bus does.
However, this could easily be made, as..
The reward for adding this single bit extra functionality is that suddenly the SSP (or enhanced SPI) would be able to do much more than what it usually does. The cost vs. efficiency is definitely worth it.
It would be possible to use the same protocol as CAN-bus; but it would also be possible to customize the behaviour to fit your needs.
An enhanced SPI / SSP would primarily be suitable for sending messages between microcontrollers on the same PCB (or stacked PCBs), but not for longer distances, without reducing the speed. I believe that it would easily be possible to maintain 50MHz on a 200mm trace, perhaps longer.
If you have any thoughts about this, please post them below; I'd be happy to hear your opinion and perhaps what you would use a high-speed Inter-IC bus for.
Have you looked at CAN FD (flexible data rate) ?
I found transceivers running at 5 Mbps and even 8 Mbps
For some applications, these would absolutely be great.
In my case, though, external interfaces would unfortunately make the application too expensive (the cost would almost triple) and they would draw extra power, which is why I suggest the minor addition to the SPI/SSP.
I think that generalizing protocols and features is the right way to go; just like NXP is doing with the SPI -> SSP and Camera Interface + more -> SCT.
STMicroelectronics is also on the right track with I2S -> SAI.
Generalizing protocols and adding small additions that open up wide possibilities will allow the products to solve some problems that could not be solved otherwise (due to cost/space/power usage for instance).