Usar un microcontrolador para programar otro microcontrolador (en una tarjeta inalámbrica)

4

Estoy trabajando en un proyecto en el que quiero incluir la funcionalidad de reprogramar el microcontrolador principal a través de la transmisión inalámbrica.

Primero, he pensado que es necesario que haya un microcontrolador dedicado programado para facilitar esta función, pero ¿exactamente cómo se debe implementar?

Suponiendo que el código ya está compilado antes de la transmisión, ¿debería el código ser almacenado de alguna manera específica antes de ser leído y utilizado para programar el controlador principal?

Además, ¿cuál es exactamente el proceso requerido para facilitar la programación real del controlador?

    
pregunta sherrellbc

3 respuestas

3

Algunos controladores pueden escribir en su propio programa flash bajo el control del software; otros no pueden Si necesita usar un procesador secundario para programar el primario, realmente no es muy diferente de cualquier otra tarea que requiera ciertos pines dispuestos en ciertas secuencias con ciertas restricciones de tiempo. Lo más importante que hay que buscar es que algunas partes pueden programarse de varias maneras, algunas de las cuales pueden ser mucho más rápidas que otras. Si la parte que se va a programar puede escribir en partes de su propio flash bajo el control del software pero no puede hacer todo y, por lo tanto, requiere el uso de un procesador secundario, a veces puede ser más rápido que el procesador secundario programe el primario con la suficiente de un cargador de arranque para recibir su código a través de otros medios (como un UART) que utilizar el modo de programación en circuito para todo.

    
respondido por el supercat
2

Hace poco hice un proyecto similar, excepto que la actualización se realizó a través de UART en lugar de inalámbrica. Todo estaba en un microcontrolador, un Silicon Labs SiM3C166. El flash integrado se segmentó lógicamente en 3 secciones, el cargador de arranque, la aplicación activa y la aplicación pendiente (en realidad había una 4ta, pequeña sección que contenía un hash de la aplicación pendiente, para verificar que se había cargado correctamente).

El código de la aplicación incluyó el código para recibir la nueva imagen y escribirlo en la sección "pendiente". Una vez que toda la imagen se cargó y verificó contra el hash, el código hizo un reinicio suave. Esto inicia el gestor de arranque, que se encuentra en la dirección 0.

La función del gestor de arranque es simple para verificar la aplicación pendiente contra su hash y compararla con la aplicación existente. Si el hash es válido y la nueva imagen es diferente a la anterior, copia la nueva aplicación sobre la antigua y luego borra el hash.

Finalmente, independientemente de si la aplicación fue copiada o no, transfirió el control a la aplicación actual. (Esto consistió en reubicar el bloque de vector de interrupción al espacio de la aplicación y derivar a la primera palabra de la aplicación).

Cosas a tener en cuenta: la aplicación tenía que estar vinculada para ubicarse en una dirección distinta de 0, específicamente a la base de la sección "activa" de flash. Esto incluía mover los vectores de interrupción. El procesador ARM M3 tiene un registro del sistema que apunta a la tabla de vectores interrot y se usó para cambiar los vectores del cargador de arranque a los vectores de aplicación.

Una vez que el código de la aplicación se está ejecutando, el código del cargador de arranque no se volverá a usar hasta que se reinicie el procesador.

Con suerte, esto te dará una idea de lo que se puede hacer.

    
respondido por el DoxyLover
1

¿Qué chip estás usando? Escribí un gestor de arranque para los chips Atmel ATMEGA y XMEGA que admite una API de nivel de usuario para actualizar el firmware en el chip a través de un protocolo arbitrario. El gestor de arranque se llama xboot y está disponible en github. Básicamente, la aplicación de usuario puede descargar el código como quiera. Pasa de bloque a bloque a xboot, que lo escribe en la mitad superior de la memoria flash. Una vez hecho esto, pasa a xboot el CRC 'dorado' del nuevo firmware y se reinicia. xboot verificará el CRC y, si coincide, copiará el firmware en la mitad inferior de la memoria flash. Luego, salta al vector de reinicio en la mitad inferior de la memoria flash para iniciar el programa. El único inconveniente es que su programa debe tener menos de la mitad del tamaño de la memoria flash. Además, el bloque de arranque debe ser lo suficientemente grande como para contener xboot. Por lo tanto, debería funcionar en el -328 atmega del Arduino, pero es demasiado grande para el -168.

    
respondido por el alex.forencich

Lea otras preguntas en las etiquetas