(all UART interfaces are consumed already)
It may be worth seeing if one can be swapped around reflecting priorities here. Or multiplexed (exclusive use with one device at a time). But perhaps they're all optimally used, and something else is preferred.
Oops. I overlooked the bursts of 50kB of data to send every 10 minutes.
CAN is a nuisance for sending bigger packets. It has a very limited / small frame format.
CAN I *think* is more of a set-of-registers protocol, with similarities to Modbus and other industrial comms -- I haven't worked with it personally (actually a bit surprising at this point, to be fair), but yeah this sort of thing tends to complicate large packets. You might basically implement a handshaking transfer protocol on top of the transport layer, which is... annoying, but doable. (For example, client sets "receive ready" register, server sets up new data register values; client polls "data ready" register, then reads out and stores a round; client clears then resets "receive ready" to signal the next round; etc.) All the delays of polling and processing, plus comms with other things on the bus (maybe not the case here, but happens in general purpose use), and automatic re-sending or whatever error correction, can add up to a lot of variable latency and really cut into the transfer rate.
I recall hearing about some manner of "mailbox" mechanism, which shows up on these sorts of protocols; I forget if CAN has that, or it's one of the expanded types, or, maybe it's literally just doing the above but as a standard network layer rather than ad-hoc.
Neither I2C nor SPI are very suitable for driving cables. Especially I2C is hampered by capacitive loading. SPI can work, but if you have a few meters of cable then you need extra bus drivers to make it reliable.
Don't be so dismissive based on trigger words -- give it a thought first:
There will be roughly 2m cabling between the two
2m is hardly a burden for these protocols, and if baud can be cranked down low, ample filtering can be applied, reaping immunity instead.
As demonstrated in my earlier link, a short pendant connection like this is quite capable in EMI terms, for frequencies below the electrical length of the cable. And filtering is readily added.
I wouldn't actually mind at all doing I2C here, with the sub-400kbaud rate being easily filtered for the 10MHz+ EMI that's likely to interact with it. I2C's 50ns glitch removal helps with EFT/ESD (though how much depends on how those transients interact with the bus filtering), and implementing a CRC and block retransmit protocol should address errors.
I2C is kind of the worst case for filtering, as its high-impedance pull-up condition guarantees mismatch with the driven-low (~30Ω) condition, neither case can be optimized for signal quality or noise rejection. But again, noise largely starts in the 10MHz+ range, and a lowpass cutoff around a few MHz, for either condition, will handle that regardless.
SPI is fine, as the clock can be cranked down nice and low, and logic-level signals used -- filtering is effective as signals are full-wave driven, no open-drain state (except if deasserted between transactions, which really doesn't matter one way or another).
Either option saves greatly on continuous current consumption of a terminated RS-422 bus.
if the SBC wake time is some seconds, a transfer rate under 50kBps seems satisfactory. That's under 500kbaud UART, 400kHz SPI, ~450kHz I2C (depending on packet length and overhead), etc.
Mind, I'm still being careful with comparisons here:
A RS-422/485 bus doesn't need to be terminated into exactly Zo.
It may be that a faster 422/485 bus (say 10Mbaud) transfers data faster than the current saved by I2C's larger-value pullups; almost trivially so if weak pulls are used instead of termination.
422/485 might simply not be applicable due to higher priority UART allocations, forcing CAN/I2C/SPI.
Perhaps CAN could be lightly-terminated as well; though, I don't know how well that plays with the bus arbitration mechanism.
(Incidentally, CANbus has an I2C equivalent: differential I2C I believe uses the same unipolar-driven-bus scheme, greatly improving immunity. I don't see it being necessary here, but when you must use I2C over enough distance, it's the preferred way to do it. Also, just to make it clear -- CAN signaling is essentially based on RS-485, indeed you can drive it with such a transceiver, with data set always-high and toggling enable instead. So it's no accident that they show up in similar contexts, as far as robustness and immunity.)
Tim