BootLoader USB Multiplataforma para el PIC 18F4550
En este artículo trataremos sobre como implementar un BootLoader con conexión USB para PIC18f4550
MICROCONTROLADORES
Biblioman
1/29/201112 min read
En este artículo trataremos sobre como implementar un BootLoader con conexión USB para PIC18f4550. El BootLader se comunicará con una aplicación de escritorio Multiplataforma para que lo podamos utilizar desde el Sistema Operativo que deseemos.
¿Qué es un BootLoader?
Un BootLoader para Microcontroladores se puede definir como un programa residente en el Microcontrolador (en este caso un PIC) que facilita la carga de los programas del usuario.
El BootLoader hay que programarlo en el PIC de forma convencional a través de un programador externo como el ICD-U64, ICD3, PICkit 3, etc. Una vez programado el BootLoader la carga de los programas de usuario se hacen directamente a través de un canal de comunicación, este canal puede ser el puerto serie, paralelo o USB de nuestro ordenador, en este caso el archivo .HEX se transfiere al PIC a través de una pequeña aplicación de escritorio que hace de interfaz entre el PC y el firmware del Microcontrolador, pero también se suelen utilizar otros buses de comunicación como el bus CAM, SPI, I2C, etc.
Ventajas de utilizar un BootLoader
Los BootLoaders llevan ya tiempo utilizándose en el mundo de los Microcontroladores
y su uso ha sido fundamental en el éxito de muchos proyectos populares como: Arduino, Pinguino, Netduino, etc. Estos proyectos basan su éxito en facilitar al usuario una plataforma económica con la que empezar a programar los Microcontroladores y para ello es fundamental el abaratar costes, como el no tener que utilizar un programador externo para cargar las aplicaciones de usuario. Estas placas de desarrollo vienen ya con el Bootloader cargado en la memoria flash del PIC, por lo que no se necesita de ningún Hardware adicional para empezar a programar el Microcontrolador insertado en la placa de desarrollo.
Pero esta no es la única ventaja de utilizar un BootLoader, otra ventaja la tenemos en que podemos actualizar el programa de usuario cargado en el Microcontrolador de manera fácil y sin necesidad de sacar el Micro fuera de la placa donde esté montado. Por ejemplo un módulo de control instalado en un automóvil que utilice Microcontroladores no se desmonta para actualizar su software, su actualización se realiza a través de puntos de control (SetPoints) accesibles por el técnico de mantenimiento y que se comunican con la unidad de control a través de un canal de comunicación como el bus CAN (muy utilizado en la industria automovilística).
Inconvenientes
El inconveniente principal e inevitable de utilizar un BootLoader, ya podéis imaginar cual es, el gasto de memoria ROM que implica el tenerlo cargado en la memoria del PIC de forma permanente, pero este no es el único inconveniente que tenemos cuando utilizamos un BootLoader, la reubicación en memoria del vector o vectores de interrupción (cuando sea necesario) provoca un incremento en la latencia del Micro, de tal forma que cada vez que se produzca una interrupción será necesario ejecutar dos instrucciones mas como mínimo para reubicar los vectores de interrupción en las nuevas posiciones de memoria.
Si queremos utilizar debuggers en circuito como el ICD-U64 hay que tener en cuenta también el rango de direcciones reservadas para cargar el programa de depuración (normalmente registros de la parte alta de la memoria ROM).
Lógicamente todo este tipo de inconvenientes está estrechamente relacionado con la ubicación del BootLoader (parte alta o baja de la memoria Flash), en el siguiente punto veremos algunas consideraciones que nos pueden ayudar a determinar en qué posición de la memoria cargar el BootLoader.
Consideraciones de diseño
Una de las metas que debe perseguir el diseño de un Bootloader y que muchas veces es tema de discusión, es que debe de ocupar el menor espacio posible en la memoria flash del Micro, sin embargo esto es relativo y depende del canal de comunicación que se utilice para cargar la aplicación de usuario en el Microcontrolador, por ejemplo: si utilizamos un Microcontrolador que implementa el módulo necesario para una conexión USB como el PIC18F4550 y queremos que el bootloader utilice ese canal de comunicación para cargar el programa de usuario, el firmware del Bootloader debe de incluir el «stack» correspondiente a la comunicación USB. Por lo tanto un Bootloader que utilice como canal de comunicación un puerto USB siempre ocupara mas memoria ROM que otro que utilice un puerto COMM serie.
Otro tema que se tiene que tener en cuenta en el diseño del Bootloader es la protección de las direcciones de memoria donde está cargado el BootLoader para evitar su sobre escritura. Esto se puede hacer de dos formas: por software o por hardware.
Protección por software: cuando la protección es por software es el propio firmware del BootLoader el que se tiene que encargar antes de escribir en la memoria flash un nuevo programa de usuario que las direcciones implicadas en la operación de escritura no pertenezcan a las direcciones donde está guardado el propio BootLoader.
Protección por Hardware: algunos dispositivos pertenecientes a la familia PIC18 como el PIC18F46J11 y otros, permiten la protección contra escritura de un número determinado de registros de la parte baja de la memoria flash a través de los fusibles de configuración del PIC. Sin embargo la mayoría de dispositivos solo permiten la protección de escritura de los registros del principio de la memoria Flash. Si queremos utilizar la protección por hardware para estos dispositivos deberemos ubicar el BootLoader al principio de la flash, por contra si utilizamos la parte alta de la memoria para cargar el bootloader tendremos el inconveniente de tener que re direccionar el vector o vectores de interrupciones, con el incremento en la latencia que ello implica.
Por tanto no existe una solución única para todos los casos, siempre dependerá de las características del PIC a utilizar, del tipo de protección que queramos emplear, de si vamos a utilizar debuggers o no, etc.
Empezando con el BootLoader
El trabajo de diseñar un BootLoader para Microcontroladores que cargue la aplicación de usuario a través de un puerto de comunicación del PC se puede dividir en dos apartados, por un lado está el diseño del propio BootLoader que tendremos que cargar en el Microcontrolador y por otro lado está el diseño de la aplicación de escritorio necesaria para poder enviarle el archivo .HEX al Bootloader.
En este ejemplo vamos a utilizar un BootLoader con conexión USB que utiliza la clase CDC (Communications Device Class) para comunicarse con el PC, esta clase se caracteriza por crear un puerto COMM virtual en el ordenador donde se conecta el dispositivo y no necesita la instalación de ningún driver en el Sistema Operativo para su funcionamiento (en Windows es necesario la instalación del archivo .INF).
La parte correspondiente al firmware del BootLoader de este tutorial está basado en el ejemplo EX_USB_BOOTLOADER.C que trae el compilador de CCS y que podemos encontrar en el directorio donde instalamos el compilador, si en la instalación dejamos la opción por defecto ese directorio será C:\Archivos de programa\PICC\Examples.
El principio de funcionamiento en que se basa un BootLoader para saber si debe de cargar una nueva aplicación de usuario o ejecutar la que en ese momento se encuentre en la memoria flash del PIC es la siguiente: después de un reset en el PIC el BootLoader espera la llegada de un evento que determine qué acción ejecutar, ese evento puede ser provocado por Hardware (por ejemplo el cambio de estado en un determinado PIN del PIC) o por Software (la llegada de un determinado comando por un canal de comunicación como la USART del PIC).
En este ejemplo utilizaremos la detección de un evento Hardware que consiste en chequear el estado de la patilla RD0 del PIC, si está a nivel bajo el BootLoader procederá a cargar una nueva aplicación de usuario en la memoria ROM del PIC, si RD0 es diferente de cero (Nivel Alto) se ejecutará la aplicación de usuario que en ese momento tenga cargado el PIC.
En la figura de abajo se muestra un diagrama de estados de este escenario:
Como hemos comentado antes el firmware del BotLoader se puede programar para que utilice los registros de la parte alta o baja de la memoria flash del PIC, nosotros utilizaremos la parte baja de la memoria ROM para ubicar allí nuestro BootLoader y nos ahorraremos el tener que re-direccionar los vectores de interrupción.
En realidad el trabajo en cuanto a programación se refiere de hacer esto se reduce bastante si nos ayudamos del Wizard que incorpora CCS. Según se muestra en la figura de abajo con un solo clic de ratón seleccionamos el lugar donde queremos ubicar el Bootloader y el asistente se encargará de generar el código necesario. Para ello genera un archivo que se llamará: Nombre_del_Proyecto_bootloader.h incluyendo todo lo necesario para que el BootLoader trabaje en la parte alta o baja de la memoria ROM según hayamos elegido.
Una imagen más detallada de como quedaría mapeada la memoria ROM del PIC la tenéis en la figura de abajo. En ella se puede ver como el vector de reset ahora apunta al comienzo del programa del BootLoader, este determinará según sea el estado de RD0 si debe ejecutar la aplicación de usuario (RD0=1) guardada en memoria o cargar una nueva aplicación de usuario (RD0=0).
Diseño de la Aplicación de escritorio
Una vez que tenemos programado el firmware del BootLoader en nuestro Pic necesitamos una aplicación de escritorio que nos permita enviarle el archivo .HEX a él, para ello tenemos dos opciones:
Utilizar la aplicación SIOW.exe que incorpora CCS y que podemos acceder a ella desde el propio IDE de programación seleccionando Tools-> Serial Port Monitor. Nos aparecerá la ventana de la figura de abajo en la que tendremos que pulsar sobre el icono «Download Software» para seleccionar el archivo .HEX a cargar y enviárselo al BootLoader.
Diseñar nuestra propia aplicación de escritorio, para ello hay que tener en cuenta que la comunicación entre el Bootloader cargado en el PIC y la aplicación de escritorio debe de ser bidireccional y que el protocolo de comunicación serie debe de implementar un control de flujo de datos por software. Esto debe de ser así ya que la velocidad en que la aplicación manda los datos al microcontrolador es mayor que la capacidad que tiene el BootLoader en recibir esos datos, decodificarlos y grabarlos en la memoria Flash del PIC. Para ello el BootLoader utiliza tres caracteres de control: ACK, XON y XOFF. Cada vez que el BootLoader recibe una línea de datos correcta envía un ACK, si el buffer de recepción se llena envía un XOFF para que la aplicación de escritorio deje de enviar datos momentáneamente , cuando esté listo de nuevo enviará un XON para que la aplicación reanude la transmisión de datos.
Para el desarrollo de la aplicación de escritorio se ha utilizado el lenguaje de programación C++ a través del Framework QtCreator.
¿Qué es Qt?
Qt es un conjunto de librerías o bibliotecas que se caracterizan por ser independientes de la plataforma donde se ejecutan y que nos permiten generar interfaces gráficas (GUIs) para muchos sistemas operativos (incluyendo sistemas embebidos) de forma rápida y sencilla. Qt fue creado por la compañía Trolltech en el año 1994 y vendida a Nokia en el año 2008 donde continua su desarrollo, a partir de la versión 4.5 existe una versión con licencia LGPL.
Originalmente Qt solo trabajaba con el lenguaje C++ pero actualmente existen módulos (bindings) para otros lenguajes como Python, Java, Perl, Ruby, PHP, etc.
Aplicaciones que han utilizado Qt para su desarrollo tenemos entre otras las siguientes: Google Earh, Skype, VLC Media Player, Editores de texto como FocusWriter, Qt Creator, ect.
Qt Creator es un entorno de desarrollo integrado (IDE) de software libre y multiplataforma desarrollado por Nokia y es con el que se ha realizado la aplicación de escritorio para el BootLoader.
En las siguientes figuras se muestra el IDE trabajando en diferentes sistemas operativos:
Windows:
Linux:
Ventajas de utilizar Qt
Es un proyecto de Código Abierto y gratuito, de libre distribución.
Es Multiplataforma su código se puede compilar en diferentes sistemas operativos:Windows, Linux, MAC y sistemas embebidos como un teléfono móvil, sin necesidad de hacer cambios en el código fuente.
La compilación es a código nativo con instrucciones máquina y no en código intermedio, por tanto la máquina cliente donde se ejecute la aplicación no necesita la instalación de ninguna máquina virtual como en el caso de Java o .NET
Al utilizar C++ como lenguaje de programación podemos acceder directamente a los puertos del ordenador a través de librerías, sin la necesidad de tener que utilizar librerías dinámicas (.dll) de terceras partes.
Con Qt Creator tienes el mismo IDE para trabajar en diferentes sistemas operativos. Por ejemplo la plataforma .NET se puede decir que es «Multiplataforma» gracias al proyecto Mono, pero el IDE en Windows (Microsoft Visual Studio) es totalmente diferente al IDE para Linux (MonoDevelop).
Qt Creator al igual que cualquier IDE moderno permite crear fácilmente interfaces gráficas por el método de arrastrar y soltar componentes como botones, labels, textbox, etc. Además permite la depuración visual de los programas por medio de la simulación del programa paso a paso, inserción de breakpoint, etc.
Inconvenientes
La verdad es que bajo mi punto de vista prácticamente no le veo inconvenientes, por citar algo decir que para ejecutar las aplicaciones en un sistema que no tenga instaladas las librerías Qt se deben de integrar en la carpeta del ejecutable todos los archivos necesarios que necesita QT para su ejecución, eso implica que una aplicación de usuario por pequeña que sea ocupará como mínimo unos 8 Megas aproximadamente. En este aspecto lo veo exactamente igual que RealBasic.
Para empezar a trabajar con Qt se necesitan dos pre-requisitos que son: saber programar en C++ y conocer la técnica de programación orientada a objetos. De no conocerlos puede llegar a ser un poco frustrante el inicio con Qt.
Creando una aplicación de usuario para cargar con el BootLoader
La única condición necesaria que tenemos que tener en cuenta en el código de nuestra aplicación de usuario si queremos cargarla a través del BootLoader es incluir el archivo de cabecera usb_bootloader.h, este se encarga de re direccionar los vectores de interrupción y de reset así como de reservar el espacio en memoria utilizado por el BootLoader. Un ejemplo sencillo para comprobar que el archivo es cargado en la ROM, podría ser el siguiente:
///////////////////////////////////////////////////////////////////////////////////////
// //
// Ejemplo de Aplicación de usuario para usar con el Bootloader //
// //
// www.AquiHayApuntes.com //
// //
///////////////////////////////////////////////////////////////////////////////////////
#include <18F4550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
//Archivo de cabecera necesario para trabajar con el Bootloader
#include "usb_bootloader.h"
void main(void)
{
while(true){
output_toggle(PIN_B7);
delay_ms(1000);
}
}
El archivo .HEX resultado de la compilación es el que le enviaremos al BootLoader a través de la aplicación de escritorio.
Nota: Si creamos una aplicación que utilice USB la aplicación debe de incluir su propio «stack» USB. El stack del BootLoader es solo para él, ya que la aplicación de usuario no puede acceder a las regiones de memoria del BootLoader.
Ejecución del programa en diferentes sistemas operativos
En Windows:
En Linux:
Fuentes de Información
Qestserialport. Librería para acceso al puerto serie.
Aplicación AN1310 de Microchip
Marcas registradas
Las marcas citadas en este artículo así como las imágenes de programas procedentes de capturas de pantallas pertenecen a sus respectivos propietarios su utilización en este artículo es con fines educativos y sin ánimo de lucro.
Licencia
Autor de este artículo: Biblioman
Página Web: https:\\www.aquihayapuntes.com
email: email.Biblioman@gmail.com
Los comentarios y conclusiones hechos en este artículo son personales y no se garantiza la veracidad de los mismos por parte del autor, para una información más amplia y precisa consultar las fuentes citadas.
Este artículo esta bajo una licencia Creative Commons: Reconocimiento-No Comercial-Compartir bajo la misma licencia.
Puedes descargarte este tutorial o publicarlo en tu blog a través de slideshare
Para cualquier duda contactar con el autor del artículo.
Un saludo