PICs
www.qsl.net/lw1ecp  Ing. Daniel Pérez  LW1ECP  danyperez1 {arrroba} yahoo.com.ar

Una buena página de radioaficionados no está completa sin un capítulo sobre microcontroladores. El problema es que todavía no experimenté mucho en este campo. Pero por esa misma razón puede resultar útil compartir mis primeras experiencias mientras aún estén frescas. A los experimentadores más avanzados los invito a bucear en las abundantes páginas que ya hay sobre el tema, cuyo contenido no voy a duplicar.
Eche un vistazo a los próximos títulos que están en orden creciente de complejidad, identifique cuál es su estado actual en tema microcontroladores, y lea desde allí.

QUÉ ES UN MICROCONTROLADOR (en adelante uC)?
Es un integrado que tiene:
- CPU, es lo que hace cuentas y tareas sencillas (sumar datos, restar, comparar, moverlos de lugar, correr sus bits, etc)
- ROM que es donde se guarda permanentemente las órdenes que debe cumplir la CPU.
- RAM, volátil, donde se guardan los resultados provisorios de las operaciones
- I/O (entrada/salida) para comunicarse con el mundo exterior (las patitas)
- Temporización.
Los microprocesadores (uP), en comparación, tienen CPU más poderosas en cuanto a cálculos, pero sin ROM, RAM ni I/O, lo cual obliga a agregar más integrados alrededor.

QUÉ ES UN "PIC"?
Es una línea de microcontroladores de Microchip (no fueron muy originales con el nombre de la empresa...).
Hay microcontroladores de otras marcas, p. ej. las series de Motorola (6805), Intel (8051), Zilog (Z8), Atmel, etc., c/u de ellas con numerosas variantes. Los primeros teclados de PC tenían adentro un 8051. Pero los Microchip se impusieron bastante en las revistas de electrónica últimamente, no sé si por el precio, publicidad, o porque le acercan información al hobbista de formas más amistosas que los otros.

QUÉ PUEDO HACER CON UN uC?
Los hay de distinto potencial, según la cantidad de RAM, ROM, patas de I/O, frecuencia de clock, cantidad de bits, etc. El más modesto, el PIC16F84-4, en 2001 me costó 7U$D, y con sus escasas 18 patas se lo puede conectar a un teclado hexadecimal, un display LED de 4 dígitos, y hacer muchas cosas que consistan en ingresarle valores, conectarle sensores binarios, tomar decisiones en base a lo mencionado, mostrar resultados en el display, y activar salidas, todo con el agregado de pocos componentes. Un mismo uC, cambiándole lo que se le pone en la ROM (modificable eléctricamente), puede servir para controlar un teclado de PC, un lavarropas automático, una cadena de semáforos, un juguete sofisticado, automatizar un pequeño proceso industrial, decodificar transmisiones digitales de radioaficionados, ser parte de un decodificador para ciertas formas de TV codificada, etc.

QUIERO ARMAR UN CIRCUITO QUE INCLUYE UN uC QUE SE COMPRA YA PROGRAMADO.
Bueno, esto no se diferencia de comprar un circuito integrado standard. No se requiere ningún conocimiento obligatorio acerca del componente. Comúnmente consiste en enviar un pago al autor del artículo y se recibe el uC programado a vuelta de correo.

QUIERO ARMAR UN CIRCUITO CON uC QUE HAY QUE GRABAR.
En este caso, la revista trae el programa, ya sea un listado impreso o en un disco, o un link para bajarlo de la web. Se compra el uC en blanco en una casa de componentes, y junto con el programa se lo damos a alguien que se dedique a grabar ("quemar" o "burn") el programa en el uC.

Nota: prefiero el término "grabar" en vez de "programar" porque éste se confunde con "escribir el programa".

ME ANIMO A GRABARLO YO. EL PROGRAMA TIENE EL ASPECTO "hex" EN FIGURA {EjHexAsm}
- Se ingresa el archivo .hex en una PC, p. ej. tipeándolo con un editor de texto.
- El .hex es leído por un programa grabador instalado en la PC.
- El uC virgen se inserta en un circuito grabador comprado o armado que se conecta a la PC, y tras la grabación queda listo para usarlo en el circuito definitivo. Muchos uC permiten ser borrados y vueltos a grabar en caso de error o para hacer pruebas.
Los .hex son archivos con los bytes (expresados en hexadecimal) que hay que meter en el uC. No están pensados para que los entienda un ser humano como puede apreciarse.
Para los PIC, Microchip ofrece en su sitio el programa PicStart que admite una serie de grabadores comerciales. Una opción casera famosa para los PIC más sencillos es el TOPIC de David Tait, y el similar NOPPP (No Parts PIC Programmer) originado en la desaparecida Popular Electronics y que se puede encontrar en el sitio de Editorial Quark y muchos otros.



ME ANIMO A GRABARLO YO. EL PROGRAMA TIENE EL ASPECTO "asm" EN FIGURA {EjHexAsm}
Entonces hace falta un programa ensamblador antes para convertirlo en .hex. El assembler de Microchip es el MPASM.
En realidad, lo que se encuentra en www.microchip.com es una "suite" de programas, llamada MPLAB, que incluye el PicStart, MPASM, posibilidad de enlazar (link) módulos de soft, simulación del funcionamiento, etc. O sea, un "entorno de programación" para que no haya que salir de un programa y entrar en otro. Es gratis, pero le costará un pedazo de su rígido, y de su tiempo para entender los menús.

NO ES hex NI asm: ESTÁ EN LENGUAJE C o BASIC
En este caso, en vez de ensamblador lo que se requiere es un compilador para obtener el .hex.
Los uC no disponen de abundante ROM y RAM, y estos lenguajes de alto nivel (más comprensibles para el humano) no permiten exprimir tan a fondo el uC como el assembler.

QUIERO HACER MI PROPIO PROGRAMA Y CIRCUITO
Ahhhhh, conque haciéndose el/la valiente?. Es imprescindible haber experimentado con algún circuito publicado, aunque sea que prenda y apague un LED. Una vez hechas esas primeras armas, será necesario:
- decidir qué integrado será adecuado (cantidad de I/O, RAM y ROM, existencia de conversor A/D, velocidad, etc.), o tirarse a un lance primero con el más sencillo y ver qué pasa.
- entender la hoja de datos del integrado: cómo se mueven sus tripas y su juego de instrucciones.
- estudiar el ensamblador o compilador correspondiente.
Puede simplificarse obteniendo un circuito + programa (con bastantes explicaciones) parecido a lo que se necesita y haciéndoles retoques. Así empecé yo!.

DÓNDE PUEDO INFORMARME MÁS?
Lugares con info sobre PICs, o que mencionan sitios con ella:
www.sss-mag.com/pic.html (english)
www.geocities.com/micramtechnologies/indice.htm (argentino)
http://personal.redestb.es/castillo/program1.html (español) y buscar cosas relacionadas con los PIC
www.webelectronica.com.ar/shop/notas/pics-se-138.htm (argentino) donde está parte de los artículos de la Saber Electrónica. Esta revista es bastante mejorable, pero bueh, es la única argentina.
www.microchip.com El papi!. Tiene muchas más cosas aparte de los PIC.
www.geocities.com/CapeCanaveral/Lab/9595/ www.qsl.net/pa3ckr/zefi/index.html Sitios de pa3ckr (frecuencímetro con PIC, y otras cosas como DDS, microwatímetro, etc.).

Problemas que tuve con aprendizaje de PIC:

- Errores de imprenta en los listados de los .asm. Se solucionó razonándolos y comparando con otros .asm que vienen con el MPLAB, NOPPP, etc.

- Al correr el NOPPP en una ventana de Win98 a veces falla el comando Program: se soluciona repitiendo una o dos veces el Erase. A Windows mucho no le gusta esta conexión a una "impresora" tan extraña.

- Me tiré a un lance: usar el programa MPLXKEY.ASM (de la AN557 en el sitio de Microchip) que escanea un teclado y muestra lo ingresado en un display, pero usando un 16F84 en vez del 16C71 indicado. Casi no hubo inconveniente al ensamblar: tras declarar al 16F84 en vez de 16C71 en LIST, lo único que me advirtió el MPASM fue que también tenía que cambiarlo en el INCLUDE, y la única instrucción que no entendió fue:
movwf ADCON1
que junto con la línea anterior y por los comentarios al margen deduje que sirve para usar los pines RA0 al 3 como I/O digital en vez de analógica (el 16C71 tiene A/D y el 16F84 no).

- Dentro del MPLXKEY.ASM no se declaraba el tipo de oscilador ni la activación o no del watchdog, por lo que el NOPPP eligió erróneamente las siguientes opciones por defecto:
1) Configurarlo para oscilador RC: como en realidad era a cristal, no arrancó.
2) Activar el watchdog: tras solucionar lo del oscilador, el programa parecía congelado en algún paso. Como el programa no estaba pensado para usar el watchdog, éste lo estaba reseteando varias veces por segundo.
La solución a ambos defectos fue agregar dentro del .asm la línea:
__CONFIG _XT_OSC & _WDT_OFF (crystal oscillator y watchdog off)
Pero para que funcionase tuve que darme cuenta que antes de la directiva CONFIG, no va uno sino DOS signos de subrayado (guión bajo), y respetar el espacio después de CONFIG y a ambos lados del &.

- Errores de armado del grabador: solucionados con el modo diagnóstico del programa NOPPP.

- No se puede poner la punta x10 del osciloscopio en un pin del cristal porque deja de oscilar. Se llegan a ver los últimos milisegundos de la oscilación amortiguada.

- En caso de dudas, es muy útil escribir un pedacito dudoso, ensamblarlo y correrlo paso a paso mirando la ventana de registros, y la barra inferior que muestra el W y el Status. P. ej.:
include <p16f84.inc>
movlw D'255'
addlw 0
btfsc STATUS, Z
movlw H'AA'
movlw D'0'
addlw 0
btfsc STATUS, Z
movlw H'AA'
end

- No hay que confundir "ciclo de máquina" con "ciclo de oscilador". Hay 4 oscilaciones por cada ciclo de máquina, o sea, con un cristal de 4MHz el ciclo de máquina (lo que tardan la mayoría de las instrucciones) es de 1us.

- No se le ocurra modificar un .asm existente si no tiene el diagrama de flujo u otra forma de entender cabalmente qué es lo que hace. Perderá muchísimo tiempo en pruebas.

- Hay más de un tipo de .hex. Ante la duda, probar con el más común: Intel hex 8

- Comencé a tener problemas inexplicables cuando el código superó los 256 instrucciones. Al examinar el .LST se vio que algunas instrucciones con GOTO computado estaban por encima de la posición 255, donde vuelve a 0 el PCLow.

- Al examinar el desensamblado de lo que se generó, hay un montón de addlw ff que no estaban en el .asm original!. No asustarse, es el relleno (3FFFh = 11 1111 1111b) de las posiciones de programa no usadas.

La terminología usada por Microchip tiene estos equivalentes que tal vez resulten más claros:
- File Registers o Data Memory viene a ser la RAM que usa normalmente el programa para guardar datos temporalmente (incluye también cosas como el contador de programa, etc.). Cada "file" es una dirección de RAM.
- Program Memory es ROM, del tipo Flash: se puede alterar sólo con el grabador de PIC, puede borrarse y reescribirse 10.000 veces, y necesita una alimentación de 12,5V para la escritura (tal vez no para los nuevos modelos). En cambio, cuando habla de EEPROM también es una ROM borrable y reescribible eléctricamente (10 millones de veces), pero lo hace el mismo PIC si el programa se lo pide, son algunas decenas de bytes para almacenamiento temporal de datos (no de programa) al apagar, y no requiere tensión especial.
- El registro W viene a ser el A, Accumulator, de otros microprocesadores.
- El 16F84 es descendiente del 16C84, y Microchip olvidó cambiar algunas menciones al original.
- Las letras "mov" en las instrucciones de muchos microprocesadores y microcontroladores significan "move", pero más adecuado es pensarlas como "copiar" (un verdadero "mover" tendría que dejar "vacío" el contenedor original).

- Todo grabador más o menos serio debe poder insertar el integrado en un zócalo ZIF (zero insertion force) para evitar torcer las patas tras reiteradas inserciones. No consigue un ZIF?.
Para fabricarlo (para integrados con 0,3" entre hileras) partiendo del de un micro de PC, ésta debe ser una 486, las que en el ZIF dicen Socket 3. Las más modernas, p. ej. Socket 7, tienen los agujeros en diagonal y no sirven.
Para no tener que desoldar los más de 200 contactos, lo que hice fue:
- sacar la tapa deslizante haciendo palanca en los encastres
- desoldar de a uno los contactos sólo en el costado que se aprovechará (sólo 4 hileras) tirando de ellos con una brusela bien puntiaguda mientras se calienta la soldadura
- con una hoja de sierra suelta, serruchar la base y la tapa a la medida, no dañando las salientes que hacen de encastre
- volver a sembrar sólo las dos hileras de contactos necesarias
- encastrar la tapa
- por la poca cantidad de patas a prensar, no se necesita la palanquita, basta con correr la tapa a mano.

- En {VolVoh} tenemos la justificación de por qué conviene usar displays de ánodo común:




Vemos que la caída en los transistores de salida es menor cuando aplican un nivel bajo (sink) que cuando aplican alimentación (source).
Cada pata de I/O tolera hasta 20 ó 25mA según el sentido de la corriente (la suma de todas las patas del port B no puede exceder 100 ó 150mA).

<eof>