Información de fondo

He usado CAN varias veces para múltiples dispositivos distribuidos en un área físicamente pequeña, como dentro de unos pocos metros de distancia. En cada caso, el bus CAN era interno al sistema y podríamos especificar exactamente cuál sería el protocolo sobre CAN. Ninguna de estos sistemas debían, por ejemplo, interactuar con OBDII, NMEA2000, etc., donde ya se había definido un protocolo específico. Un caso era una gran máquina industrial que requería muchos sensores y actuadores distribuidos. La interfaz del mundo exterior se ocupa del funcionamiento general de la máquina. La forma en que el controlador obtuvo la información del sensor y provocó que los actuadores hicieran cosas fue una opción de implementación interna que usamos para CAN. En otro caso, una compañía necesitaba una buena forma para que sus clientes controlaran varios (hasta unas pocas docenas) de los artilugios que hacen dentro de un solo sistema más grande. En este caso, especificamos CAN como un medio de comunicación y documentamos el protocolo. Este controlador lo implementaría el controlador de este sistema, pero no se lo revelaría al cliente final que compró este sistema en su totalidad y se comunicó con él a través de diferentes medios a un nivel superior.

La solución EmCan

He convergido en una forma de lidiar con esto en varias implementaciones. Ahora estoy en medio de otras dos implementaciones de este tipo, y esta vez decidí usar la experiencia anterior para crear una especificación formal para una capa de infraestructura inmediatamente superior a CAN. CAN es un protocolo bien diseñado hasta el momento, y se implementa directamente en varios microcontroladores en la actualidad. Parece una forma natural de conectar varios dispositivos pequeños a una distancia física limitada siempre que la velocidad de datos no sea demasiado alta. Básicamente, puede hacer todo lo que probablemente habría usado RS-485 hace 20 años, excepto que se especifican más capas de protocolo, la especificación tiene sentido y las implementaciones de hardware están disponibles integradas en microcontroladores de bajo costo.

El resultado de esto es lo que llamo EmCan (EMbed CAN). Poco a poco estoy completando la especificación de protocolo formal a medida que migro el código de las implementaciones anteriores, generalizo los conceptos un poco y hago cambios. Módulos de firmware utilizables donde el código del protocolo EmCan puede usarse sin cambios en una variedad de proyectos. Todavía no estoy listo para publicar oficialmente la especificación y proporcionar las implementaciones de referencia, pero puedes ver lo que hay para ver hacia dónde se dirigen las cosas. El documento actual es un trabajo en progreso, como dice él mismo.

Hasta ahora tengo implementaciones de PIC 18 y dsPIC 33 del lado del dispositivo EmCan, una implementación de host reducida para PIC 18 y una implementación más completa (más cosas manejadas localmente) para el dsPIC 33. Todo está documentado en la versión actual Se implementa y parece estar funcionando. Estoy trabajando en la interfaz de flujo de bytes en este momento. Hice esto antes en uno de los sistemas anteriores, pero estaba más ligado a la aplicación y no era una buena capa separable como EmCan.

El problema con una carga conmutada

Creo que intentar cambiar el bus CAN con FET o interruptores analógicos es una idea realmente mala . La razón principal para el intercambio de velocidad de bits en función de la longitud no es la resistencia total del cable, sino la propagación de ida y vuelta. Observe cómo CAN detecta colisiones, y verá que este mecanismo asume la propagación de la señal de un extremo a otro en un tiempo de fracción de un bit. El bus CAN debe mantenerse una línea de transmisión. Para la mayoría de las implementaciones, como cuando se usa el controlador de bus MCP2551 común, la impedancia característica debe ser cercana a 120. Eso significa una resistencia de 120 Ω en cada extremo del bus, por lo que cualquier punto en el bus se ve como una carga de 60..

Cómo EmCan arregla esto

EmCan resuelve el problema de la dirección del nodo sin requerir hardware especial. Para obtener más información, consulte la especificación de EmCan, pero básicamente, cada nodo tiene un ID de 7 bytes único a nivel mundial. Cada nodo solicita periódicamente una dirección de bus y envía esta ID. El mecanismo de detección de colisión garantizará que el maestro del bus vea solo una de estas solicitudes, incluso si varios nodos envían una solicitud de dirección al mismo tiempo. El maestro del bus envía un mensaje de asignación de dirección que incluye el ID de 7 bytes y la dirección asignada, por lo que a un solo nodo se le asigna una nueva dirección a la vez.

Si está interesado en este concepto y está dispuesto a discutir los detalles de su sistema, hable conmigo. Mi mayor temor en este momento es especificar algo que será incómodo más tarde o que prohiba ciertos usos que no había considerado. Tener otra implementación en curso a medida que se finalice la especificación sería buena para el desarrollo de la especificación y para probar la implementación de referencia si planea implementarla en los PIC de Microchip.     

En lugar de cambiar el bus CAN para lograr un direccionamiento secuencial, ¿considera cambiar el bus de alimentación de la misma manera? Cada nodo tiene vin y vout. Una vez que un nodo recibe alimentación, recibe una dirección y, a continuación, habilita Vout para que el siguiente dispositivo en línea reciba alimentación. Esto podría agregar un FET por placa, pero elimina los interruptores analógicos y mantiene bajo el riesgo de extrañeza en su bus CAN.

No menciona para qué sirve el pin de habilitación en la conexión en cadena, y si se trata de un nivel lógico, pero esto podría usarse en lugar de potencia de una manera similar; utilícelo para secuenciar la asignación de direcciones en el encendido, luego cada nodo simplemente repite el nivel lógico visto en su entrada para replicar un cable sólido después de que todos tengan una dirección.

No he visto ninguna buena forma automatizada de administrar la terminación del bus; En general, requiere un conocimiento previo de la topología del bus. Si su arnés tiene una longitud fija, el mejor lugar para realizar la terminación es el propio arnés. Si se desconoce el número de nodos, es probable que desee hacer un conector de terminación especial que se coloque en el daisy_chain_out de la última placa de la cadena. Entonces, se convierte en un requisito de que siempre haya algo conectado al puerto daisy_chain_out, ya sea otro nodo o la resistencia de terminación especial.

Espero que alguno de los anteriores haya sido útil.

Pregunta difícil de responder sin saber cuántos nodos, longitudes de cable, velocidad de transmisión, carga de bus, etc., pero en general, CAN realmente no se presta para tener una longitud de cable 'variable' y un número variable de nodos como (creo ) Necesitas.

No recomendaría agregar ningún tipo de 'cambio' en las señales CANH y CANL ya que cualquier tipo de falla aquí destruiría las comunicaciones de todo lo que esté más abajo de esto.

¿Ha considerado la CAN tolerante a fallos? Utiliza un chip de capa física ligeramente diferente (NXP TJA1054 como ejemplo) pero la terminación de la red se coloca en cada nodo, no en las extremidades del bus. El inconveniente es una velocidad de transmisión máxima de 125k y aproximadamente 100 m de longitud de cable, ya que fue diseñado para uso automotriz.

Su otro problema es la asignación dinámica de ID de nodo: ya existe una solución llamada 'Servicios de configuración de capas' y se define en la especificación CANopen DS-306. Por supuesto, tanto el maestro como el esclavo tienen que soportar esta característica.