Ethernet vs CAN bus physical signal

Question

Reading about Controller Area Networks and Ethernet standard, I cannot understand why there is a difference in the way the signal is transmitted. Both protocols use twisted pair cables to communicate, with mirroring signals, the logic state being determined as a function of the voltage difference between the two wires.

In CAN networks, CAN Low will range between 1,5V to 2,5V, while CAN High will be in the range of 2,5V to 3,5V.

In an Ethernet network, though, the signal will cross each other and the values will be the exact opposite of each other. So, when one cable will have +3V, the other will have -3V and viceversa.

Why did the engineers choose this particular methods and why isn't just one method used? What are the advantages/disadvantages of each?

Also, in a CAN bus, the wires will be terminated with 120Ohm resistors, to match the line impedance and ameliorate reflections and the end of the cable. I don't think ethernet cables have such terminations. If they are used, are they in the NIC's? If so, how do they account for different wire lengths?

Thank you.

Answer 1

On a hardware level:

• The CAN bus works by a voltage differential between a pair of lines.
• The Ethernet bus is current-driven and is coupled through transformers at both ends, providing galvanic insulation and avoiding any grounding issue.

The electrical operation principle is very different between these buses. Ethernet bus is by default galvanically isolated, as for the CAN bus it is not necessarily (but can be) the case.

CAN:

^{simulate this circuit – Schematic created using CircuitLab}

Ethernet:

^{simulate this circuit}

Single/Multiple points

A big difference between CAN and Ethernet is that CAN is a multi-point; no-master; address-based bus with collision management.

Ethernet is a point-to-point connection, anymore than 2 devices will need a hub of some sort.

CAN Bus, on a hardware level, is based on the RS485 bus but CAN also include the protocol layer, RS485 is only a hardware layer standard.

CAN bus is slow compared to ethernet, but is much cheaper to implement and allows to have multiple devices on the same bus without the need of hub or switches. You can also plug-in devices anywhere on the bus. Being master-less and collision tolerant, any devices can actively communicate at will, which is quite handy in some applications.

Cost

The firmware stack is also much simpler on a CAN bus, making it widely available in cheap MCU, while Ethernet often requires a dedicated chip or a Unix capable system. You can run ethernet on an MCU, but often it will take a lot of resources and require a fairly heavy and complex stack. In my experience, running an ethernet stack on bare MCU often has mixed results, and is better to have a UNIX stack as soon as dealing with ethernet.

Some MCU will have a CAN hardware module, which means the CAN transaction can be handled without the need of using the CPU, leaving more resources to the application.

Both have their own use for different needs. CAN was initially developed for the automotive industry to provide a cheap and effective way to connect all the sensors.

Hardware implementation

Bus lines are usually twisted to reduce sensitivity to ambient interferences (EMI), both in CAN and ethernet.

Can is a voltage differential-based bus that requires transceivers. The voltage level may differ, sometimes it's 5V, sometimes it's more, it depends a lot on the driver and the available power supply of your board. CAN is not, by default, isolated, while some CAN transceiver does have isolation.

Ethernet, on the other hand, is a current-driven bus that is inductively coupled. On ethernet, you always have small transformers on both sides of the line, they are either within the RJ45 socket or soldered to the board. It is by default isolated. You can see ethernet cable pairs as a current loop, driven by transformers on both ends.

CAN is a single-line bus (1 pair) with packet collision handling.

Ethernet is a multi-line bus, usually at least an RX and TX pair but it can be more depending on the CAT.

CAN requires a termination resistor on both buses ends. Ethernet does not.

---

So, when one cable will have +3V, the other will have -3V

You should rather think in terms of current flow in ethernet rather than voltage.

I don't think ethernet cables have such terminations. If they are used, are they in the NIC's? If so, how do they account for different wire lengths?

There are no needs as the bus is current driven.

Answer 2

There are some huge differences at the protocol level, other than the physical cabling issues.

First of all even CAN has a controlled impedance transmission line at 120 ohm (in fact ethernet twisted pair is one of the best CAN cable available), it's just much more tolerant.

CAN is designed as a stubbed bus system while Ethernet is in star topology (at least the modern one), so the termination points are different: end of bus in CAN (discrete terminators), port terminators in ethernet (integrated in the magnetics, substantially).

CAN has not a zero-DC guaranteed signal: the original Ethernet was Manchester IIRC, the modern one changes depending on the bitrate but it's a signal designed to pass transformers. CAN has only a guaranteed transition every IIRC 6 bits for clock recovery purposes (the error frame in fact is a huge signalling violation) so it can't be coupled in that way. Usually we keep the transceiver on the cable side and use digital isolators on the TX/RX lines.

As for the signal levels: the most important difference is that Ethernet is CSMA/CD (at least in the half-duplex, non-switched version) while CAN is CSMA/CA. In short: Ethernet tries to transmit and if a conflict occurs tries after a while (in full duplex or switched links there is no issue, it's really a point-to-point link with the switch!). CAN, on the other hand, has a rule to decide which frame will complete and which will abort. It works exactly like I2C, there is a dominant bit and a recessive bit (by the way, zero is dominant). When both are on the line dominant wins and keep transmitting. In Ethernet there are simply bit patterns (Manchester or other), if two station transmits the result is a mess (a collision) and they try later.

Supposedly this simplifies traffic planning on a CAN network since you have lower IDs always prioritary with higher IDs. Ethernet has no priority on the MACs, it's actually a random thing (by specification in the retry algorithm).

Have I missed something?