I've had the opposite experience: each I2C device has its own way of using the constructs of the protocol, and you need to customise your code for each one, eve

I've had the opposite experience: each I2C device has its own way of using the constructs of the protocol, and you need to customise your code for each one, even though they all generally basically implement the same concepts. e.g. how do you address the register (after you've addressed the device), how do you read vs write, how do you read multiple bytes, empty a FIFO, what does an ACK or NAK mean? And I2c means you need the software to decide this on every. single. byte. And woe betide you if the software chose wrong or takes too long to decide, because then the bus is wedged and nothing will happen. And that's before you get into buggy implementations, either in the micro (STM32s have had multiple different buggly I2C peripherals), or on the device. I've had multiple hair-pullingly bad bugs in I2C where it mostly worked fine until some edge case or another caused the whole thing to lock up unpredictably, causing bugs which ranged from subtle to hardware destroying. It's absolutely the furthest from 'just work' I've seen at this level. On the other hand, CAN is mildly more difficult to configure initially (usually you need to understand the message box protocol if you want maximum efficiency), but it's then pretty damn bulletproof, and far less actual code to worry about.