Porting de GCC a PIC16

Documento: Programador por puerto paralelo para PIC 20 noviembre, 2006

Recapitulando un poco los documentos de orientación del proyecto, la primera falta que podemos encontrarnos es la imposibilidad de grabar código ensamblador en el microcontrolador. Bien, si tenemos código ensamblador con ayuda de las gputils y de uno de sus programas, el gpasm, podemos obtener el código hexadecimal listo para grabar en el microcontrolador. Pero para grabarlo necesitamos dos cosas, un dispositivo hardware y otro software. El software puede ser odissey (1) para linux o icprog (2) para windows, entre otros muchos, pero el hardware es el mismo para todos los sistemas operativos.

Hay mucha diversidad de hardware para grabar los microcontroladores PIC pero el más fácil de crear es el programador por puerto paralelo. Por ahora veremos éste pero podemos encontrar propuestas que usan tanto el puerto serie como el puerto USB (ver 3). El principal problema de los que usan USB es su precio, y personalmente el problema del puerto serie es que mi portátil no tiene : ).

El principio de funcionamiento de del programador se basa en la programación usando el protocolo ICSP de Michochip. Por ello se puede usar pinchando el PIC en un zócalo convenientemente dispuesto en el programador o con el microcontrolador soldado a la placa definitiva. Para la segunda opción tendremos que haber considerado esa opción en el desarrollo de la placa.

La programación según el modelo ICSP usa cinco líneas. Tres de alimentación y dos para la programación en si. Las líneas de programación son DATA y CLOCK, las cuales no nos es difícil adivinar que se usan para datos y reloj. Las líneas de alimentación son VPP para la tensión de programación de 13,2 voltios, y VCC y GND para 5 y 0 voltios. Los microcontroladores que admiten ICSP tienen pines que corresponden con estas cinco entradas, estando algunas veces duplicadas algunas de las mismas como es el caso de nuestro micro donde se usan dos entradas de GND. No tiene mayor misterio que puentearlas.

El principio de funcionamiento de ICSP es, alimentar el microcontrolador normalmente, pero elevar la tensión en el pin MCLR a VPP, la tensión de programación. El microcontrolador entrará con ésta acción en el modo programación y los pines marcados como DT y CK funcionarán como datos y reloj para, a través del protocolo indicado por la especificación ICSP, escribir o incluso leer (en caso de que no este protegido) la memoria de nuestro PIC.

El modelo de programación por puerto paralelo se basa en escribir directamente los unos y ceros en pines del puerto paralelo conectados a los pines adecuados del microcontrolador. La alimentación se ha de conseguir de forma externa al programador. La línea DATA puede no solo escribir datos, sino también leerlos, por lo que usaremos dos pines uno de entrada y otro de salida según la utilización del puerto. Usaremos otro pin del puerto paralelo para controlar la entrada de 13,2 voltios, activándola o no, para entrar al modo programación del chip.

Con esto en mente cualquiera puede realizar este programador que es una simple prolongación del puerto paralelo a la interface ICSP del micro. Sin embargo hay ciertas recomendaciones, que cuando las sigamos, nos ahorraremos muchos problemas en la programación. Para ir más rápidos primero observemos la figura siguiente:

Lo primero que no hemos comentado y que resulta la parte más llamativa del programador es el integrado 74LS04N. Este contiene seis inversores, de los que hemos usado tres, dos para la línea DATA y uno para CLOCK. A nivel lógico hemos invertido las líneas, pero en el software lo indicaremos así y no habrá diferencia en la operación, pero sin embargo a nivel eléctrico, asegura que pese a que el nivel de intensidad en el puerto paralelo sea bajo, entregamos suficiente potencia para que la comunicación sea efectiva. Además protegemos al puerto paralelo de posibles malas conexiones, dejando el posible daño en este integrado. Hay otros muchos circuitos que se podían haber usado en su lugar, pero el 74LS04 es barato, fácil de encontrar y funciona.

Como anunciamos la tensión de programación se controla con un simple pin del puerto paralelo gracias al transistor 2N3904. La configuración muestra que funciona como inversor de la señal de entrada, con lo que si introducimos un nivel alto a la base del transistor este conducirá entre emisor y receptor y llevará la entrada MCLR a cero. Con un nivel bajo, introducimos la tensión dada por VPP, estableciendo el micro en estado de programación.

Pese a decir que un simple pin realiza la entrada no estamos ni mintiendo ni nos hemos equivocado de figura. Vemos que la entrada a la base de transistor puede venir de dos pines distintos del puerto paralelo. La elección de cual escoger la da el dispositivo a programar, dado que si tiene 28 pines o más, el programador debe usar el pin 6 y en caso contrario usará el pin 5. La distinción en estos dos estados es la diferencia de distribución encontrada entre estos dos grupos. En un programador con un solo zócalo, se pueden duplicar el transistor y conducir las otras líneas a todas las posibilidades. En este caso se ha decidido usar un mismo conector ICSP que puede usarse con varios zócalos, localizando en los mismos las posiciones deseadas.

Tenemos cuatro clases de zócalos que cubren la mayoría de los dispositivos PIC y se clasifican según el número de pines del integrado a programar. Se muestran en la figura siguiente. Los dispositivos que no se anexan a ninguna clase, nos obligaran a o bien crear el zócalo oportuno o usarlo desde el circuito con las restricciones normales.

El programador no esta completo sin una fuente de alimentación de la que podamos tomar 0, 5 y 13.2 voltios. Una posible es la que se presenta en el esquema de la figura siguiente.

Básicamente esta fuente de alimentación toma un voltaje de al menos 15 Voltios, y nos entrega 5 y 13,2. Con el condensador C1 estabilizamos la entrada. El integrado 78L12 consigue a su salida 12 voltios, por lo que usando las resistencias R1 y R2 introducimos 1,2 como referencia de tierra del integrado, consiguiendo que este entrege 12 voltios sobre 1.2, resultando los 13.2 necesarios para la tensión de programación. Con el integrado 78L05 conseguimos los 5 voltios para VCC. El condensador C2 simplemente estabiliza aún más la señal. Para la entrada de 15 voltios (o más) podemos usar cualquier transformador de alterna a continua de 12 voltios no regulado o 15 regulados. Lo único a tener en cuenta es que el máximo voltaje es de 35 voltios.

Como contras o desventajas de este programador nos encontramos con la necesidad de usar un alimentador externo, con el consiguiente aumento de volumen del programador e incapacidad de usarlo de forma portátil, sino es en conjunción de pilas externas de alto voltaje, pero en todo caso incomodo.

Como ventajas es más fácil de crear y depurar para iniciados y una vez conectado siempre funciona. Por ejemplo podemos sustituir las salidas ICSP con diodos led con sus resistencias adecuadas para comprobar el funcionamiento correcto del programador antes de arriesgarnos a pinchar un chip. Además no tiene problemas con puertos de baja intensidad.

La idea inicial está basada en el programador «Pablin 2», basado éste a su vez en el programador «propic 2». El original, el «propic 2», estaba pensado para usar con un solo zócalo ZIF (inserción de fuerza cero) por lo que triplicaba los transistores para seleccionar tres configuraciones distintas. También controlaba el VCC activando y desactivando éste para limitar su operación. En el programador «Pablin 2» se duplican las puertas inversoras en las tres líneas para evitar la inversión de la señal, y se usan cuatro zócalos para los distintos chips soportados.

El principal problema del programador «Pablin 2» es que no regula la entrada de 13.2 voltios, sino que supone que una entrada de 12 voltios no regulada o 15 regulados unidos a un diodo led, llevarían a un rango válido para el voltaje VPP. Esta presunción podría funcionar en microcontroladores permisivos, pero no en la gran mayoría de ellos. Un transformador de 12 voltios no regulados entrega unos 16,97 voltios. La caída de tensión en un led verde (de los led normales el de mayor caída) es de unos 2.4 voltios, dando 14.57 voltios, superior a los 14 máximos aconsejados y con una fuente de 15 regulada, obtenemos 12.6 V insuficiente para el voltaje de programación. No solo no conseguiríamos programar un PIC sino que lo pondríamos en peligro. La razón de su extendido uso es que sí es acto para el 16F84 chip famoso por su precio, su benevolencia ante errores de diseño y ser generoso en rango.

Estos problemas quedan solucionados con el uso del integrado 78L12 y el divisor de tensión visto en el programador presentado con lo que conseguimos la generalidad y operatividad buscada sin incrementar apenas el coste.

1) http://www.desert.cx/odyssey/downloads.php
2) http://www.ic-prog.com/
3) http://www.hobbypic.com/index.php?option=com_content&task=view&id=12&Itemid=34

Documento: Compilar Porting de GCC a 16F877 15 noviembre, 2006

Para poder compilar GCC con la arquitectura PIC necesitamos obviamente las fuentes de GCC (1) y las fuentes del porting de PIC (2). La versión de GCC utilizada es 4.0.2. Podría funcionar en otras versiones pero puede requerirse pequeñas modificaciones. Además necesitamos las GPUTILS (3) para poder compilar el código ensamblador generado. Empezamos descargando todas las fuentes desde los enlaces a pie de noticia o utilizando paquetes preparados para las distribuciones empleadas.

Para instalar GPUTILS desde el código fuente, descomprimimos el archivo descargado:

tar xvf gputils-0.13.4.tar.gz

Una vez descomprimido, cambiamos a la carpeta creada gputils-0.13.4 y configuramos:

./configure

Creamos los ejecutables:

make

Y una vez compilado podemos bien ejecutarlos desde sus subdirectorios gpasm/gpasm, gplink/gplink y gputils/gplib o instalarlos y ejecutarlos sin miramientos, opción preferida (la ruta por defecto es /usr/bin si se cambia se deberá cambiar también en el archivo pic.h del parche para el porting GCC). Para instalarlo, usamos

make install

Con lo que ya podemos ensamblar código PIC a código hex para poder grabarlo en un microcontrolador.

Seguimos con GCC. Descomprimimos GCC,

tar xvf gcc-4.0.2.tar.bz2

Descomprimimos el parche de la arquitectura PIC (la versión más reciente)

tar xvf csl-pic-gcc-16f877-0.0.5.tar.gz

Con esto tenemos un directorio llamado gcc-4.0.2 que contiene las fuentes de GCC preparadas para la arquitectura PIC. Pero esta vez no usaremos este directorio para compilar GCC sino que creamos otro

mkdir pic-gcc

y desde dentro lo configuramos

cd pic-gcc
../gcc-4.0.2/configure -target=pic -enable-languages=c

Una vez configurado lo creamos y esperamos un rato (en un Celeron 2400 con 192Mg unos 10-15 minutos).

make

Cuando acabe (por ahora fallando con un AQUÍ) se habrá creado varios ejecutables en pic-gcc/gcc/ . Por ahora solo importa cc1 que compilará código C simple de un byte (es decir con tipos short o char y una sola función main). Poco a poco se conseguirá compilar todo el ANSI C. El código complicado (y por ahora todo lo que se salga de lo muy básico) fallará pero se puede ir comprobando el aumento de características del porting poco a poco.

Nos vemos.

1) ftp://ftp.gnu.org/gnu/gcc/gcc-4.0.2/gcc-4.0.2.tar.bz2
2) http://forja.rediris.es/frs/?group_id=101
3) http://sourceforge.net/project/showfiles.php?group_id=41924

Documento: Archivos de un porting 12 noviembre, 2006

Cuando nos enfrentamos al porting de GCC a una nueva arquitectura, el primer paso es modificar convenientemente el fichero «config.sub» de la raíz de directorios de GCC. El fichero «config.sub» es la base de datos de gcc de arquitecturas y sistemas operativos soportados. Por lo tanto debemos unir nuestra arquitectura `pic’ a la lista de máquinas básicas. Lo dicho se traduce en sumar, dentro del fichero, los siguientes datos:

case $basic_machine in
…
| pdp10 | pdp11 \
| pic \
| pj | pjl \
Con esto le decimos a GCC a la arquitectura PIC existe y es válida dentro de algún producto GNU. Para conseguir que el mismo GCC lo soporte, debemos modificar otro fichero, el de configuración. Para ello tenemos dos maneras de hacerlo, modificar el fichero configure.in y ejecutar posteriormente autoconf para regenerar el ejecutable configure o modificar éste directamente. Elegir una opción u otra no influye si seguimos los pasos adecuados al compilar, es decir, no olvidar ejecutar autoconf si elegimos modificar configure.in. En ambos casos para encontrar la sección adecuada podemos buscar la arquitectura avr e introducir los siguientes datos a continuación de ella:

avr-*-*)
noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 ${libgcj}"
;;
pic-*-*)
noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 ${libgcj}"
;;
Modificados estos dos ficheros, GCC conoce la arquitectura PIC y podrá compilarla. La definición de la arquitectura estará en un directorio llamado pic dentro del subdirectorio gcc/config. Allí no solo podemos crear la nueva arquitectura sino examinar las otras ya existentes. Como ejemplo podemos ver la simplicidad de la arquitectura stormy16 o la complejidad de la arquitectura i386.

Los ficheros principales que describen la arquitectura y que serán el centro de trabajo fundamental durante el transcurso de este proyecto son:

• pic.md
• pic.h
• pic.c

El primer fichero, pic.md, contiene la descripción de la máquina (Machine Description). Allí encontraremos como GCC tiene que traducir las instrucciones del lenguaje intermedio de registros RTL a código ensamblador funcional para nuestra arquitectura. Este fichero a su vez puede contener inclusiones de otros ficheros que contendrán el mismo tipo de datos. El objetivo de usar estos ficheros incluidos es la claridad en la presentación, ya que no imponen ningún cambio funcional.

El fichero pic.h contiene la especificación de la máquina. El objetivo es especificar macros de describen a GCC como funciona interiormente la máquina. Entre otras informaciones indica el número de registros, su uso y nombre, la alineación requerida para los datos o como nombrar las distintas sección dentro del código ensamblador. Para algunas macros no nos bastará un descripción corta en linea o esta sería muy compleja, por lo que podemos usar funciones C externas y que serán definidas en el fichero pic.c. Este último fichero puede contener también funciones C llamadas desde pic.md para aquellas instrucciones RTL que no sean fácil de pasar a código ensamblador o necesiten ciertas comprobaciones. GCC usa la información de pic.h para crear el código RTL adecuado a la máquina y saber como optimizarlo.

A parte de estos ficheros existen otros que sirven de apoyo a la descripción de la máquina. Por ejemplo con la pareja t-pic y libgcc.S podemos definir rutinas directamente en ensamblador que servirán para crear la librería libgcc, que contiene todas las operaciones matemáticas que no sean soportadas directamente por la arquitectura y si por el estándar ANSI C. En estos ficheros podemos incluir rutinas de apoyo para otras operaciones. Pensemos por ejemplo que una operación de división, esta es muy costosa espacialmente, y si la usamos varias veces a lo largo del código C tendremos un gasto excesivo de memoria de programa. Si en lugar de usarla directamente la incluimos en la librería como una rutina y en cada uso de la división simplemente realizamos una llamada a la rutina de librería, conseguiremos un recorte en el tamaño del código sin demasiado gasto temporal.

Conocidos los ficheros que forman la descripción de la arquitectura PIC para GCC, ya solo falta rellenarlos. Para la próxima entrega de documentación explicaré la idea que se desarrollará a partir de ahora, salvos futuros (y más que probables) cambios.