Tutorial Microcontroladores
Microcontroladores
Reserva de Byte de Memoria (RMB).
Esta directiva se usa para reservar un lugar (asignar un espacio) en RAM para las variables de un programa. La directiva RMB no genera código objeto alguno, pero ello genera una entrada en la tabla cruzada interna del ensamblador. En el programa de ejemplo (listado 6-1), la variable en RAM TEMP1 fue asignada con una directiva EQU. Otra forma de asignar esa variable podría ser de la siguiente forma:
Esta forma es preferible a la del uso de EQU en la asignación de espacio en RAM porque es muy común en el desarrollo de un programa borrar o agregar variables sobre la marcha. Si se usara directivas EQU se debe tener en cuenta de cambiar varias sentencias después de remover una sola variable. Con la directiva RMB, el ensamblador asigna direcciones tanto como sean necesarias. Establecer por Definición Número de Base Decimal. Algunos ensambladores, tal como el P & E Microcomputers Systems, asumen que cualquier valor que no sea específicamente marcado será interpretado como un número hexadecimal. Le idea es simplificar el ingreso de información numérica por la eliminación de la necesidad del uso del símbolo $ antes de cada valor. Si se quiere que el ensamblador asuma que los valores no marcados sean valores decimales, usar la directiva $BASE.
Esta directiva es un tanto diferente con respecto a otras descriptas en esta capítulo. La directiva $BASE comienza en la columna extrema izquierda del programa fuente. Esta directiva está incluida cerca del comienzo de cada programa ejemplo en este curso. Si se está usando un ensamblador que no requiere esta directiva, se puede borrar la misma o incluir un asterisco (*) al comienzo de la línea para anular la sentencia.
Popurrí de Soluciones.
Como en muchos otros campos de la ingeniería, hay más de una secuencia de instrucciones que pueden realizar una tarea en particular. Una buena forma de aprender una nueva instrucción es ver como en cuantas diferentes maneras se puede resolver un pequeño problema de programación. A esto yo lo llamo “Popurrí de Soluciones”.
La figura 6-7 nos muestra cuatro diferentes métodos para verificar el cierre de un interruptor conectado al puerto A bit 0 (PTA0).
Dos de estos métodos fueron usados en el programa de ejemplo del listado 6-1. Si bien todas las secuencias aquí presentadas realizan la misma tarea básica, existen diferencias entre ellas. Usualmente estás diferencias no son significativas, pero algunas veces ellas pueden ahorrar tiempo de ejecución o espacio de memoria de programa.
En microcontroladores pequeños, el ahorro de espacio, puede ser algo muy importante a tener en cuenta.
Fig. 6-7 – Cuatro Maneras de Chequear un Interruptor.
Los números entre paréntesis cuadrados son los números de ciclos de CPU que se requieren por instrucción en cada línea del programa. La secuencia TOP1 ocupa 6 bytes de espacio de programa y toma 8 ciclos para su ejecución. El acumulador está en $01 cuando el programa “cae” (sigue de largo) a través de la instrucción BEQ. La secuencia TOP2 ocupa solamente 3 bytes de memoria y 5 ciclos para su ejecución. Además el acumulador no es alterado (Esta es probablemente la mejor secuencia en la mayoría de los casos).
La secuencia TOP3 ocupa un byte menos que TOP1 pero también insume un ciclo más en la ejecución de la misma. Después de la secuencia TOP3, el acumulador mantendrá los otros 7 bits leídos desde el PORT A, también desplazados en una posición a la derecha.
La última secuencia ocupa 6 bytes en memoria y toma 8 ciclos su ejecución, pero el loop en si mismo solamente toma 6 ciclos. Con ejercicios como el anterior, nuestra habilidad para encontrar mejores soluciones en cantidad de ciclos y espacios de memoria ocupados irá mejorando, lo cuál será muy útil a la hora de necesitar reducir la extensión de nuestros programas o mejorar la velocidad de ejecución del mismo.
Sistemas de Desarrollo.
Freescale y fabricantes de terceras fuentes, disponen de una variedad muy extensa de herramientas de desarrollo tanto para la familia HC705 como para la nueva familia HC 908 FLASH. En esta basta propuesta de sistemas, encontraremos desde herramientas profesionales de altas prestaciones y por consiguiente, costos elevados, hasta herramientas de muy bajo costo pero con prestaciones más que interesantes para su categoría.
Para la nueva familia HC908 FLASH, presentaremos más adelante (en el curso complementario (Parte II) “Curso sobre Microcontroladores HC908 FLASH” incluido en el presente curso) un portfolio de herramientas de fabricación nacional que permiten prestaciones similares a equipos de mayores costos.
Pues bien, los simuladores en circuito (ICS) (In-Circuit Simulator) tal el nombre genérico para la familia de MCUs HC705, ofrecidos por Freescale, incluyen simulación pura (software) y simulación en circuito propiamente dicha. Estos simuladores en circuito (ICS05xxx para las distintas versiones de la familia HC705) poseen una placa principal (Board) denominada “POD” que se conecta por medio de un puerto serial (COMxx) a una PC (Computadora Personal). Un conector del tipo DIP y un cable plano permiten al ICS conectarse con la aplicación bajo desarrollo tomando el lugar del microcontrolador que eventualmente esté en uso. Un zócalo especial, del tipo ZIF (Fuerza de Inserción Cero) viene provisto en estos sistemas. Este zócalo permite programar chips del MCU bajo desarrollo, tanto en versiones OTP como en versiones EPROM (borrables por medio de luz ultravioleta) desde la misma PC.
A esta altura, se hace necesario, explicar las diferencias existentes entre “Simulación Pura”, “Simulación En Circuito” y “Emulación en Circuito”.
Un “Simulador Puro” o simplemente “Simulador” es un programa para una computadora personal (PC) que nos ayuda durante el desarrollo y depuración de un programa dado.
Esta herramienta de soft “simula” las acciones de un microcontrolador real, pero tiene algunas ventajas importantes. En un simulador tenemos un completo control de cómo y cuando el CPU debería avanzar a la próxima instrucción. También se puede mirar y cambiar valores de registros internos o de memoria RAM, etc, etc, antes de ir a la próxima instrucción.
Los simuladores NO CORREN A VELOCIDAD DE TIEMPO REAL!! . Mientras la PC está “simulando” las acciones del MCU con programas de software, cada instrucción del MCU tomará mucho más tiempo de ejecución que si estas fueran efectuadas por el MCU REAL. Para muchos programas de MCUs, esta reducción en la velocidad no es algo problemática. Sin embargo, NO puede considerarse como TIEMPO REAL la ejecución de las instrucciones en los simuladores, ya que la velocidad de ejecución de cada instrucción estará fuertemente ligada a la velocidad de ejecución del programa simulador en la PC. Por lo que en PCs con alta perfomance, el programa simulador correrá mucho más rápido que en una PC de baja perfomance, pero nunca podrá igualar a la velocidad real de ejecución de cada instrucción como lo haría el propio MCU.
Un truco para acelerar la ejecución de algunos loops de demora que tomarían algún tiempo su ejecución en simulación, es reemplazar las cuentas a alcanzar por los contadores dentro del lazo por valores más pequeños, de esta forma, se llegará más rápido al valor final de la cuenta. Tener presente que, una vez terminada la simulación, se deberán reemplazar nuevamente los valores por los originales, a fin de no alterar la ejecución del programa en el MCU real.
Un “Simulador en Circuito” es un simulador que puede ser conectado al sistema del usuario (sistema bajo desarrollo) en lugar del microcontrolador. Un simulador puro normalmente solo toma información de entrada por medio de la PC y muestra resultados y salidas por medio del display o pantalla de la PC. En un simulador En Circuito, las entradas y las salidas pueden controlarse en forma real como si fuera el propio microcontrolador el que tomará el control de las mismas. Las consideraciones anteriores (simulador puro) siguen siendo válidas para la simulación en circuito. Todo transcurrirá más lentamente que en un MCU real pero la gran diferencia aquí radica en la posibilidad de controlar entradas y salidas del MCU en forma física y NO simulada por software.
Trabajar con este tipo de herramientas (simuladores / simuladores en circuito) es mucho más sencillo que si lo hiciéramos directamente sobre el MCU, volcándole el programa en la memoria del mismo sin posibilidad de “ver” lo que está sucediendo con el programa en cada ciclo de instrucción del mismo. Solo nos quedaría el método de “prueba y error” con múltiples intentos (borrado y re-grabación de un chip versión EPROM) hasta alcanzar el objetivo deseado.
En los Simuladores / Simuladores en Circuito, podemos parar nuestro programa a voluntad, producir puntos de quiebre (paradas) o breakpoints en lugares específicos, modificar / verificar valores de registros, posiciones de memoria RAM, correr paso a paso nuestro programa, etc, etc. Además nos informa cuando una variable no ha sido inicializada al intentar usarla sin haberlo hecho.
Todo ello contribuye a facilitar la tarea del desarrollador, ya que permite observar con suma facilidad los errores cometidos en la confección de un programa y corregirlos en consecuencia.
Un “Emulador En Circuito” o ICE (In-Circuit Emulator) es una herramienta de desarrollo en TIEMPO REAL. El “emulador” está construido alrededor de un MCU REAL de forma tal que este pueda ejecutar instrucciones de programa exactamente como ellas fueran ejecutadas en la aplicación final. Por lo general, un emulador dispone de memoria RAM donde debería haber memoria ROM o EPROM en el MCU final. Esto permite una rápida carga del programa en el emulador y efectuar cambios constantes en el programa durante el proceso de depuración del mismo. Una serie de circuitos extras permiten al emulador establecer “Breakpoints” o puntos de quiebre en el programa bajo desarrollo.
Cuando el programa alcanza una de estas direcciones de breakpoint, el programa bajo desarrollo el programa temporariamente se detiene y un “programa monitor” de dicha herramienta toma control. Este programa monitor permite mirar o cambiar registros del CPU, locaciones de memoria, o registros de control.
Un emulador tiene típicamente menos visibilidad de las acciones internas del MCU que un simulador, pero SOLO el emulador puede correr las instrucciones del programa bajo desarrollo en TIEMPO REAL, o sea a la velocidad REAL del MCU. Esta ventaja es particularmente apreciable, en programas de aplicación donde existan interrupciones u otro tipo de eventos muy rápidos que no puedan “simularse” debido a su velocidad y su no repetibilidad en el tiempo. Además tener la posibilidad de correr el programa bajo desarrollo en tiempo real, permite constatar que los tiempos calculados en los distintos retardos o temporizados que tuviera, sean exactos o bien actuar en función de ello. Los sistemas emuladores en tiempo real, son por lo general, más costosos que los simuladores en circuito o aún más costosos que un simple simulador puro (software). Sin embargo, como se verá más adelante en el curso complementario sobre HC908 FLASH, la nueva tecnología de esta familia de MCUs, posibilita el acceso a EMULADORES en Tiempo Real (que también funcionan como Simuladores puros / Simuladores En Circuito / Programadores) muy económicos de costos comparables a los Simuladores en Circuito para la familia HC705. Gracias a esta facilidad que presenta la nueva familia HC908 FLASH de Freescale, el diseñador ve facilitado su trabajo de desarrollo, ya que cuenta con las características de una herramienta muy poderosa como un emulador en tiempo real, pero sin afrontar los costos altos que por lo general presentan este tipo de sistemas.
“FLASH_POD” - Sistema de Desarrollo para toda la familia HC908 FLASH
“EVAL08QTY” – Sistemas de Desarrollo tipo I.C.E para TODA la flia. HC908Q (de 8 y 16 pines).
“EDUKIT08” – Sistema Didáctico / Entrenamiento para las familias HC908 / HC9S08 / Serie Flexis (8 / 32 Bits).