Ethernet frente a señal física de bus CAN

A nivel de hardware:

• El bus CAN funciona por un diferencial de tensión entre un par de líneas.
• El bus Ethernet está alimentado por corriente y está acoplado a través de transformadores en ambos extremos, proporcionando aislamiento galvánico y evitando cualquier problema de conexión a tierra.

El principio de funcionamiento eléctrico es muy diferente entre estos autobuses. El bus Ethernet está aislado galvánicamente de forma predeterminada, mientras que para el bus CAN no es necesariamente (pero puede ser) el caso.

PODER:

^{simular este circuito : esquema creado con CircuitLab}

ethernet:

^{simular este circuito}

Puntos únicos/múltiples

Una gran diferencia entre CAN y Ethernet es que CAN es multipunto; no maestro; Bus basado en direcciones con gestión de colisiones.

Ethernet es una conexión punto a punto, más de 2 dispositivos necesitarán un concentrador de algún tipo.

CAN Bus, a nivel de hardware, se basa en el bus RS485 pero CAN también incluye la capa de protocolo, RS485 es solo un estándar de capa de hardware.

El bus CAN es lento en comparación con Ethernet, pero es mucho más económico de implementar y permite tener varios dispositivos en el mismo bus sin necesidad de concentradores o conmutadores. También puede enchufar dispositivos en cualquier parte del autobús. Al ser tolerante a colisiones y sin maestro, cualquier dispositivo puede comunicarse activamente a voluntad, lo cual es muy útil en algunas aplicaciones.

Costo

La pila de firmware también es mucho más simple en un bus CAN, por lo que está ampliamente disponible en MCU baratas, mientras que Ethernet a menudo requiere un chip dedicado o un sistema compatible con Unix. Puede ejecutar ethernet en una MCU, pero a menudo requerirá muchos recursos y requerirá una pila bastante pesada y compleja. En mi experiencia, ejecutar una pila de ethernet en MCU desnudo a menudo tiene resultados mixtos, y es mejor tener una pila de UNIX tan pronto como se trate de ethernet.

Algunas MCU tendrán un módulo de hardware CAN, lo que significa que la transacción CAN se puede manejar sin la necesidad de usar la CPU, dejando más recursos para la aplicación.

Ambos tienen su propio uso para diferentes necesidades. CAN se desarrolló inicialmente para la industria automotriz para proporcionar una forma económica y efectiva de conectar todos los sensores.

Implementación de hardware

Las líneas de bus suelen estar retorcidas para reducir la sensibilidad a las interferencias ambientales (EMI), tanto en CAN como en Ethernet.

Can es un bus basado en diferencial de voltaje que requiere transceptores. El nivel de voltaje puede diferir, a veces es de 5V, a veces es más, depende mucho del controlador y la fuente de alimentación disponible de su placa. CAN no está, por defecto, aislado, mientras que algunos transceptores CAN tienen aislamiento.

Ethernet, por otro lado, es un bus impulsado por corriente que está acoplado inductivamente. En ethernet, siempre tiene pequeños transformadores en ambos lados de la línea, están dentro del conector RJ45 o soldados a la placa. Está aislado por defecto. Puede ver los pares de cables Ethernet como un bucle de corriente, impulsado por transformadores en ambos extremos.

CAN es un bus de una sola línea (1 par) con manejo de colisión de paquetes.

Ethernet es un bus de varias líneas, generalmente al menos un par RX y TX, pero puede ser más según el CAT.

CAN requiere una resistencia de terminación en ambos extremos de los buses. Ethernet no.

---

Entonces, cuando un cable tendrá +3V, el otro tendrá -3V

Debería pensar en términos de flujo de corriente en Ethernet en lugar de voltaje.

No creo que los cables de ethernet tengan tales terminaciones. Si se usan, ¿están en las NIC? Si es así, ¿cómo explican las diferentes longitudes de cable?

No hay necesidades ya que el autobús funciona con corriente.

Hay algunas diferencias enormes a nivel de protocolo, aparte de los problemas de cableado físico.

En primer lugar, incluso CAN tiene una línea de transmisión de impedancia controlada a 120 ohmios (de hecho, el par trenzado de Ethernet es uno de los mejores cables CAN disponibles), es mucho más tolerante.

CAN está diseñado como un sistema de bus stub mientras que Ethernet está en topología de estrella (al menos la moderna), por lo que los puntos de terminación son diferentes: fin de bus en CAN (terminadores discretos), terminadores de puerto en ethernet (integrados en el magnetismo, sustancialmente ).

CAN no tiene una señal garantizada de CC cero: la Ethernet original era Manchester IIRC, la moderna cambia según la tasa de bits, pero es una señal diseñada para pasar transformadores. CAN solo tiene una transición garantizada cada IIRC 6 bits para fines de recuperación del reloj (el marco de error, de hecho, es una gran violación de señalización), por lo que no se puede acoplar de esa manera. Por lo general, mantenemos el transceptor del lado del cable y usamos aisladores digitales en las líneas TX/RX.

En cuanto a los niveles de señal: la diferencia más importante es que Ethernet es CSMA/CD (al menos en la versión semidúplex, no conmutada) mientras que CAN es CSMA/CA. En resumen: Ethernet intenta transmitir y, si se produce un conflicto, lo intenta después de un tiempo (en enlaces full dúplex o conmutados no hay problema, ¡es realmente un enlace punto a punto con el conmutador!). CAN, por otro lado, tiene una regla para decidir qué cuadro se completará y cuál se cancelará. Funciona exactamente como I2C, hay un bit dominante y un recesivobit (por cierto, cero es dominante). Cuando ambos están en la línea dominante gana y sigue transmitiendo. En Ethernet, simplemente hay patrones de bits (Manchester u otros), si dos estaciones transmiten, el resultado es un desastre (una colisión) y lo intentan más tarde.

Supuestamente, esto simplifica la planificación del tráfico en una red CAN, ya que tiene ID más bajas siempre prioritarias con ID más altas. Ethernet no tiene prioridad en los MAC, en realidad es algo aleatorio ( por especificación en el algoritmo de reintento).

¿Me he perdido algo?