2 ms·

I can see your point, but I disagree with the "CAN software interface is typically simpler"-- in my experience, there is often a significantly larger API surfac

I can see your point, but I disagree with the "CAN software interface is typically simpler"-- in my experience, there is often a significantly larger API surface with CAN than with I2C on microcontrollers, and you are forced to deal with it because otherwise NOTHING works; examples are bit timing configuration, parameters for behavior when messages are not acknowledged, picking the right frame format, etc. While with I2C, chances are much better that your microcontroller manufacturer just provides you with a HAL_I2C_Mem_Write function, and you just use defaults everywhere, without understanding or caring, and things just work™. But all this probably depends a lot on specific platform...

rcxdude 6y ago
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.
R0b0t1 6y ago
I think at worst it is a wash. Having used various device on both, CAN is more regular. The complexity you attribute to CAN is there with I2C just poorly documented, devices resetting for no reason, etc. I think CAN is preferable, and you can even use it on short runs without the physical interfaces.

rcxdude 6y ago

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.

R0b0t1 6y ago

I think at worst it is a wash. Having used various device on both, CAN is more regular. The complexity you attribute to CAN is there with I2C just poorly documented, devices resetting for no reason, etc. I think CAN is preferable, and you can even use it on short runs without the physical interfaces.