5 ms·

Has anyone used both I2C and other protocols like PJON or CAN and can compare?

pantalaimon 6y ago
CAN is used for more robust communication at a longer distance, whereas I2C is typically used for inter-chip communication on the same PCB. Never heard of PJON.
SAI_Peregrinus 6y ago
I've used I2C and CAN. I2C is electrically far more fragile than CAN. CAN is robust against all sorts of electrical faults. While you might not be able to transmit data, you won't fry the controller, and once the fault is removed it comes back. I2C is often more tolerant of unexpected traffic on the bus. There are far too many ECUs that will put a vehicle into limp mode (limit speed drastically) if they detect unexpected CAN traffic, even traffic not directed to them. Protocol-wise I2C is significantly simpler to get right.
- StavrosK 6y ago
  That's a very useful analysis, thanks!
  - DoingIsLearning 6y ago
    To add to this, I2C is more common between a controller and 'slaves' which are architecturally simpler, for instance single output sensors often have I2C as their comms interface. CAN is really meant for distributed embedded systems where you are having to implement full blown communication between equally complex nodes. CAN is indeed much more robust both at a physical layer with a differential line and at a transfer layer with all sorts of error detection and mitigation mechanisms.
    - StavrosK 6y ago
      I see, thanks. I'm asking mostly from a model airplane perspective, where you have a receiver, GPS, mag, transmitter, etc. Right now they use UART, with only the mag using I2C, but CAN sounds like a better solution, especially given the amount of electrical noise you get from the motors/servos.
      - tonyarkles 6y ago
        It doesn't have wide adoption yet, but it's coming! https://uavcan.org/ https://uavcan.org/
        StavrosK 6y ago
        Oooh, that's very exciting! Worth it just for the standardized connectors, pinouts are such a mess right now, no two of them are the same.
      - moftz 6y ago
        You could go for a realism factor and adopt MIL-STD-1553 or ARINC 429.
        HeyLaughingBoy 6y ago
        No LOL, but that made me giggle.
myrmidon 6y ago
The closest comparable protocol IMO would be SPI-- which generally requires more wiring and more "slave management" (addressing a certain slave device is typically done via dedicated chip-select connection, while sharing data lines). Potential data rates are significantly higher (>1MBit/s) But SPI is even less specified, and you will sometimes encounter slaves with diverging/exotic requirements (regarding chip select/clock timing behavior, actual protocol structure on bit level, etc.). This is also typically full duplex unlike both others. I2C is highly suitable as an interface to a bunch of registers, while being still very simple (especially wiring/addressing) and easy to get to work. Slave devices are also typically more consistent in behavior/requirements than with SPI. CAN is by far the most complex of these; it is not intended for connecting components on a single board, but instead to connect discrete components. It typically needs transceivers (separate from your controller), and has typically the most rigid timing requirements for participants. Multiple bitrates are possible, and the protocol already comes with mechanisms for clock synchronization, CRC checking, message retransmission on error and basic protocol structure (11/29bitID + up to 8 data bytes per message). Actual useful bandwith is often the worst with this protocol, also because overhead is very significant (think ~150bits on the bus for every message containing 8byte data+29bit ID) Max Bus baudrate is typically 1Mbit but 250K is most common, while higher rate extensions exist (CAN-FD). Never used PJON before, but AFAICT its more of a software stack on top of existing protocols (while also defining a custom physical layer). This one is MUCH less pervasive than the other three from my experience.
- StavrosK 6y ago
  That's helpful, thank you. CAN does sound much more heavy-weight, though I guess it might be a good fit when you have multiple MCUs (not just sensors to connect to one MCU).
- rcxdude 6y ago
  I would say that while CAN is much more complex as a protocol, it is far simpler from the point of view of the software interface: CAN works by sending and receiving atomic messages, and usually there's a straightforward messagebox protocol with the control which can be used. I2C on the other hand required a very complex (and timing-sensitive) interface between the software and the peripheral, due many details of the protocol being underspecified and varying from device to device. SPI is far simpler than the other two, even though there are many variations (usually just a matter of tweaking some bits in the peripheral).
monocasa 6y ago
PJON is more an abstraction over a bunch of different protocols. CAN is for off board comms. I2C should really never leave the board. I've actually seen a blend though, where someone hooked a couple CAN transceivers to bridge an I2C bus off board (a simple LED board had to be 3 meters away from the micro controller). At the end of the day they should have just put a micro controller on the other end and ran CAN over it, as they still had a bunch of glitches anyway.
TickleSteve 6y ago
CAN is intended for real-time applications, i.e. with bounded latency. Its also intended for use in noisy environments, hence the differential signalling. Both these characteristics are required for automotive applications. I2C is relatively susceptible to noise in comparison to CAN. I2C is also very simple to interface with from both a h/w and s/w perspective. CAN, having timing requirements requires more thought on the s/w side. UARTs are also simple to use and can be used in multi-drop protocols for using multiple devices and can also give good range and noise rejection in some variants (i.e. RS485, RS422, etc). SPI is for on-board, relatively high-speed use with a handful of devices (maximum) but offers limited noise rejection. There are also other simple protocols (e.g. one-wire) but they're less popular these days. PJON on the other hand is pretty much unknown and is a very much higher level protocol that isn't really comparable to CAN-bus.

CAN is used for more robust communication at a longer distance, whereas I2C is typically used for inter-chip communication on the same PCB. Never heard of PJON.

SAI_Peregrinus 6y ago

I've used I2C and CAN. I2C is electrically far more fragile than CAN. CAN is robust against all sorts of electrical faults. While you might not be able to transmit data, you won't fry the controller, and once the fault is removed it comes back. I2C is often more tolerant of unexpected traffic on the bus. There are far too many ECUs that will put a vehicle into limp mode (limit speed drastically) if they detect unexpected CAN traffic, even traffic not directed to them. Protocol-wise I2C is significantly simpler to get right.

StavrosK 6y ago
That's a very useful analysis, thanks!
- DoingIsLearning 6y ago
  To add to this, I2C is more common between a controller and 'slaves' which are architecturally simpler, for instance single output sensors often have I2C as their comms interface. CAN is really meant for distributed embedded systems where you are having to implement full blown communication between equally complex nodes. CAN is indeed much more robust both at a physical layer with a differential line and at a transfer layer with all sorts of error detection and mitigation mechanisms.
  - StavrosK 6y ago
    I see, thanks. I'm asking mostly from a model airplane perspective, where you have a receiver, GPS, mag, transmitter, etc. Right now they use UART, with only the mag using I2C, but CAN sounds like a better solution, especially given the amount of electrical noise you get from the motors/servos.
    - tonyarkles 6y ago
      It doesn't have wide adoption yet, but it's coming! https://uavcan.org/ https://uavcan.org/
      - StavrosK 6y ago
        Oooh, that's very exciting! Worth it just for the standardized connectors, pinouts are such a mess right now, no two of them are the same.
    - moftz 6y ago
      You could go for a realism factor and adopt MIL-STD-1553 or ARINC 429.
      - HeyLaughingBoy 6y ago
        No LOL, but that made me giggle.

myrmidon 6y ago

The closest comparable protocol IMO would be SPI-- which generally requires more wiring and more "slave management" (addressing a certain slave device is typically done via dedicated chip-select connection, while sharing data lines). Potential data rates are significantly higher (>1MBit/s) But SPI is even less specified, and you will sometimes encounter slaves with diverging/exotic requirements (regarding chip select/clock timing behavior, actual protocol structure on bit level, etc.). This is also typically full duplex unlike both others. I2C is highly suitable as an interface to a bunch of registers, while being still very simple (especially wiring/addressing) and easy to get to work. Slave devices are also typically more consistent in behavior/requirements than with SPI. CAN is by far the most complex of these; it is not intended for connecting components on a single board, but instead to connect discrete components. It typically needs transceivers (separate from your controller), and has typically the most rigid timing requirements for participants. Multiple bitrates are possible, and the protocol already comes with mechanisms for clock synchronization, CRC checking, message retransmission on error and basic protocol structure (11/29bitID + up to 8 data bytes per message). Actual useful bandwith is often the worst with this protocol, also because overhead is very significant (think ~150bits on the bus for every message containing 8byte data+29bit ID) Max Bus baudrate is typically 1Mbit but 250K is most common, while higher rate extensions exist (CAN-FD). Never used PJON before, but AFAICT its more of a software stack on top of existing protocols (while also defining a custom physical layer). This one is MUCH less pervasive than the other three from my experience.

StavrosK 6y ago
That's helpful, thank you. CAN does sound much more heavy-weight, though I guess it might be a good fit when you have multiple MCUs (not just sensors to connect to one MCU).
rcxdude 6y ago
I would say that while CAN is much more complex as a protocol, it is far simpler from the point of view of the software interface: CAN works by sending and receiving atomic messages, and usually there's a straightforward messagebox protocol with the control which can be used. I2C on the other hand required a very complex (and timing-sensitive) interface between the software and the peripheral, due many details of the protocol being underspecified and varying from device to device. SPI is far simpler than the other two, even though there are many variations (usually just a matter of tweaking some bits in the peripheral).

monocasa 6y ago

PJON is more an abstraction over a bunch of different protocols. CAN is for off board comms. I2C should really never leave the board. I've actually seen a blend though, where someone hooked a couple CAN transceivers to bridge an I2C bus off board (a simple LED board had to be 3 meters away from the micro controller). At the end of the day they should have just put a micro controller on the other end and ran CAN over it, as they still had a bunch of glitches anyway.

TickleSteve 6y ago

CAN is intended for real-time applications, i.e. with bounded latency. Its also intended for use in noisy environments, hence the differential signalling. Both these characteristics are required for automotive applications. I2C is relatively susceptible to noise in comparison to CAN. I2C is also very simple to interface with from both a h/w and s/w perspective. CAN, having timing requirements requires more thought on the s/w side. UARTs are also simple to use and can be used in multi-drop protocols for using multiple devices and can also give good range and noise rejection in some variants (i.e. RS485, RS422, etc). SPI is for on-board, relatively high-speed use with a handful of devices (maximum) but offers limited noise rejection. There are also other simple protocols (e.g. one-wire) but they're less popular these days. PJON on the other hand is pretty much unknown and is a very much higher level protocol that isn't really comparable to CAN-bus.