Siguenos en ...

Google+facebooktwitter

youtubepinterest RSS aquihayapuntes

Últimos Tutoriales

Licencia

Creative Commons

 

Todo el contenido de este sitio está bajo una licencia de Creative Commons

 

BootLoader USB Multiplataforma para el PIC 18F4550

BootLoader MultiplataformaEn 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:

 

Diagrama de estados del BootLoader

 

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.

 

Ayuda al utilizar el Wizard

 

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).

 

 

Mapeo de la Memoria ROM

 

© 2007-2017 AquiHayapuntes.com