Un gestor de arranque es un programa que se ejecuta en el microcontrolador para ser programado. Recibe nueva información del programa externamente a través de algunos medios de comunicación y escribe esa información en la memoria del programa del procesador.
Esto está en contraste con la forma normal de llevar el programa al microcontrolador, que es a través de un hardware especial integrado en el micro para ese propósito. En PIC, esta es una interfaz similar a SPI. Si recuerdo bien, los AVR usan Jtag, o al menos algunos de ellos lo hacen. De cualquier manera, esto requiere un hardware externo que mueva los pines de programación para escribir la información en la memoria del programa. El archivo HEX que describe el contenido de la memoria del programa se origina en una computadora de propósito general, por lo que este hardware se conecta a la computadora por un lado y los pines especiales de programación del micro por el otro. Mi compañía hace programadores de PIC, entre otras cosas, como actividad secundaria, por lo que estoy bastante familiarizado con este proceso en PIC.
El punto importante de la programación externa a través de hardware especializado es que funciona independientemente de los contenidos existentes de la memoria del programa. Los microcontroladores comienzan con la memoria del programa borrada o en un estado desconocido, por lo que la programación externa es el único medio para obtener el primer programa en un micro.
Si está seguro del programa que desea cargar en su producto y sus volúmenes son lo suficientemente altos, puede tener el programa del fabricante o un distribuidor para usted. El chip se suelda a la placa como cualquier otro chip, y la unidad está lista para funcionar. Esto puede ser apropiado para algo como un juguete, por ejemplo. Una vez que el firmware está listo, está prácticamente terminado y se producirá en grandes volúmenes.
Si sus volúmenes son más bajos, o lo que es más importante, espera un desarrollo continuo de firmware y correcciones de errores, no desea comprar chips preprogramados. En este caso, se montan chips en blanco en la placa y el firmware debe cargarse en el chip como parte del proceso de producción. En ese caso, las líneas de programación de hardware deben estar disponibles de alguna manera. Esto puede ser a través de un conector explícito o pads de pin pogo si está dispuesto a crear un accesorio de prueba de producción. A menudo, dichos productos deben probarse y calibrarse de todos modos, por lo que el costo adicional de escribir el programa en el procesador suele ser mínimo. A veces, cuando se utilizan pequeños procesadores, se carga primero un firmware de prueba de producción especial en el procesador. Esto se utiliza para facilitar las pruebas y la calibración de la unidad, entonces el firmware real se carga después de que se sabe que el hardware es bueno. En este caso, hay algunas consideraciones de diseño de circuito para permitir el acceso a las líneas de programación lo suficiente como para que el proceso de programación funcione, pero también para no molestar demasiado al circuito. Para más detalles sobre esto, vea miescritura de programación en circuito .
Hasta ahora todo bien, y no se necesita ningún gestor de arranque. Sin embargo, considere un producto con firmware relativamente complejo que desee actualizar en el campo o incluso permitir que el cliente final se actualice. No puede esperar que el cliente final tenga un dispositivo de programador, o sepa cómo usar uno correctamente, incluso si usted lo proporcionó. En realidad, uno de mis clientes hace esto. Si compra su opción de personalización de campo especial, obtiene uno de mis programadores con el producto.
Sin embargo, en la mayoría de los casos solo desea que el cliente ejecute un programa en una PC y tenga el firmware actualizado mágicamente. Aquí es donde entra un gestor de arranque, especialmente si su producto ya tiene un puerto de comunicaciones que puede interactuar fácilmente con una PC, como USB, RS-232 o Ethernet. El cliente ejecuta un programa de PC que habla con el gestor de arranque que ya está en el micro. Esto envía el nuevo binario al gestor de arranque, que lo escribe en la memoria del programa y luego hace que se ejecute el nuevo código.
Suena simple, pero no lo es, al menos no si quieres que este proceso sea robusto. ¿Qué sucede si se produce un error de comunicación y el nuevo firmware está dañado cuando llega al gestor de arranque? ¿Qué pasa si la energía se interrumpe durante el proceso de arranque? ¿Qué pasa si el gestor de arranque tiene un error y craps en sí mismo?
Un escenario simplista es que el gestor de arranque siempre se ejecuta desde el reinicio. Intenta comunicarse con el host. Si el host responde, le dice al gestor de arranque que no tiene nada nuevo o le envía un código nuevo. A medida que llega el nuevo código, se sobrescribe el código anterior. Siempre incluye una suma de verificación con el código cargado, para que el gestor de arranque pueda saber si la nueva aplicación está intacta. De lo contrario, permanece en el gestor de arranque solicitando constantemente una carga hasta que algo con una suma de verificación válida se cargue en la memoria. Esto puede ser aceptable para un dispositivo que siempre está conectado y posiblemente donde se ejecuta una tarea en segundo plano en el host que responde a las solicitudes del cargador de arranque. Este esquema no es bueno para las unidades que son en gran medida autónomas y solo ocasionalmente se conectan a una computadora host.
Por lo general, el gestor de arranque simple como se describió anteriormente no es aceptable ya que no hay seguridad contra fallas. Si una nueva imagen de la aplicación no se recibe intacta, desea que el dispositivo continúe ejecutando la imagen anterior, que no esté muerta hasta que se realice una carga exitosa. Por esta razón, generalmente hay dos módulos especiales en el firmware, un cargador y un cargador de arranque. El cargador es parte de la aplicación principal. Como parte de las comunicaciones regulares con el host, se puede cargar una nueva imagen de la aplicación. Esto requiere memoria separada de la imagen principal de la aplicación, como una EEPROM externa o usar un procesador más grande para que la mitad del espacio de memoria del programa se pueda asignar al almacenamiento de la nueva imagen de la aplicación. El cargador solo escribe la nueva imagen de la aplicación recibida en alguna parte, pero no la ejecuta. Cuando se reinicia el procesador, lo que podría ocurrir a pedido del host después de una carga, Se ejecuta el gestor de arranque. Este es ahora un programa totalmente autónomo que no necesita capacidad de comunicación externa. Compara las versiones actuales y cargadas de la aplicación, verifica sus sumas de verificación y copia la nueva imagen en el área de la aplicación si las versiones difieren y la nueva suma de verificación de la imagen verifica. Si la nueva imagen está dañada, simplemente ejecuta la aplicación anterior como antes.
He hecho muchos cargadores de arranque, y no hay dos iguales. No hay un gestor de arranque de propósito general, a pesar de lo que algunas de las compañías de microcontroladores quieren que creas. Cada dispositivo tiene sus propios requisitos y circunstancias especiales para tratar con el host. Estas son solo algunas de las configuraciones del cargador de arranque y, a veces, del cargador que he usado:
- Gestor de arranque básico. Este dispositivo tenía una línea en serie y se conectaría a un host y se encendería según sea necesario. El gestor de arranque se ejecutó desde el reinicio y envió algunas respuestas de solicitud de carga al host. Si el programa de carga se estaba ejecutando, respondería y enviaría una nueva imagen de la aplicación. Si no respondía dentro de 500 ms, el gestor de arranque se daría por vencido y ejecutaría la aplicación existente. Por lo tanto, para actualizar el firmware, primero tenía que ejecutar la aplicación de actualización en el host, luego conectar y encender el dispositivo.
- Programa de cargador de memoria. Aquí utilizamos el siguiente PIC de tamaño superior que tenía el doble de memoria de programa. La memoria del programa se dividió aproximadamente en el 49% de la aplicación principal, el 49% de la nueva imagen de la aplicación y el 2% del gestor de arranque. El gestor de arranque se ejecutará desde el reinicio y copiará la nueva imagen de la aplicación en la imagen de la aplicación actual en las condiciones adecuadas.
- Imagen EEPROM externa. Como # 2, excepto que se usó una EEPROM externa para almacenar la nueva imagen de la aplicación. En este caso, el procesador con más memoria también habría sido físicamente más grande y en una subfamilia diferente que no tenía la combinación de periféricos que necesitábamos.
- Cargador de arranque TCP. Este fue el más complejo de todos. Se usó un PIC 18F grande. El último 1/4 de memoria más o menos contenía el gestor de arranque, que tenía su propia copia completa de una pila de red TCP. El gestor de arranque se ejecutó desde el reinicio e intentó conectarse a un servidor de carga especial en un puerto conocido en una dirección IP configurada previamente. Esto fue para grandes instalaciones donde siempre había una máquina de servidor dedicada para todo el sistema. Cada pequeño dispositivo se registraría con el servidor de carga después del reinicio y se le daría una nueva copia de la aplicación, según corresponda. El gestor de arranque sobrescribirá la aplicación existente con la nueva copia, pero solo la ejecutará si la suma de comprobación está marcada. De lo contrario, volvería al servidor de carga e intentaría nuevamente.
Dado que el gestor de arranque era en sí mismo un código complicado que contenía una pila de red TCP completa, también tenía que ser actualizable en campo. La forma en que lo hicimos fue hacer que el servidor de carga lo alimentara como una aplicación especial cuyo único propósito era sobrescribir el cargador de arranque una vez que se ejecutó, y luego reiniciar la máquina para que el nuevo cargador de arranque se ejecute, lo que haría que el servidor de carga envíe el última imagen de la aplicación principal. Técnicamente, una falla de energía durante los pocos milisegundos que tomó la aplicación especial para copiar una nueva imagen sobre el gestor de arranque sería una falla irrecuperable. En la práctica esto nunca sucedió. Estábamos de acuerdo con la muy improbable posibilidad de que eso ocurriera, ya que estos dispositivos eran partes de grandes instalaciones donde ya había personas que harían mantenimiento en el sistema, lo que ocasionalmente significaba reemplazar los dispositivos integrados por otras razones de todos modos.
Esperemos que pueda ver que hay una serie de otras posibilidades, cada una con sus propias compensaciones de riesgo, velocidad, costo, facilidad de uso, tiempo de inactividad, etc.