Ejecución de bus CAN con transceptor RS-485

Recientemente tuve una discusión sobre si se podrían usar transceptores RS-485 para una red CAN-bus para obtener la flexibilidad de usar el mismo hardware en un entorno CAN o en una red RS-485 semidúplex, aunque con un software diferente. .

esquemático

simular este circuito : esquema creado con CircuitLab

La idea es utilizar un controlador de bus RS-485 como de costumbre cuando se utiliza la placa en la configuración RS-485. Que este el transmisor esté habilitado por DEN cuando uno quiera transmitir y los bits se presenten en la entrada D como de costumbre. Se proporcionan pull-up y pull-down adicionales para garantizar un nivel de autobús válido en las líneas de autobús abiertas.

Cuando está en modo CAN, la entrada D está ligada a nivel bajo (dominante) y la entrada DEN se usa para presentar el flujo de bits al transmitir. Cuando DEN = 1 (controlador habilitado), el bus se conduce bajo (dominante), de lo contrario, la línea permanece recesiva. Entonces, esto debería imitar la naturaleza de colector abierto del bus CAN, ya que solo un estado es activado activamente mientras que el otro solo es activado pasivamente por las resistencias pull-up.

La parte que considero es el SN64HVD11 y el SN65HVD230 como referencia para un transceptor CAN 3V3.

Los tiempos de habilitación del controlador del SN64HVD11 se dan como máx. 55 ns y el tiempo de caída está limitado a 30 ns, que es menos que las cifras comparativas del controlador CAN "real".

¿Alguien ha probado esto antes? ¿Hay problemas que podría pasar por alto por completo?

Aclaración: todo el sistema está destinado a un control de vehículos no tripulados a pequeña escala en el ámbito académico, por lo que la interoperabilidad con componentes de terceros no se considera importante.

Las líneas de bus CAN están inactivas a 2,5 V. RS-485 está inactivo a 5V y 0V respectivamente.

Respuestas (3)

Probablemente se pueda hacer que funcione, ¡aunque yo no lo llamaría una "solución de producción"!

Una cosa que deberá hacer es invertir la señal DEN ya que CAN es dominante bajo, no dominante alto.

También deberá ajustar la terminación ya que, aunque tanto CAN como RS485 están diseñados para terminar con una sola resistencia de 120 ohmios en cada extremo del bus, las resistencias de polarización adicionales que normalmente incluye RS485 llevarán las líneas del bus a voltajes ligeramente "o lado del punto central", mientras que CAN necesita inactivo recesivo a ~ 2.5V en ambas líneas.

IIRC, hay alrededor de 0,5 V de voltaje diferencial permitido antes de que se detecte un bit dominante.

Según tengo entendido, tanto CAN como RS-485 requieren terminación solo en ambos extremos. Para RS-485, las resistencias de polarización hacia tierra y VCC a menudo se sugieren para proporcionar un nivel lógico determinado en el circuito abierto. Me pregunto si se supone que estas resistencias de polarización deben colocarse en cada nodo.
La inversión de la señal DEN no debería suponer un problema ya que el controlador CAN está conectado al controlador de bus a través de un FPGA/CPLD de todos modos.
Bastante seguro de que rs485 usa un conjunto de resistencias de polarización para todo el bus. Suelen ir cerca de uno de los dos terminator iirc.
En ese caso, leí mal el esquema, lo que implica que la terminación y el sesgo estarían en cada nodo. Sigo pensando que la CAN será potencialmente escamosa si las resistencias de polarización RS485 están allí (aunque solo sea en los extremos del bus)

Esto funcionaría, pero reduciría el margen de ruido frente al RS485 adecuado o al CAN adecuado.

El gran problema está en el extremo de recepción. El umbral CAN es de 700 mV típico (+500 a +900 mV). El umbral de RS485 es de 0 V típico (-200 a +200 mV).

La red de terminación está solo en cada extremo del bus RS-485. Esto está diseñado para proporcionar un diferencial de alrededor de 200 mV entre A y B (necesario para los transceptores RS485 para garantizar una salida "1").

Para el receptor RS-485, termina con un margen de ruido negativo cuando busca el estado no dominante en un bus CAN (en el peor de los casos), ya que los receptores RS485 estándar de bog tienen un umbral especificado como +/- 200 mV, donde solo CAN promete 500mV. Algunos transceptores RS485 más nuevos son de -50 mV típicos, 0 mV en el peor de los casos, pero aún así no detectarán 500 mV.

Si usa un transceptor más nuevo y cambia "B" y "A" para que CANL sea RS485A y CANH sea RS485B, obtendrá una polarización adicional de -200 mV en el bus, por lo que el receptor RS485 tendrá más posibilidades de detectar el no -estado dominante (las resistencias de polarización estarían tirando en sentido opuesto al bit dominante, por lo que el transceptor RS485 tendrá una mejor oportunidad de ver el cruce).

Tomará algo de trabajo en el CPLD para invertir en todos los lugares correctos.

Cuando miré esto, decidí instalar transceptores CAN y 485, ambos conectados al bus, y agregar lógica para garantizar que solo uno estuviera activo a la vez.

Esta es la respuesta correcta. Se puede hacer que el lado Tx funcione, pero el lado Rx funcionará en umbrales incorrectos. Conectar un transceptor RS485 y CAN a las mismas líneas aumentará la carga capacitiva, lo que puede ser un problema de calidad de la señal a altas tasas de bits.

En algún lugar escuché que algunas de las primeras aplicaciones CAN usaban rs485. No estoy seguro de si el CAN moderno sigue siendo compatible, pero en la superficie se ven similares. El problema que veo es que el transceptor RS485 podría tener un retraso en el encendido después de habilitar el controlador, pero eso se mencionaría en la hoja de datos.

Pero si los protocolos son realmente lo suficientemente similares, ¿por qué no simplemente agregar pull up/downs al bus rs485 y usar un transceptor CAN para ambas tareas? Los transceptores CAN tienen el mismo precio o son más baratos y parecen tener una mejor protección contra fallas que los transceptores rs485 del mismo costo.

Eso es si son realmente compatibles, de lo que no estoy seguro.

Ejecución de bus CAN con transceptor RS-485
RespuestasAquíPolítica de privacidad1y, 0v