entornos

ENTOR ENTORNO NOS S DE ´ PROGRAMACION

Son los sistemas que permiten editar, compilar, depurar e incluso programar el microcontrolador, todo desde una misma plataforma. Para ver en detalle c´ omo se realizan cada uno de omo los pasos en los respectivos entornos, se utilizar´ a el cl´ asico ejemplo de apagar y encender un asico LED por un pin del microcontrolador (este ejemplo se ha convertido para aplicaciones con hola mundo mundo   de las aplicaciones de escritorio). El circuimicrocontrolador en el equivalente   hola to esquem´ atico, atico, y el diagrama diagrama de flujo de ´esta esta aplicaci´ on es el que aparece en la figura 20, habitualmente se usa una resistencia de 220 Ohmios. Es importante tener presente que sin la conexi´ on a Vcc del pin de Reset, el microcontrolador no ejecuta ning´ on un un programa, y la conexi´ on del cristal externo debe hacerse siempre y cuando se elija este circuito como el circuito de reloj del microcontrolador a la hora de programar los fusibles (tal como se explic´ o en el apartado de fusibles). INICIO

10k Vcc

Configurar pin como salida

Reset RB0

Encender LED

Osc1 RETARDO

Osc2

Apagar LED

RETARDO

Figura 20: Circuito esquem´ atico y diagrama de flujo del programa que enciende y apaga LED atico Para quienes est´en en acostumbrados a escribir aplicaciones para escritorio, encontrar´ an algunas similitudes y diferencias a la hora de escribir el programa. Las principales diferencias son: no hay archivos de cabecera para entrada/salida (los famosos stdio.h  y  conio.h ), ), pues la entrada y salida es mucho m´ as simple y se realiza leyendo y/o escribiendo en puertos (y si hubiese un as sistema de entrada y salida m´ as as complejo, depender dep ender´´ıa del circuito de la aplicaci´ on). on ). Tambi´ Tambi´en en es importante resaltar que el programa no se ejecuta  inmerso  en un sistema operativo, raz´ on on

por la cual el programa que se transfiera a la memoria no puede simplemente terminar, por eso todos los programas de microcontrolador deber´ an quedarse en un ciclo infinito en vez de salir de la funci´ on main.

SourceBoost (para microncotroladores PICs) El SourceBoost es un entono de programaci´ on de bajo costo desarrollado por Pavel Baranov, David Hobday y que puede ser descargado de la p´ agina www.sourceboost.com, este entorno consiste en un editor y depurador, adem´ as se pueden invocar diferentes compiladores (C2C, C2C++ BoostC, BoostC++). La versi´ o n que se descarga por internet es una versi´ on demostrativa que tiene la limitante de que el c´ odigo fuente no puede superar las 2048 instrucciones, espacio que es m´ as que suficiente para los ejemplos que veremos en este libro. El entorno SourceBoost usa por defecto el compilador BoostC. Este compilador utiliza la sintaxis definida en el ANSI-C, pero adicion´ andole algunas caracter´ısticas que hacen m´ as simple la escritura de programas para microcontroladores, la m´ as destacable es la posibilidad de usar el operador punto (.) en las variables para acceder a un bit individualmente, de tal suerte que se puede poner 1 o 0 en un bit sin alterar los dem´ as bits en el caso de escritura; o nos permite conocer si solo un bit esta en 1 o 0 en el caso de lectura. En un compilador ANSI-C debe utilizarse enmascaramiento para cualquiera de estas operaciones, m´ as adelante mostraremos ejemplos de c´omo se usa este operador. En ´este compilador se tiene la convenci´ on de que todos los registros se etiquetan con nombres en min´ uscula sostenida y todos los bits se etiquetan con nombres en may´ uscula sostenida.

Por cada aplicaci´ on debe construirse un proyecto nuevo, escogiendo la respectiva opci´ on del men´ u. Inmediatamente aparecer´ a un cuadro de di´ alogo como el que aparece en la figura 21. Si a´u n no se ha escrito el c´ odigo, lo mejor es elegir la segunda opci´ on, pues con ´esta el entorno nos crea un archivo de c´ odigo .c  nuevo (con el mismo nombre del proyecto) con el cuerpo de la funci´ on  main  y algunas otras l´ıneas tal como aparece en la figura 22

Figura 21: Creaci´ on de un nuevo proyecto en el entorno SourceBoost

Adem´ as del archivo de c´ odigo fuente, en la parte izquierda de la figura 22 se puede observar el arbol   de archivos que hacen parte del proyecto. Ah´ı se encuentra el archivo ej1.c  (ej1   fue el ´  nombre dado a este proyecto, as´ı que ej1.c  es el nombre del archivo que se est´ a editando), y adicionalmente aparecen una serie de archivos en la carpeta Release (tambi´en puede aparecer la carpeta Debug, dependiendo de la opci´ on elegida en la pesta˜ na superior, esto permite tener compiladas diferentes versiones, dependiendo si es una versi´ on definitiva, o una versi´ on para depurar), estos archivos son los que se crear´ an una vez se compile la aplicaci´ on, el archivo con extensi´ on   .asm   es una versi´ on en ensamblador del programa en lenguaje C, el archivo .lst  es similar al .asm   pero detallando las posiciones de memoria donde quedan los c´ odigos de m´ aquina. El archivo .hex  contiene los c´ odigos de m´ aquina del programa; este archivo es el que se programa (o  quema  en la memoria ROM del microcontrolador). Aunque no aparece en el a´rbol tambi´en se crea el archivo  .cof , que es algo as´ı como una versi´ on binaria del archivo .hex , y que adem´ as

contiene informaci´ on u ´ til para los programas de depuraci´ on (indicando los archivos, n´ umero de l´ıneas correspondiente a los c´ odigos de m´ aquina, nombre de variables, etc). Y el archivo  .map  contiene una descripci´ on detallada de la memoria usada por el programa (tanto RAM como ROM). Conforme al mane jo de proyectos en cualquier entorno, el c´ odigo fuente podr´ıa estar distribuido en varios archivos, y/o librer´ıas, pero por lo pronto haremos proyectos con un solo archivo de c´ odigo fuente. La ventana inferior de la pantalla se utiliza para mostrar los mensajes que tanto el compilador como el enlazador mostrar´ıan en la ventana de comandos, para indicar el resultado de la compilaci´ on y el enlace de las aplicaciones.

Figura 22: Archivo .c que crea el entorno cuando se construye un proyecto nuevo

Inmediatamente despu´es, es conveniente escoger la referencia del microcontrolador para el cual se est´ a dise˜ nando la aplicaci´ on. Tal como se muestra en la figura 23(b). Tambi´ en es recomendable escoger la frecuencia del oscilador, y en este entorno se debe ser muy cuidadoso pues la opci´ o n que se escoge en el men´ u (con la opci´ on ClockRate), es solo para la simulaci´ on, siendo necesario agregar una l´ınea de c´ odigo para indicarle dicha frecuencia al compilador. Para nuestro caso escogemos 4 MHz con la siguiente l´ınea de preprocesador: (una l´ınea de preprocesador en un programa en lenguaje C no es exactamente c´ odigo, sino que son opciones que le indica al compilador como realizar ciertas acciones). # pragma CLOCK F REC  4000000

(a)

(b)

Figura 23: Escogencia de la referencia del microcontrolador Esta l´ınea debe ubicarse al principio del archivo, pues con ella el compilador determina los c´ o digos de m´ a quina para todo aquello que dependa la frecuencia del oscilador (como los retardos). Es importante resaltar que para estas y otras opciones de configuraci´ on, cada uno de los entornos utiliza diferentes mecanismos, as´ı que si se est´ a utilizando uno diferente al SourceBoost deber´ıa consultar en las ayudas los pasos equivalentes. Nota:  Si

se est´a utilizando un cristal de 4 MHz se puede omitir la l´ınea de preprocesamiento pues 4 MHz es el valor por defecto que se utiliza en este entorno.

Todos los pasos comentados hasta aqu´ı ser´ an necesarios en cualquier aplicaci´ on, y a partir de aqu´ı se escribir´ an las instrucciones propias de cada programa. Volviendo a la aplicaci´ o n escogeremos el pin RB0 para conectarlo al LED. Y siguiendo el diagrama de flujo lo primero que debe hacerse es programar el pin RB0 como salida y luego un ciclo infinito que contiene cuatro sentencias, la primera enciende el LED, en la segunda se hace un retardo de un segundo y luego apagamos el LED en la tercera y por ultimo, ´ hacemos otro retardo de un segundo. El listado completo es el siguiente: #include // a r c h iv o de c ab ec e ra que d e f i n e r eg y f u n ci o ne s #pragma   CLOCK FREC 40 00 00 0 // l i n e a p r e p r o . I n d i c i a f r e c . o p er a ci o n   void    main() { trisb=0xFE; do {

portb=1; delay s (1); portb=0; delay s (1); } w h i l e  ( 1 ) ;

// i n i c i o f u nc i o ´n   mai n   // c o n f i g u r a p i n r b0 como s a l i d a   // i n i c i o c i c l o i n f i n i t o // p on e un 1 e n e l p i n r b 0 ( e n c i e n d e LED) // r e t a r d o 1 s eg un do // p on e un 0 e n p i n r b 0 ( a p ag a e l LED) // r e t a r d o de 1 s eg un do // f i n c i c l o i n f i n i t o

}

Despu´es de editar el archivo se procede a compilar y enlazar el programa. Para compilar se utiliza la respectiva opci´ on en el men´ u Build o si se quiere utilizando el bot´ on para tal prop´ osito como se muestra en la figura 24

Figura 24: Formas de invocar el compilador en el entorno SourceBoost Si todo va bien en la ventana de mensajes del compilador/enlazador deber´ıa aparecer el siguiente texto: ”C: \ P ro gr am F i l e s \ SourceBoost \ b o o s t c p i c 1 6 . e x e ” − t PIC16F877A − i d x 1 − o b j R e le a se −d RELEASE ej 1 . c Boo st C O p ti m iz i n g C C o mp il e r V e r s i o n 7 . 0 0 (  f o r    P IC16 a r c h i t e c t u r e ) http : //www. sourceboost .com  Copyright (C) 2004 − 2010 Pavel Baranov Copyright (C) 2004 − 2010 David Hobday S i n g l e u s e r L i t e L i c en s e ( U n r eg i st e r ed ) f o r  0 n od e ( s ) Lim ita tio ns : PIC12 , PIC16 max code si z e :2048 words , max RAM banks :2 , Non c o mm e rc i al u s e o n l y

ej 1 . c success Done

Si hay errores, por cada uno de ellos aparecer´ a el n´ umero la l´ınea donde ocurri´ o el error y una descripci´on del mismo. Aprender a identificar y corregir los errores es todo un arte y solo se aprende con la pr´ actica. Si se tiene experiencia con aplicaciones de escritorio, se debe tener en cuenta que adem´ a s del famoso olvido del punto y coma, en este entorno es muy com´ un que ocurran errores con los nombres de los registros, o los nombres de los bits asociados, frecuentemente debido a que los escribimos con el tipo de letra contrario (may´ uscula cuando debe ser en min´ uscula o viceversa), o porque omitimos el paso de escoger el microcontrolador para el cual se est´ a dise˜ nando la aplicaci´ on. La regla general para los nombres en este entorno es la siguiente: los registros se etiquetan con solo letras en min´ usculas y los nombres de bits asociados con solo letras may´ usculas. El u ´ ltimo paso para generar el archivo ejecutable en el microcontrolador ser´ıa enlazar los archivos (enlazar los archivos consiste en tomar los c´ odigos de m´ aquina correspondiente a nuestro c´ odigo fuente y unirlo con el c´ odigo m´ aquina de las librer´ıas y generar un solo archivo .hex con los c´ odigos de m´ aquina de la aplicaci´ on completa). Este proceso se invoca usando el icono con la letra L, o la respectiva opci´ o n del men´ u Build. Aqu´ı tambi´en pueden ocurrir errores, pero a diferencia de la fase de compilaci´on, solo se menciona el error, pues ya no es posible identificar la l´ınea del c´ odigo que gener´ o el error. En este punto adem´ as se informa sobre la cantidad de memoria RAM y ROM consumida en la aplicaci´ on. (Nota: con la opci´ on Build se puede compilar y enlazar el archivo, pero es mejor hacerlo por separado para que sea m´ as f´acil identificar y corregir los errores). Despu´es de haber superado la fase de escritura y codificaci´ on de la aplicaci´ on debe realizarse la fase de depuraci´ on que consiste en identificar y corregir errores l´ ogicos en el programa, y a pesar de que esta aplicaci´ o n es tan simple, muchas veces consiste en la fase que m´ as tiempo hay que dedicarle. Aqu´ı tambi´ en hay diferencias con las aplicaciones de escritorio, pues hay que tener en cuenta que adem´ as del software que estamos desarrollando, se debe simular el hardware sobre el cual se ejecutar´a dicho software (en la mayor´ıa de las aplicaciones con el PC se asume el mismo hardware, o por lo menos podemos contar con que el sistema operativo y el kernel son los encargados del manejo directo del hardware). Los entornos donde se programan aplicaciones de microcontrolador escasamente permiten simular el hardware interno de los microcontroladores, de tal forma que nos toca   simular en la cabeza  el comportamiento del hardware externo a partir de los valores de los pines del microcontrolador, y solo algunas aplicaciones especializadas como el Proteus de la empresa Labcenter permiten simular simult´ aneamente el hardware y el software, (en realidad Proteus, es un paquete que adem´ as de simular el hardware y el software de la aplicaci´ on, permite el dise˜ no del PCB del circuito; se puede descargar una versi´ on demostrativa de la p´ agina www.labcenter.com). En el SourceBoost se puede simular el programa utilizando el icono   mariquita   (la palabra en ingl´ es para depurar es Debug, que literalmente traduce quitar insectos, y su origen se remonta a las primeras grandes computadores que ocupaban piezas enteras con tubos de vac´ıo, y cuando un programa no funcionaba correctamente, se le echaba la culpa a las cucarachas que ocasionaban cortos en los circuitos; a pesar del avance en la microelectr´ onica, esta situaci´ on ha cambiado poco, sobre todo en este tipo de aplicaciones, muchas veces nos vemos tentados a culpar al hardware de los errores de nuestro software). Estando en modo depuraci´ on se puede correr paso a paso, observar el valor de los registros, los puertos y generar datos de entrada

para determinar si el comportamiento del programa es el apropiado ante diferentes situaciones. El u ´ ltimo paso, es descargar la aplicaci´ on en la memoria del microcontrolador.

Panorama de la Herramienta AVR Studio La herramienta AVR Studio suministrada por la empresa Atmel en su p´ agina web (www.atmel.com) permite editar programas para sus aplicaciones usando microcontroladores de esta marca, compilarlos, depurarlos, y mediante un programador compatible, descargar los programas a la memoria FLASH del dispositivo.

R1 10k

U1 9 12

C1 0.1uF

13 40 39 38 37 36 35 34 33

R2

1 2

330

3 4 5

D1 LED

6 7 8

RESET

PC0/SCL PC1/SDA

 

XTAL1

PC2/TCK

XTAL2

PC3/TMS PC4/TDO

 

PA0/ADC0

PC5/TDI

 

PA1/ADC1

PC6/TOSC1

 

PA2/ADC2

PC7/TOSC2

 

PA3/ADC3

 

PA4/ADC4

PD0/RXD

 

PA5/ADC5

PD1/TXD

 

PA6/ADC6

PD2/INT0

PA7/ADC7

PD3/INT1 PD4/OC1B

PB0/T0/XCK

PD5/OC1A

PB1/T1

PD6/ICP1

PB2/AIN0/INT2

PD7/OC2

22 23 24 25 26 27 28 29 14 15 16 17 18 19 20 21

PB3/AIN1/OC0 PB4/SS PB5/MOSI PB6/MISO

 AREF

PB7/SCK

 AVCC

32 30

 ATMEGA16

Figura 25: Diagrama esquem´ atico para el ejemplo AVR Studio es un ambiente integrado de desarrollo para escribir y depurar aplicaciones AVR. Suministra una herramienta de administraci´ on de proyectos, editor de archivos fuente y simulador de chip. AVR Studio es un front – end donde permite escribir c´ odigo ya sea en lenguaje ensamblador o en lenguaje C. Por defecto trae todas las librer´ıas necesarias para ejecutar un proyecto en lenguaje ensamblador. Sin embargo, si se necesita escribir un proyecto en lenguaje C, se debe adicionar la herramienta WinAVR la cual es un back – end y contiene todas las funciones de la AVRlibc necesarias para correr cualquier aplicaci´ on. Para dar un vistazo a la herramienta, se propone un ejemplo sencillo para el manejo de un LED conectado al pin PB0 del puerto B del microcontrolador ATmega16. Su frecuencia de reloj ser´a manejada por el oscilador interno a 8 MHz. Su objetivo es encenderlo y apagarlo cada segundo. El primer paso para desarrollar esta aplicaci´ on, es tener claro el diagrama esquem´ a tico y su objetivo. El diagrama esquem´ atico se muestra en la figura 26 A continuaci´ on se debe configurar el pin donde est´ a conectado el LED como salida mediante la escritura del bit PB0 del registro DDRB. Una vez es configurado este pin como salida, la

INICIO

Como se puede ver en el diagrama esquem´ atico, para encender el LED, el microcontrolador debe poner un estado l´ o gico alto sobre el pin 1 (PB0), mientras que un estado l´ ogico alto har´ a que se apague. Por lo tanto la funci´ on del microcontrolador ser´ a sencilla, alternar altos y bajo sobre este pin a una rata de 1 segundo. En la figura 26 se muestra el diagrama de flujo para la soluci´ on de este problema.

Configurar PB0 como salida

Encender LED

RETARDO

Apagar LED

La primera parte de este programa corresponde al bloque INICIO donde el compilador ejecuta una serie de instrucciones de inicializaci´ on y queda listo para que el programador inicie su programa.

RETARDO

Figura 26: Diagrama de flujo para encender un LED siguiente etapa corresponde a un ciclo infinito donde el microcontrolador nunca retornar´ a de su trabajo a menos que se suspenda la fuente de alimentaci´ on y permanecer´ a encendiendo y apagando el LED cada segundo. Para el retardo de 1 segundo, la librer´ıa AV Rlibc   trae compilado un archivo llamado < util/delay.h > donde contiene dos funciones para el manejo de retardos en milisegundos y microsegundos, las cuales se llaman   delay ms(valor s) y   delay us(valor us) respectivamente. m

A continuaci´ on se muestra el c´ odigo en lenguaje C.
#include #include


. h> i l / d e l a y . h>

i n t    main( void )

{ PORTB = 0 ;   // Se g ar an t iz a c er o en e l p ue rt o a nt es de s e r   / / c o n f i g u r a d o c omo s a l i d a   DDRB = 1<
{ PORTB | = (1<
} return  0 ;

}

Las primeras dos l´ıneas del c´ odigo corresponden a las librer´ıas que son utilizadas durante el programa. La librer´ıa < avr/io.h > es la que contiene la definici´ on de todos los registros de entrada y salida as´ı como constantes que son manejadas por el microcontrolador seleccionado; sin ella, la definici´ on de los registro DDRB y PORTB ser´ıan desconocidas para el compilador y por lo tanto reportar´ıa el error en compilaci´ on. La librer´ıa < util/delay.h > ya mencion´ oy es la encargada de llamar las funciones de los retardos.

Posterior a esto se define la secci´ o n de c´ odigo donde estar´ a vinculado nuestro programa. Y por u ´ltimo se resalta el ciclo infinito denotado while(1) donde el microcontrolador de manera indefinida repetir´ a la secuencia mencionada. Hay que resaltar, si nuestro programa involucra operaciones con la frecuencia de la CPU como lo hace el archivo de retardos, se debe configurar el valor de la frecuencia. Este proceso se realiza cuando hayamos escrito nuestro c´ odigo en la herramienta de desarrollo. Una vez nuestro programa ha sido escrito en un editor de texto cualquiera o ha sido planteado, se procede a crear el proyecto usando la herramienta de desarrollo AVR Studio y compilar y depurar nuestro programa. La figura 27 muestra la ventana donde el usuario crea un nuevo proyecto. En esta fase se parametriza el proyecto. Si se trata de escribir un archivo fuente en ensamblador se selecciona la opci´ on  Atmel AVR assembler,   o si se trata de escribir un archivo fuente en lenguaje C se selecciona la opci´ on  AVR GCC  . A continuaci´ on se escribe un nombre para el proyecto, se escoge la ruta y se selecciona el dispositivo o microcontrolador a utilizar.

Figura 28: Ventana para escoger dispositivo a utilizar

Figura 27: Ventana de creaci´ on de nuevo Proyecto en el AVR Studio

Figura 29: Interfaz principal AVR Studio

En la figura 28 se muestra la interfaz principal de la herramienta AVR Studio. Una vez nuestro programa est´e editado es necesario compilarlo a trav´es del men´ u   Build   o mediante F7. Si el c´ odigo no presenta ning´ un error en compilaci´ on reporta el mensaje en la parte de debajo de la ventana principal. Para configurar el valor de la frecuencia del oscilador, se debe hacer a trav´ es del men´ u  Pro jects – Configuration Options  como se muestra en la figura 29.

Figura 30: Configuraci´ on de la frecuencia de la CPU

Adicional en esta ventana tambi´ en se puede observar todos los registros de entrada y salida que posee el microcontrolador. En el men´ u  Debug  se puede iniciar el proceso de depuraci´ on ante la cual, la interfaz indicar´ a sobre la ventana del c´ odigo la instrucci´ on que est´ a pr´ oxima a ejecutarse a trav´ es de una flecha como se puede observar en la figura 30. De la misma manera se puede observar una ventana llamada  Processor  en la que se muestran las variables principales de la CPU. Si se requiere, puede adicionarse una ventana de Watches  donde se puede visualizar los valores y las ubicaciones en la memoria de datos de las variables que hayamos definido. Durante la depuraci´ on de nuestro programa, en la ventana ubicada en la parte inferior derecha de la ventana principal, se puede ver c´ omo cambia cada bit de los registros involucrados en nuestro programa. Para terminar, se debe tener especial cuidado con el tipo de oscilador y manejo de fusibles a la hora de descargar el c´ odigo a la memoria FLASH del dispositivo.

Figura 31: Ventana de Depuraci´ on del AVR Studio