¿Qué es un gestor de arranque, y cómo se desarrollan?

Question

He conocido muchos proyectos que utiliza un microcontrolador AVR con un gestor de arranque (como Arduino), pero no entiendo el concepto muy bien.

¿Cómo puedo hacer un cargador de arranque (para cualquier microcontrolador)?

Después de escribir mi gestor de arranque, ¿cómo se programa al microcontrolador (como cualquier programa .hex en la rom flash de lo AVR, o algún otro método)?

Answer 1

Un bootloader es un programa que se ejecuta en el microcontrolador a programar. Se recibe nueva información sobre el programa externamente a través de algunos medios de comunicación y escribe la información a la memoria de programa del procesador.

Esto está en contraste con la forma normal de conseguir el programa en el microcontrolador, que es a través de un hardware especial integrada en el micro para ese propósito. En las Imagenes, este es un SPI-como el interfaz. Si no recuerdo mal, AVRs usar Jtag, o al menos algunos de ellos. De cualquier manera, esto requiere algo de hardware externo que se menea la programación de alfileres al derecho a escribir la información en la memoria del programa. El archivo HEX que describe el programa de los contenidos de la memoria se origina en un equipo de propósito general, por lo que este hardware se conecta a la computadora por un lado y la programación especial pines del micro en el otro. Mi empresa hace que los programadores de PIC entre otras cosas, como una actividad secundaria, por lo que estoy bastante familiarizado con este proceso en las Imagenes.

El punto importante de programación externo a través de hardware especializado, es que funciona independientemente de los contenidos existentes de la memoria de programa. Los microcontroladores de empezar con el programa de la memoria borrada, o en un estado desconocido, de modo de programación externo es el único medio para obtener el primer programa en una micro.

Si usted está seguro acerca del programa que desea cargar en su producto y sus volúmenes son lo suficientemente altos, usted puede tener el fabricante o distribuidor del programa de fichas para usted. El chip se pone soldados a la placa como cualquier otro chip, y la unidad está listo para ir. Esto puede ser adecuado para algo así como un juguete, por ejemplo. Una vez que el firmware se ha hecho, es bastante mucho por hacer, y se producen en grandes volúmenes.

Si los volúmenes son menores, o lo que es más importante, se espera que en curso de desarrollo de firmware y correcciones de errores, usted no quiere comprar pre-programados fichas. En este caso en blanco chips están montados en el tablero y el firmware tiene que cargar en el chip como parte del proceso de producción. En ese caso, la programación de hardware líneas deben ser puestos a disposición de alguna manera. Esto puede ser a través de una explícita conector, o pogo pin pads si usted está dispuesto a crear una producción fixture de prueba. A menudo, dichos productos tienen que ser probados y tal vez calibrado de todos modos, por lo que el costo adicional de escribir el programa para el procesador suele ser mínima. A veces, cuando los pequeños procesadores se utilizan una producción especial de la prueba de firmware es la primera carga en el procesador. Esto se utiliza para facilitar las pruebas y la calibración de la unidad, entonces el firmware se carga después de que el hardware es conocido por ser bueno. En este caso hay algunas circuito consideraciones de diseño para permitir el acceso a las líneas de programación de manera suficiente para el proceso de programación para trabajar sino también para no molestar al circuito demasiado. Para más detalles sobre esto, véase mi programación en el circuito valoración crítica.

Tan lejos y tan bien, y no bootloader es necesario. Sin embargo, considera un producto relativamente complejo de firmware que desea campo actualizable o incluso permitir que el cliente final para actualizar. Usted no puede esperar que el cliente final para tener un programador gadget, o saber cómo utilizar correctamente incluso si se proporciona uno. De hecho, uno de mis clientes. Si usted compra su campo especial de personalizar opción, usted consigue uno de mis programadores con el producto.

Sin embargo, en la mayoría de los casos sólo quiere el cliente para ejecutar un programa en un PC y tengo el firmware por arte de magia actualizado. Esto es donde un gestor de arranque que viene, especialmente si el producto ya tiene un puerto de comunicaciones que puede interactuar fácilmente con un PC, como USB, RS-232 o ethernet. El cliente ejecuta un programa de PC que se comunica con el gestor de arranque ya en el micro. Esto envía el nuevo binario para el gestor de arranque, que escribe en la memoria de programa y, a continuación, hace que el nuevo código se ejecute.

Suena simple, pero no lo es, al menos no si quieres que este proceso sea robusto. Lo que si es un error de comunicación de la pasa y el nuevo firmware está dañado por el tiempo que se llega en el gestor de arranque? ¿Y si el poder se interrumpe durante el proceso de arranque? ¿Qué pasa si el gestor de arranque tiene un error y el juego de dados en sí mismo?

Una visión simplista escenario es que el gestor de arranque siempre se ejecuta desde el reinicio. Intenta comunicarse con el host. Si el host responde, a continuación, dice que el bootloader no tiene nada nuevo, o lo envía de nuevo código. Como el nuevo código llega, el código antiguo se sobrescribe. Incluir siempre una suma de comprobación con uploaded código, por lo que el gestor de arranque puede decir si la nueva app está intacto. Si no, se queda en el bootloader constantemente pidiendo una subida hasta algo con la validez de una suma de comprobación se carga en memoria. Esto puede ser aceptable para un dispositivo que siempre está conectado y, posiblemente, donde una tarea en segundo plano se ejecuta en el host que responde a gestor de peticiones. Este esquema no es bueno para las unidades que son en gran parte autónoma y sólo de vez en cuando conecte a un ordenador host.

Generalmente el sencillo gestor de arranque como se describe arriba no es aceptable ya que no hay ninguna prueba de fallos. Si una aplicación nueva de la imagen no es recibido intacta, desea que el dispositivo a seguir en la ejecución de la antigua imagen, a no ser muerto hasta que un éxito de la carga se realiza. Por esta razón, por lo general, hay en realidad dos módulos especiales en el firmware, un cargador y un gestor de arranque. El uploader es parte de la aplicación principal. Como parte de la comunicación regular con el host, una nueva aplicación de la imagen se pueden cargar. Esto requiere de memoria independiente de la aplicación principal de la imagen, como una EEPROM externa o utilizar una mayor procesador de la mitad del espacio de memoria de programa puede ser asignado para el almacenamiento de la nueva app de la imagen. El uploader sólo escribe el recibido la nueva app de la imagen en algún lugar, pero no se ejecuta. Cuando el procesador es cero, por lo que podría ocurrir en el comando de host después de una carga, el cargador de arranque se ejecuta. Ahora es totalmente auto-contenidos programa que no necesita de la comunicación externa de la capacidad. Se compara la actual y cargar versiones de la aplicación, comprueba sus sumas de comprobación, y de los ejemplares de la nueva imagen en el área de aplicación si las versiones son diferentes y la nueva imagen de la suma de comprobación de cheques. Si la nueva imagen está dañado, simplemente se ejecuta la app antigua como antes.

He hecho un montón de cargadores de arranque, y no hay dos iguales. No hay ningún propósito general del gestor de arranque, a pesar de lo que algunos de los microcontroladores las empresas quieren que usted crea. Cada dispositivo tiene sus propias necesidades y circunstancias especiales en el trato con el anfitrión. Aquí son sólo algunas de las bootloader y a veces uploader configuraciones que yo he utilizado:

Básica del gestor de arranque. Este dispositivo tenía una línea serie y se conecta a un host y encendido según sea necesario. El gestor de arranque corrió desde el reinicio y envió un par de solicitud de carga de las respuestas para el host. Si la carga del programa se estaba ejecutando, iba a responder y enviar una aplicación nueva de la imagen. Si no responde dentro de los 500 ms, el gestor de arranque se rendiría y ejecutar la aplicación existente. Para actualizar el firmware por lo tanto, había que ejecutar el programa de actualización de la aplicación en el host en primer lugar, a continuación, conecte y encienda el dispositivo.

La memoria de programa uploader. Aquí hemos utilizado el siguiente tamaño de la foto que había el doble de memoria de programa. La memoria de programa fue dividida en 49% de la aplicación principal, el 49% de la nueva app de la imagen, y el 2% del gestor de arranque. El gestor de arranque se extendería desde el reset y copiar la nueva aplicación de la imagen en la aplicación actual de la imagen bajo las condiciones adecuadas.

EEPROM externa de la imagen. Como #2, excepto que una EEPROM externa se utiliza para almacenar la nueva app de la imagen. En este caso, el procesador con más memoria, también habría sido físicamente más grande y en diferentes sub-familia que no tienen la mezcla de los periféricos que necesitábamos.

TCP gestor de arranque. Este ha sido el más complejo de todos ellos. Un gran PIC 18F fue utilizado. El último 1/4 de la memoria o la tan celebrada el gestor de arranque, que tenía su propia copia completa de una red TCP de la pila. El gestor de arranque corrió desde el reinicio y trató de conectarse a una especial carga de servidor en un puerto conocido a una dirección IP configurada previamente. Esto fue para instalaciones grandes donde siempre hubo un servidor dedicado máquina para todo el sistema. Cada pequeño dispositivo de verificación con la carga del servidor después de reiniciar, y que le daría una nueva aplicación de copia, según corresponda. El gestor de arranque, se sobrescribirá la aplicación existente con la nueva copia, pero sólo se ejecuta si la suma de verificación activada. Si no, se iba a volver a la carga del servidor y volver a intentarlo.

Desde el gestor de arranque era de por sí una complicada pieza de código que contiene una completa red TCP pila, tenía que ser de campo actualizable. De la manera en que lo hicimos fue tener la carga de alimentación de servidor es una aplicación especial, cuyo único fin era para sobrescribir el gestor de arranque una vez que se ejecuta, a continuación, reiniciar la máquina para que el nuevo gestor de arranque, lo que provocaría que la carga del servidor para enviar la última de la aplicación principal de la imagen. Técnicamente un fallo de alimentación durante las milésimas de segundo que le tomó a la aplicación especial para copiar una imagen nueva sobre el gestor de arranque sería un error irrecuperable. En la práctica esto nunca sucedió. Estábamos bien con la muy probable posibilidad de que, dado que estos dispositivos eran piezas de grandes instalaciones donde allí ya había gente que se iba a hacer mantenimiento en el sistema, que en ocasiones significó la sustitución de los dispositivos embebidos, por otras razones, de todos modos.

Espero que usted puede ver que hay un número de otras posibilidades, cada una con sus propias ventajas y desventajas, por el riesgo, la velocidad, el coste, la facilidad de uso, tiempo de inactividad, etc.

Answer 2

¿Cuál es el concepto de que el gestor de arranque?

Imagina este escenario: Usted tiene una buena cantidad de almacenamiento en el microcontrolador suficiente para almacenar más de 2-3 programas o aplicaciones que son independientes el uno del otro. Supongamos que al inicio de su dispositivo, es posible que desee ser capaz de elegir la que desee ejecutar. Entonces, lo que usted necesita para apoyar esto? Usted necesita un programa inicial que luego le permite elegir entre las demás, en tiempo de arranque.

Cómo funciona?

Un gestor de arranque es que el programa es la primera cosa que hay que ejecutar y cargar otras aplicaciones en lugares específicos en la memoria (ya sea persistente como FLASH, o volátil, como la memoria RAM) y, a continuación, salta a la deseada programa donde se realizará sobre la ejecución de allí.

Cómo hacer un avr gestor de arranque (o para cualquier microcontrolador)?

Yo nunca he hecho un gestor de arranque, pero esto es lo que yo pienso que yo haría hacer: empezar a escribir un programa de firmware justo como lo haría normalmente, pero asegúrese de que esté colocado en un área que es siempre la primera cosa que se ejecute cuando el dispositivo se inicia. La parte superior de mi cabeza, parte de la funcionalidad que me gustaría que fuera de este pequeño programa: capacidad para cargar un nuevo programa a un lugar disponible en la memoria, borrar previamente cargado el programa, elegir el programa a ejecutar (si hay más de uno), y tienen algún tipo de almacenamiento de datos de estructura (crecer-capaz de saltar de la tabla?) para ser capaz de recordar donde el resto de los programas y saltar a ellos. Interacción puede ser hecho a través de UART donde se puede presentar un terminal sencillo menú y la capacidad para cargar el firmware en el mismo canal.

Cómo está programado el microcontrolador (como cualquier otro .hex programa de quema en la memoria flash rom de la avr, o algún otro método)?

Si está completamente en blanco con el chip de ningún gestor de arranque que puede actualizarse a sí mismo, entonces usted necesita para grabar en FLASH muy similar a la que se describe el uso de cualquier técnica es necesaria para lograr que (ICSP en el caso de AVR).

Esto no es de ningún modo exhaustiva de lo que los "gestores". Dependiendo de lo que usted desea fuera de uno o el sistema que está diseñado para, usted puede diseñar uno para subir cosas a una ubicación especificada en la memoria RAM en lugar de FLASH, y comenzar la ejecución en cualquier lugar de la memoria. O tal vez usted desea uno que es capaz de escoger el sistema operativo que se carga al arrancar su PC (véase el grub , por ejemplo). Gestores de arranque, 8 bits microcontroladores tienden a ser muy simple.

Una nota acerca de Arduino: Este gestor de arranque sólo gestiona un programa de AFAIK, también se lleva a través del puerto serie para gestionar el firmware de la carga y otras cosas.

Answer 3

El concepto de un "boot" cargador es similar al concepto de "priming" de una bomba. En otras palabras, se necesita "algo" que se carga un programa a una determinada dirección y, a continuación, comenzar a ejecutar el programa en la dirección dada. Ese algo, es el gestor de arranque. En el caso más simple, el cargador de arranque "aparece" en la CPU designado por la dirección inicial (cero, lo más probable), se carga el programa en el segmento de memoria, transfiere el control a ella, y "desaparece". La aparición y desaparición son controladas por el "exterior" de hardware. Una posible aplicación sería mediante el uso de una ROM que es activado a través de un "hardware" reset, y desactivarse con un "software" de reset. El cargador en la ROM puede ser tan simple o tan complejo como necesario, y debe ser escrito en la forma binaria que la CPU particular entiende. Si el espacio de direcciones utilizado por la ROM no es necesario, ROM desactivación no sería necesario. Obviamente, EEPROM, ePROM, flash PROM, etc. podría ser utilizado en lugar de la ROM.