¿Las comunicaciones del bus CAN son suficientes para actualizar el firmware?

2
  1. Voy a controlar algunas unidades basadas en microcontroladores (aproximadamente 30) desde una computadora maestra.
  2. Se conectarán utilizando un bus CAN
  3. La unidad más alejada puede estar a aproximadamente 10 metros de distancia.
  4. Necesito actualizar el firmware del microcontrolador desde la computadora maestra.

Arriba están mis requisitos del sistema. Ahora vienen mis preguntas:

  1. ¿Las comunicaciones CAN bus son suficientes para actualizar el firmware?
  2. ¿Cuánto tiempo pueden funcionar las comunicaciones del bus CAN?
  3. ¿Necesito un transceptor CAN o es suficiente lo incorporado?
  4. Si no, ¿qué otras opciones existen para actualizar los microcontroladores desde el maestro? (de otra manera que mediante el uso de un bus CAN)

(No tengo una base sólida en microcontroladores (aunque soy un ingeniero de electrónica y comunicaciones)).

    
pregunta Maharajan

5 respuestas

8

Actualmente tenemos un sistema con 10 microcontroladores en un bus CAN, y puede actualizar el firmware en cualquiera de ellos. Funciona así:

El firmware de cada MCU consta de dos partes, el cargador de arranque y la aplicación. En el encendido, el Bootloader se ejecuta primero. Comprueba un byte en la EEPROM que indica si una aplicación válida está cargada en el FLASH o no.

Si se carga una aplicación (EEPROM = 0x42), el gestor de arranque salta directamente a ella, y la aplicación se ejecuta normalmente

Si no se carga ninguna aplicación, el gestor de arranque espera instrucciones en el bus CAN. Hay varios tipos de instrucciones que pueden provenir del maestro: Establecer dirección, Escribir datos, Leer datos, Finalizar. Y el gestor de arranque puede responder con: Hola, Datos, Escritura terminada.

El Maestro envía paquetes de datos para que el Cargador de arranque escriba en el FLASH (siempre asegurándose de que no se le solicite que se sobrescriba). Como la escritura lleva un tiempo, envía un mensaje de escritura finalizada cuando termina de escribir cada bloque. Después de haber enviado toda la Aplicación, el Maestro luego la vuelve a leer para asegurarse de que todo está escrito correctamente. Por último, envía un mensaje finalizado al gestor de arranque. El Bootloader escribe 0x42 en la EEPROM y salta al código de la aplicación.

Por supuesto, la aplicación también debe ser consciente del cargador de arranque. Debe haber alguna forma de decirle a la Aplicación que escriba 0xFF en la EEPROM y luego reinicie la MCU. Esto hará que vuelva al Bootloader y espere las instrucciones.

    
respondido por el Rocketmagnet
4
  1. La actualización del firmware no depende de la elección del bus. El bus solo es responsable de transferir datos de un nodo a otro. El código en sus unidades debe poder actualizar el código de cualquier información recibida a través de CAN. Sobre la integridad de los datos, CAN Bus tiene un mecanismo de CRC decente para evitar la corrupción. Por lo tanto, será seguro transmitir datos críticos a través de CANBus

  2. CAN puede comunicarse hasta 40mtrs a 1M Baud. Más el baud, menos es la distancia y viceversa.

  3. Hay muchos controladores que tienen un transceptor CAN incorporado. No necesitas más. Si su controlador no tiene un chip transceptor CAN, definitivamente necesita uno.

respondido por el Swanand
2

La forma en que lo he abordado es la siguiente:

Tengo un nodo maestro. Este dispositivo es la nave nodriza, envía comandos y le dice a los demás qué hacer. Por el bien de esta conversión, estoy usando un LPC1769 (Cortex-M3) que tiene dos en -los controladores CAN , así que tengo dos TJA1050 para hacer las conexiones a los autobuses CAN reales.

Mis dispositivos periféricos que se sientan en el bus utilizan un LPC11C24 . Es un Cortex-M0 con un transceptor CAN incorporado , por lo que puedo mantener el recuento de componentes externos agradable y, a su vez, mantener los tableros periféricos y los gabinetes aún más pequeños.

Cada vez que se arrancan los periféricos, van al gestor de arranque. Verifican si necesitan ser programados. Si es así, solicitan que los programe el maestro, que sigue de manera similar a la respuesta anterior de Rocketmagnet. El único giro es que, si están programados, verifican si están actualizados. Si el maestro tiene una versión más nueva del firmware que ellos, también solicitarán que se actualice.

Este enfoque me permite no solo pegar un periférico nuevo en el bus y hacer que "simplemente funcione", sino que también me permite enviarles un nuevo firmware a través del maestro. Todas las actualizaciones proceden del mismo lugar. Para actualizar el firmware en mi dispositivo maestro, hago que se presente como un dispositivo de almacenamiento masivo USB y puedo arrastrar y soltar archivos en él.

Puede usar el protocolo que desee ... 1-Wire, I2C, SPI, CAN, etc. Los parámetros operativos y las limitaciones de longitud están claramente documentados con una simple búsqueda en Google. Siendo realistas, CAN es probablemente la mejor opción. Fue diseñado con largos recorridos en malos ambientes en mente. Es relativamente rápido teniendo en cuenta que la mayoría del firmware para un microcontrolador es de solo unos pocos kB, tal vez decenas de kB. Además, solo requiere dos cables, lo que significa que puede conectar en cadena los dispositivos con tan solo cuatro cables. 1-Wire solo necesitaría 3, e I2C solo necesitaría cuatro, pero son bastante "meh" en comparación con CAN. : P

Ahora, si tiene todos los dispositivos con un LPC1769 , admite Ethernet con un pequeño IC auxiliar . Puede hacer que todos los dispositivos se conecten a través de Ethernet y transferir gran cantidad de datos para arrancar desde el maestro. Parece que solo estás buscando hacer transferencias simples de firmware ... pero es algo para pensar. :)

    
respondido por el Toby Lawrence
0

De hecho, la actualización del firmware a través de CAN es posible. Ya está hecho en muchos coches de producción.

La longitud máxima del bus CAN depende de varios factores, entre ellos:

  • velocidad de bits
  • retrasos a través de la capa física (especialmente si hay aisladores ópticos)

El ACKnowledge desde el nodo más lejano tiene que llegar hasta el final del bus y los retrasos antes del punto de muestreo del nodo "más cercano". Por lo tanto, la compensación de velocidad / longitud / retraso

También:

  • la calidad de las fuentes de reloj utilizadas dentro de cada uno de los sistemas conectados al bus: cuanto más inquieto tenga, más corto será el bus para garantizar que los nodos puedan permanecer sincronizados.
  • calidad del cableado del bus (he visto fallar un bus de 10 m de longitud cuando los cables solo están torcidos de forma vaga y luego funcionan cuando se reemplazan con un cable debidamente especificado)
respondido por el Martin Thompson
0
  

¿Las comunicaciones CAN bus son suficientes para actualizar el firmware?

Sí, el bus CAN es más que suficiente para actualizar el firmware. Un bus CAN típico utilizado para automóviles es de alrededor de 1Mega baudios y para aviones es de 10 Megabaud, lo que es más que suficiente para el arranque de firmware.

  

¿Cuánto tiempo pueden durar las comunicaciones del bus CAN?

Una comunicación de bus CAN puede ejecutarse fácilmente para sus necesidades. Por lo que he probado, es de 100 m a 250 kbps y creo que es posible hasta 1000 m.

  

¿Necesito un transceptor CAN o es suficiente lo incorporado?   Si no, ¿qué otras opciones hay para actualizar los microcontroladores desde el maestro? (de otra manera que mediante el uso de un bus CAN)

Ve por los microcontroladores de automoción. La mayoría de ellos tienen puertos Can en su interior. Por ejemplo, > freescale 9s12 / 9s12x

Otra cosa que puedes mirar es LIN. LIN es una solución rentable para CAN y funciona de manera similar a un bus CAN. El único problema es que la distancia es limitada, pero creo que 10 m no deberían ser un problema.

    
respondido por el Vish

Lea otras preguntas en las etiquetas