Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Bootloaderuspparapic18f4550 110129113532 Phpapp01 PDF
Bootloaderuspparapic18f4550 110129113532 Phpapp01 PDF
BootLoader USB
Multiplataforma para
el PIC18F4550
Implementación de un BootLoader para el PIC18F4550 con conexión USB
utilizando la clase CDC (Communications Device Class) y desarrollo de la
aplicación de escritorio en un entorno Multiplataforma que permita la carga de
programas de usuario desde PCs con diferentes Sistemas Operativos.
Biblioman
www.AquiHayApuntes.com
28/01/2011
BootLoader USB Multiplataforma para el PIC18F4550
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?
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.
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).
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).
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.
¿Qué es Qt?
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.
Windows:
Linux:
Ventajas de utilizar Qt
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 11
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.
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);
}
}
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.
En Windows:
http://www.youtube.com/watch?v=L1K5TKjMJCw
En Linux:
http://www.youtube.com/watch?v=ncU0cdnGwhk
En MAC:
Están pendientes las pruebas en este sistema operativo, puedes seguir las
actualizaciones de este software en el siguiente hilo del foro de aquihayapuntes.com
Fuentes de Información
Qt
Marcas registradas
Las marcas citadas en este artículo así como las imágenes 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
Versión: 1.01
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.