SISTEMA DE DESARROLLO PARA UN MICROPROCESADOR ORIENTADO A APLICACIONES AEROESPACIALES

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL PROYECTO FIN DE CARRERA SISTEMA DE DESARROLLO PARA UN MICROPROCESADOR ORIENTADO A APLICACIONES AEROESPACIALES DIRECTOR: AUTOR: Jose Daniel Muñoz Frías Alberto Requena Izard MADRID, Junio de 2009

2 ÍNDICE DE CONTENIDOS

3 MEMORIA. ÍNDICE DE CONTENIDOS 1 Parte I Memoria... 5 Capítulo 1 Introducción Estructura del sistema con el que se trabaja Estudio de los trabajos existentes / tecnologías existentes Motivación del proyecto Objetivos Objetivos para el ensamblador Objetivos para el simulador Objetivos para la interfaz gráfica Metodología / Solución desarrollada Recursos / herramientas empleadas Capítulo 2 Ensamblador Capítulo 3 Simulador Introducción Estructura general Clase sim Clase sys Clase dsp Clase tm Clase apb Clase apb_slave Clase var Clase dsp Datos principales Funciones principales Clase tm (Task Manager) Datos principales Funciones principales Clase apb (Advanced Peripheral Bus) Datos principales... 27

4 MEMORIA. ÍNDICE DE CONTENIDOS Funciones principales Clase apb_slave y clases derivadas Clase apb_mem Clase apb_seq Clase apb_timed Clase var Datos principales Funciones principales Clase sys Funciones Clase sim Datos principales Funciones principales Comunicación del simulador Modo interactivo normal Modo entrada por fichero, salida por ventana Modo entrada por fichero, salida por fichero Modo interactivo por tuberías con la Interfaz Gráfica Estructura del main Capítulo 4 Interfaz Gráfica Introducción Para qué una interfaz gráfica wxwidgets Comunicación con los programas. Clase Console Comunicación con el ensamblador Comunicación con el simulador Datos principales de la clase console Funciones principales de la clase console Diálogo de configuración Estructuración en el programa Clase configure_panel Panel del procesador... 74

5 MEMORIA. ÍNDICE DE CONTENIDOS Datos principales Funciones principales Panel del programa Datos principales Funciones principales Panel de registros Datos principales Funciones principales Panel de mensajes Funciones de manejo de eventos Panel principal Marco principal ( Main Frame ) Datos principales Funciones principales Funciones de manejo de eventos Capítulo 5 Resultados / Experimentos Datos de entrada Ejecutando instrucciones Ficheros de entrada Archivo con el código ensamblador, Prueba.asm Archivo con los datos de entrada de la memoria tipo timed, Timed.apbin Archivo con los datos de entrada del esclavo secuencial 1, in_seq_1.apbin Archivo con los datos de entrada del esclavo secuencial 2, in_seq_2.apbin Ficheros generados por el programa Archivo de proyecto, Prueba.dspp Archivo de backannotation, test.back Archivo con la ROM en vhdl, test.vhdl Archivo con la salida del esclavo secuencial 1, out_seq_1.apbout Archivo con la salida del esclavo secuencial 2, out_seq_2.apbout Capítulo 6 Conclusiones Capítulo 7 Futuros desarrollos

6 MEMORIA. ÍNDICE DE CONTENIDOS 4 1 Pequeños cambios Adaptar a cambios en códigos de operación y ciclos de reloj sin necesidad de recompilar Mejorar la escritura de código en la interfaz gráfica Implementar las operaciones de la FPU manualmente Grandes cambios Co-simulación con ModelSim Adaptación del compilador GCC Generación de código directamente con Simulink Parte II Manuales de usuario Capítulo 1 Manual del Ensamblador Capítulo 2 Manual del Simulador Capítulo 3 Manual de la Interfaz Gráfica Capítulo 4 Manual para adaptar el sistema de desarrollo a distintos proyectos Qué hace falta recompilar y cómo Cómo recompilar el ensamblador Cómo recompilar el simulador Cambiar ciclos de reloj de cada instrucción Cambiar códigos de operación Cambiar el set de instrucciones Cambiar el fichero de entrada del programa bison Cambiar el fichero de entrada del programa flex Cambiar los ficheros dsp_inst.h y dsp_inst.c Cambiar el simulador Bibliografía Parte III Estudio económico

7 Parte I MEMORIA

8 MEMORIA. INTRODUCCIÓN 6 Capítulo 1 INTRODUCCIÓN Un DSP (Digital Signal Processor) es un procesador de señales digitales. Mientras que un microprocesador está preparado para trabajar con grandes bloques de software y muchas tareas simultáneamente, un DSP está específicamente diseñado para altas necesidades de cálculo. Sin embargo, el diseño de un simulador para un microprocesador o para un DSP es prácticamente idéntico. El departamento Microelectrónica de EADS Astrium CRISA, empresa con la que se ha realizado el proyecto, diseña electrónica para el espacio. A menudo se quiere diseñar un DSP para que vaya incluido en la FPGA, por motivos de espacio. Este proyecto trata de facilitar el desarrollo de software para los mismos, mejorando las herramientas que utilizaban para ello. La parte concreta del desarrollo del software un DSP en la que se ha trabajado es en la simulación del código binario que entiende éste. Figura 1. Partes del sistema de desarrollo. El sistema de desarrollo está dividido en las tres partes que se aprecian en la Figura 1. En el Capítulo 2 se habla muy brevemente del ensamblador y las pequeñas modificaciones que se le han realizado, en el Capítulo 3 se discute el simulador del DSP, y el Capítulo 4 trata sobre la interfaz gráfica que facilita y agiliza tanto el ensamblado como la simulación. El resto de

9 MEMORIA. INTRODUCCIÓN 7 capítulos muestran resultados, conclusiones y posibles ampliaciones del proyecto. 1 Estructura del sistema con el que se trabaja Puesto que el proyecto trata sobre herramientas para apoyar el desarrollo de un DSP, se ve la necesidad de detallar la estructura del sistema sobre el que se trabaja antes de explicar cómo se ha simulado. Figura 2. Estructura del sistema en la FPGA. El sistema entero se implanta en una FPGA, de modo que se implementa con hardware tres circuitos diferentes: Un DSP, que contiene la memoria del programa, los registros (256 posiciones de memoria) y una FPU (Floating Point Unit) en la que se ejecutan los algoritmos. Además de comunicarse con el Task Manager y el ABP que se comentan a continuación recibe directamente una palabra de 32 bits con la información más relevante del exterior, que se usa con instrucciones especiales, como jmps, que condiciona un salto al valor de uno de los bits de la palabra de status. Un circuito externo, el Task Manager, en el que se implementan por hardware las distintas tareas que debe realizar el DSP, se decide cuál se

10 MEMORIA. INTRODUCCIÓN 8 debe ejecutar en cada momento y se manda la indicación al DSP. En el proyecto sobre el que se trabaja, el DSP está encargado de cinco tareas independientes del satélite: o Selección del canal de conversión de ADC. o Calibración del ADC. o Ejecución y activación del algoritmo de control de la velocidad. o Ejecución y activación del algoritmo de control de la posición. o Ejecución y activación del algoritmo de supervivencia. Son todas tareas que se deben ejecutar, siempre con el mismo periodo, y siempre las mismas instrucciones, es por ello que se implementan en una memoria ROM. Un sistema de comunicaciones con periféricos, el APB (Advanced Peripheral Bus), que tiene mapeados en memoria a los dispositivos del entorno, es decir, cada esclavo tiene asignadas unas posiciones de memoria. Puesto que los esclavos (periféricos con los que se comunica el DSP a través del APB) trabajan en coma fija y el DSP en coma flotante, se produce una conversión al trasvasar información. El sistema de desarrollo se ha intentado hacer tan fácil de adaptar como ha sido posible, de modo que algunas cosas se pueden configurar sin necesidad de tocar el código fuente, como el número de tareas, o el tamaño de las memorias, y otras se han hecho de forma estructurada pero para adaptarlo a otro proyecto habría que hacer pequeñas modificaciones sobre el código fuente, como cambiar los ciclos de reloj de las instrucciones o el set de instrucciones en sí. En la Parte IICapítulo 4 se ha escrito un pequeño manual sobre como adaptar el código fuente ante los típicos cambios para adaptar a distintos proyectos, o cambios en la aquitectura del DSP.

11 MEMORIA. INTRODUCCIÓN 9 2 Estudio de los trabajos existentes / tecnologías existentes El simulador de un microprocesador o de un DSP comercial es algo que suelen hacer las propias empresas que lo fabrican y lo distribuyen, pues es algo básico para su uso, por tanto se han encontrado muchos ejemplos en Internet con los cuales hacerse una idea clara de lo que se busca. El problema es que al no ser de código abierto no se ha podido reutilizar nada de lo encontrado. Lo que ha sido de gran ayuda es la versión anterior del simulador de la propia empresa CRISA, realizado por D. Juan Antonio Ortega y por D. José Daniel Muñoz Frías. Aunque estaban en lenguaje C, en vez de en C++, algunas de las funciones principales que éste simulador realizaba han mantenido su estructura. 3 Motivación del proyecto Como ya se ha mencionado, la empresa CRISA desarrolla electrónica para el espacio, y entre otras cosas, microprocesadores y DSPs. Puesto que la herramienta que utilizaban para simular el diseño necesitaba algunas modificaciones, surgió la idea de hacer un simulador en lenguaje C++ de manera muy estructurada, y una interfaz gráfica que englobara la edición del texto, el ensamblado, la simulación y la presentación de resultados. Al tener una herramienta que facilita y acelera la simulación, se consigue probar con mayor eficiencia el DSP que se está desarrollando y el programa que se busca implementar. Si además esta herramienta está diseñada pensando en su fácil modificación y adaptación a distintos proyectos, se ahorrarán muchas horas de trabajo en futuros desarrollos de microprocesadores y DSPs.

12 MEMORIA. INTRODUCCIÓN 10 4 Objetivos El objetivo del proyecto es diseñar y realizar un sistema de desarrollo para microprocesadores y DSPs para agilizar el diseño de los mismos y los programas que usan. El diseño se centrará en una aplicación para un proyecto concreto, en el que el set de instrucciones y la configuración general del DSP está determinado, pero se intentará hacer lo más modular posible, pensando en que la utilidad del programa se basa en su posible aplicación a muchos proyectos. 4.1 Objetivos para el ensamblador El ensamblador se debe adaptar al set de instrucciones nuevo, también debe crear un fichero VHDL con la memoria ROM, para su simulación con ModelSim y su posterior síntesis en la FPGA, y por último se debe poder elegir ensamblar la memoria de registros en 24 o en 32 bits. 4.2 Objetivos para el simulador Su programación debe ser muy modular y clara, para adaptarlo fácilmente a otros proyectos. Se deben poder simular tres tipos distintos de esclavos APB, secuencial, memoria y memoria función del tiempo. El simulador se debe poder usar sin necesidad de la interfaz gráfica en una ventana de comandos, y también se debe poder automatizar su uso mediante ficheros de entrada y de salida. Se debe dejar abierta la posibilidad de simular comparando con el resultado de la simulación con ModelSim, aunque no será el uso principal del simulador. Se estudiará el realizar una portabilidad del GCC a la arquitectura creada, permitiendo programar en lenguaje C en lugar de ensamblador.

13 MEMORIA. INTRODUCCIÓN Objetivos para la interfaz gráfica La interfaz debe estar programada de forma modular, también para facilitar modificaciones, y debe ser un ejecutable aparte del simulador. Debe existir una ventana en la que escribir comandos directamente al simulador. 5 Metodología / Solución desarrollada Se crearán tres proyectos independientes del entorno de desarrollo CodeBlocks, uno para cada ejecutable que se va a realizar. El ensamblador es una modificación del ya desarrollado, por lo que no ocupa mucho tiempo. El simulador se realiza usando el lenguaje C++ basándose en el ya realizado también por D. Jose Daniel Muñoz Frías y D. Juan Antonio Ortega en lenguaje C. La interfaz gráfica se diseña partiendo de cero usando el plugin para CodeBlocks llamado wxwidgets, especialmente pesado para el diseño de interfaces gráficas. Puesto que el proyecto es la razón de mi beca con la empresa CRISA, que serán además los usuarios finales del programa realizado, los objetivos y la metodología vienen definidos en gran parte por sus necesidades. Por ello especialmente al principio del proyecto, en la etapa de en la que se definen los objetivos y los métodos usados, es más adecuado trabajar desde la propia empresa, más adelante cuando el tiempo se dedica mayormente a programar basta con acercarse a CRISA una vez por semana. 6 Recursos / herramientas empleadas Todas las herramientas empleadas son de código abierto. Para los tres ejecutables se ha usado el entorno de desarrollo CodeBlocks (en la

14 MEMORIA. INTRODUCCIÓN 12 referencia [1] se encuentra un enlace a la página oficial) junto con el compilador GCC (enlace en la referencia [2]). Estos dos programas son suficientes para el desarrollo del programa simulador, sin embargo para el ensamblador y la interfaz son necesarios algunos más. El ensamblador necesita de un analizador léxico, que se ha desarrollado usando el programa flex (enlace para descarga en la referencia [3]) y un analizador sintáctico, bison (enlace en la referencia [4]). Un tutorial sobre su uso básico se puede encontrar en la referencia [5]. Para la interfaz gráfica se a usado wxwidgets, su funcionamiento básico se explica brevemente en el Parte ICapítulo 41.2, donde también se encuentran menciones a referencias con las páginas web útiles relacionadas con el tema.

15 MEMORIA. ENSAMBLADOR 13 Capítulo 2 ENSAMBLADOR El ensamblador es el programa que transforma el fichero de texto con el código del programa en ficheros binarios con la información necesaria para cargar el programa en la FPGA y para su análisis como la puede entender la máquina. Figura 3. Estructura interna del DSP. La estructura por dentro del se puede apreciar en la Figura 3.Consta de una FPU donde se realizan los cálculos, un banco de registros (el regfile), el contador del programa, la bandera del sistema (C) para condicionales, la memoria ROM donde se almacena el programa y una unidad de control. En éste proyecto se ha tomado un ensamblador ya hecho por D. José Daniel Muñoz Frías y D. Juan Antonio Ortega, al que se le han hecho pequeñas modificaciones, que son: Cambio en el set de instrucciones que se ensambla, para dejarlo en las siguientes funciones: o nop: No hace nada, sólo incrementa en PC en 1.

16 MEMORIA. ENSAMBLADOR 14 o halt: Para la tarea actual, guarda el contexto y avisa al Task Manager. o fin arg1, arg2: Mueve el dato de la dirección arg2 del APB a la dirección arg1 del regfile. o fout arg1, arg2: Mueve el dato de la dirección arg2 del regfile a la dirección arg1 del APB. o inout arg1, arg2: Mueve el dato de la dirección arg2 del APB a la dirección arg1 del APB. o finmul arg1, arg2, arg3: Escribe en la dirección arg1 del regfile el resultado de lo que está en la dirección arg2 del APB multiplicado por lo que está en la dirección arg3 del regfile. o foutmul arg1, arg2, arg3: Escribe en la dirección arg1 del APB el resultado de lo que está en la dirección arg2 del regfile multiplicado por lo que está en la dirección arg3 del regfile. o mov arg1, arg2: Mueve dentro del regfile el dato de la dirección arg2 a la dirección arg1. o movc arg1, arg2: Mueve dentro del regfile el dato de la dirección arg2 a la dirección arg1 si la bandera del sistema está a 1. o movnc arg1, arg2: Mueve dentro del regfile el dato de la dirección arg2 a la dirección arg1 si la bandera del sistema está a 0. o movgz arg1, arg2, arg3: Mueve dentro del regfile el dato de la dirección arg2 a la dirección arg1 si arg3 es mayor que cero. o movlz arg1, arg2, arg3: Mueve dentro del regfile el dato de la dirección arg2 a la dirección arg1 si arg3 es menor que cero. o cmpgt arg2, arg3: Compara dos registros y si arg2 es mayor que arg3 pone la bandera a 1. o cmplt arg2, arg3: Compara dos registros y si arg2 es menor que arg3 pone la bandera a 1.

17 MEMORIA. ENSAMBLADOR 15 o cmpeq arg2, arg3: Compara dos registros y si arg2 es igual que arg3 pone la bandera a 1. o cmpge arg2, arg3: Compara dos registros y si arg2 es mayor o igual que arg3 pone la bandera a 1. o cmple arg2, arg3: Compara dos registros y si arg2 es menor o igual que arg3 pone la bandera a 1. o jmp dst_jmp: Salta a la dirección de memoria dst_jmp. o jmpc dst_jmp: Salta a la dirección de memoria dst_jmp si la bandera vale 1. o jmpnc dst_jmp: Salta a la dirección de memoria dst_jmp si la bandera vale 0. o jmps dst_jmp, arg3: Salta a la dirección de memoria dst_jmp si el bit arg3 de la palabra de status vale 1. o fadd arg1, arg2, arg3: Escribe en la dirección arg1 del regfile el resultado de lo que está en la dirección arg2 más lo que está en la dirección arg3 del regfile. o fsub arg1, arg2, arg3: Escribe en la dirección arg1 del regfile el resultado de lo que está en la dirección arg2 menos lo que está en la dirección arg3 del regfile. o fmul arg1, arg2, arg3: Escribe en la dirección arg1 del regfile el resultado de lo que está en la dirección arg2 multiplicado por lo que está en la dirección arg3 del regfile. o fdiv arg1, arg2, arg3: Escribe en la dirección arg1 del regfile el resultado de lo que está en la dirección arg2 dividido por lo que está en la dirección arg3 del regfile. o fsqrt arg1, arg2: Escribe en la dirección arg1 del regfile el resultado de la raíz cuadrada de lo que está en la dirección arg2.

18 MEMORIA. ENSAMBLADOR 16 o fsin arg1, arg2: Escribe en la dirección arg1 del regfile el resultado del seno de lo que está en la dirección arg2. o fcos arg1, arg2: Escribe en la dirección arg1 del regfile el resultado del coseno de lo que está en la dirección arg2. o fsatp arg1, arg2, arg3: Si arg3 es mayor o igual que arg2, escribe en la dirección arg1 del regfile lo que está en la dirección arg2 del regfile, si no, escribe lo que está en la dirección arg3 del regfile. o fsatn arg1, arg2, arg3: Si arg3 es menor o igual que arg2, escribe en la dirección arg1 del regfile lo que está en la dirección arg2 del regfile, si no, escribe lo que está en la dirección arg3 del regfile. o fabs arg1, arg2: Escribe en la dirección arg1 del regfile el valor absoluto de lo que está en la dirección arg2. La posibilidad de trabajar con registros de 24 o de 32 bits, pudiendo así ser más flexibles en el compromiso entre precisión y espacio ocupado. La creación automática de un fichero vhdl que contiene la memoria rom con las instrucciones ya codificadas, para permitir realizar también la simulación en vhdl del programa. Con éstas pequeñas adaptaciones el ensamblador se utiliza en el proyecto tanto manualmente, como siendo llamado de manera automática por la interfaz gráfica.

19 MEMORIA. SIMULADOR 17 Capítulo 3 SIMULADOR 1 Introducción El simulador es un programa de ordenador que permite emular el comportamiento del DSP (Digital Signal Processor) a lo largo de la ejecución de un programa. Permite por tanto obtener estadísticas del programa, (como por ejemplo el tiempo que tarda en ejecutar una tarea) y del sistema simulado, facilitando la tarea de probar posibles modificaciones en el diseño, de manera mucho más rápida que cambiando el DSP en sí. Figura 4. Estructura del simulador. En la Figura 4 se presenta la estructura general del programa simulador. Como cabe esperar, se aprecia una estructura muy parecida a la del sistema emulado. Se puede apreciar en la una clara estructura en el diseño del programa, con unas partes contenidas en otras. La necesidad de esta estructuración es lo que nos llevó a usar el lenguaje de programación C++. En el apéndice A

20 MEMORIA. SIMULADOR 18 se ofrece una breve introducción a la programación orientada a objetos, y C++ en particular. 2 Estructura general Se explica brevemente la estructura global del Simulador antes de entrar en el proceso de diseño de cada parte, para dar una idea clara del programa en su conjunto. El simulador al completo está englobado en la clase sim, fuera de ella quedan funciones necesarias para poder comunicar el objeto sim con las peticiones realizadas al programa; éstas últimas funciones se presentan después de las clases que componen el simulador Las clases más importantes son las siguientes: 2.1 Clase sim Esta clase contiene el sistema simulado (objeto sys) y el objeto var, los métodos tanto para obtener los valores de las variables de simulador como para ordenarle ejecutar, hace de interfaz con el sistema. 2.2 Clase sys Engloba toda la parte más hardware del simulador. Por simplicidad y buscando el máximo parecido con la realidad, tan sólo tiene dos métodos: Init() y Step(). El primero inicializa todo el sistema, y el segundo ejecuta la siguiente instrucción del programa, como en un microprocesador real. 2.3 Clase dsp Contiene el objeto rom (el programa), el objeto regfile (variables) y la información de las operaciones, aparte contiene el valor del Program Counter, el reloj y el contexto de cada tarea. Alberga también la función DecoAndExe(), encargada de decodificar y ejecutar cada instrucción.

21 MEMORIA. SIMULADOR Clase tm El Task Manager (tm) contiene los objetos de las tareas y la función Schedule(), que accede a ésta información y decide cuál es la tarea que el DSP debe ejecutar. 2.5 Clase apb El Advanced Peripheral Bus (apb) es un bus de comunicaciones por el cual el DSP obtiene información del exterior y a su vez deja sus resultados. Está emulado como una memoria, compuesta por esclavos de tres tipos, que son posibles dispositivos conectados al DSP. Contiene las funciones CreateSlave(), que permite asignar a una zona de memoria un esclavo con una información dada, y FindSlave(), que encuentra a qué esclavo le corresponde la zona de memoria a la que se quiere acceder. 2.6 Clase apb_slave A partir de ella se derivan las tres clases correspondientes a cada tipo de esclavo, accesibles sólo a traves de la clase apb. 2.7 Clase var Contiene información de las variables del programa, tanto su posición en memoria como su valor esperado de la simulación del VHDL.

22 MEMORIA. SIMULADOR 20 3 Clase dsp Figura 5. Elementos principales de la clase dsp. El objeto dsp es la parte más importante del simulador, ya que tiene la función principal (ejecutar una instrucción) y las memorias principales del programa, además de los contextos de las tareas. 3.1 Datos principales Reloj del programa (clk_tick), para saber cuándo despertar una tarea, por ejemplo. Program Counter del programa (PC). Id de la tarea en ejecución (current_task). Flags del programa, generados en instrucciones de comparación (b_gt, b_lt, b_eq, b_ge, b_le). Vector con el contexto de cada tarea (tasks_context): o Id de cada tarea del vector. o PC por el que estaba ejecutando la tarea cuando se interrumpió. o PC al que debe volver en caso de reset de la tarea (PC_reset). Punteros a los objetos apb, tm (task manager), rom y regfile. Necesarios para poder acceder a sus datos y sus métodos

23 MEMORIA. SIMULADOR 21 Nombre del fichero con la información para inicializar los Program Counters de cada tarea (name_pc). Nombre del fichero de donde se lee la Status Word, dato de 32 bits externo al DSP, que se simula con un fichero de texto externo (name_status). 3.2 Funciones principales DecoAndExe Figura 6. Función DecoAndExe. Argumentos de entrada: ninguno. Argumentos de salida: 1 si se realiza un halt (se termina una tarea), 0 si no. Función principal: Decodifica la instrucción de la memoria ROM a la que apunta el PC y la ejecuta. Funcionamiento: 1. Lee PC. 2. Accede a la dirección de la ROM indicada en PC. 3. Separa el código de operación de los argumentos, mediante máscaras.

24 MEMORIA. SIMULADOR Con un switch, dependiendo del código de operación, accede al APB, al regfile, realiza un salto, multiplica dos registros, lo que corresponda a la instrucción. 5. modifica el PC y el reloj del programa Status Figura 7. Función Status. Argumentos de entrada: ninguno. Argumentos de salida: entero de 32 bits, con la palabra de status Función principal: devuelve el valor de la palabra de status correspondiente al clk_tick actual.

25 MEMORIA. SIMULADOR Halt Figura 8. Función Halt. Argumentos de entrada: ninguno. Argumentos de salida: ninguno. Función principal: almacena el PC actual en el contexto de la tarea e informa al task manager de que la tarea actual ha terminado Load Figura 9. Función Load. Argumentos de entrada: id de la tarea a cargar. Argumentos de salida: ninguno.

26 MEMORIA. SIMULADOR 24 Función principal: fuerza la carga del contexto de una tarea en concreto. 4 Clase tm (Task Manager) Figura 10. Elementos principales de la clase tm. El objeto task manager es el encargado de decidir la tarea que se debe ejecutar en cada momento. Está implementado fuera del DSP porque también en realidad es un circuito externo. 4.1 Datos principales Vector de objetos task, cada uno de los cuales a su vez contienen: o Id de la tarea. o Prioridad de la tarea. En esta primera versión se toma como mayor prioridad la tarea con identificador menor, pero está pensado para poder realizar una ampliación en la que la o Bit que indica si la tarea está o no activa (1/0). o Estado de la tarea. RUNNING indica que la tarea es está ejecutando. READY indica que la tarea está lista para ejecutarse, y está esperando a que acabe otra de mayor prioridad.

27 MEMORIA. SIMULADOR 25 HALTED en el caso en el que la tarea está parada. o Periodo de la tarea. o Tick de reloj en el que se debe despertar la tarea, si está parada. 4.2 Funciones principales Schedule Figura 11. Función Schedule. Argumentos de entrada: Reloj del dsp Argumentos de salida: Id de la tarea a ejecutar. Función principal: Organiza las tareas en función de su estado y su prioridad, y decide la tarea a ejecutar. Funcionamiento: 1. Comprueba si todas las tareas está paradas, de ser así, avanza el reloj de ejecución hasta que a alguna le toque despertar. 2. Compara el reloj del sistema con el tick de reloj en el que cada tarea debe despertar, y si procede, despierta la tarea. 3. Busca la tarea con mayor prioridad, que esté lista (en estado READY). 4. Devuelve el id de esta tarea para que el dsp la ejecute.

28 MEMORIA. SIMULADOR Init Figura 12. Función Init. Argumentos de entrada: ninguno Argumentos de salida: ninguno Función principal: Inicializa las tareas, leyendo sus periodos de archivo Halt Figura 13. Función Halt. Argumentos de entrada: Id de la tarea y reloj actual del dsp Argumentos de salida: ninguno Función principal: Cuando se ejecuta una instrucción halt en el código, duerme la tarea hasta el siguiente periodo

29 MEMORIA. SIMULADOR 27 5 Clase apb (Advanced Peripheral Bus) Figura 14. Elementos principales de la clase apb. El objeto apb es la puerta de comunicaciones del dsp hacia el entorno. Se estructura como si fuera una memoria, cada esclavo (dispositivo conectado al apb) tiene asignado un rango de direcciones de memoria y para leer o escribir en él, simplemente se ha de hacer en la posición de memoria que le corresponda en el apb. 5.1 Datos principales Tamaño del bus apb (apb_size), simplemente se necesita para poder comprobar que los esclavos que se crean están dentro. Valor más alto de memoria usado (apb_max_used), se actualiza según se crean esclavos en posiciones superiores de memoria, para cuando se impriman los valores del apb dar sólo la información hasta la zona de memoria usada. Un vector en el que se almacena información básica sobre los esclavos (slaves_info), es decir: o type, el tipo de esclavo, que puede ser: mem, que representa una memoria.

30 MEMORIA. SIMULADOR 28 seq, que representa un esclavo de acceso sequencial, es decir, se le pide un dato y te da el siguiente que tiene en la cola de entrada, o le das un dato y lo guarda en la cola de salida. timed, que emula un esclavo que dará valores distintos dependiendo de cuando se le pidan los datos, como por ejemplo un conversor analógico-digital. o start, la primera dirección de memoria correspondiente al esclavo. o end, la última. o slave_ptr, que es un puntero al esclavo, para usar sus propias funciones de lectura y escritura. 5.2 Funciones principales CreateSlave Figura 15. Función CreateSlave. Argumentos de entrada: Tipo de esclavo, direcciones de comienzo y fin del esclavo y nombres de los ficheros de entrada y de salida Argumentos de salida: Ninguno. Función principal: Crea un tipo de esclavo dado y guarda su información básica en el vector slaves_info. Se le llama al configurar el programa al iniciar.

31 MEMORIA. SIMULADOR FindSlave Figura 16. Función FindSlave. Argumentos de entrada: Dirección del apb buscada. Argumentos de salida: Puntero al esclavo del apb correspondiente, y dirección dentro de este esclavo. Función principal: Permite desde fuera acceder para leer o escribir a una dirección del apb sin tener información sobre el esclavo, usando esta función para redirigir el acceso al que corresponda Resto de las funciones del apb Figura 17. Resto de funciones del apb.

32 MEMORIA. SIMULADOR 30 Agrupo el resto de las funciones porque su funcionamiento es el mismo, simplemente usan la función FindSlave para encontrar el esclavo al que debe ser redirigidos, y luego usan la función correspondiente del esclavo. 6 Clase apb_slave y clases derivadas Se ha creado una clase base, apb_slave, a partir de la cual se han derivado las tres clases correspondientes a los tres tipos de esclavos. Esto permite poder referirse a cualquiera de las tres clases con un puntero a clase apb_slave, y usar las funciones definidas como virtuales en la clase base. Figura 18. Elementos principales de la clase base apb_slave. El ser las funciones virtuales en la clase base, su definición es distinta para cada clase derivada, pero su uso es el mismo desde fuera, lo que simplifica mucho su uso. A continuación se describen las diferencias principales entre las tres clases derivadas. 6.1 Clase apb_mem Al llamar a la función Init se cargan en un vector los datos del fichero externo, que contiene los valores de las posiciones de memoria distintas de cero en el formato dirección valor, por ejemplo: f f bf80

33 MEMORIA. SIMULADOR 31 El fichero de entrada no se modifica, pero cada vez que se usa la función Update se guarda el contenido de la memoria completa en el fichero especificado de salida. Las funciones de lectura y escritura funcionan de la manera que cabe esperar de una memoria, sin nada especial. Se puede ver, sin embargo, que existe una versión que transforma los datos a tipo float (las funciones Read y Write), y otra versión que los deja como unsigned int (ReadNoConv y WriteNoConv), esta última se usa tan sólo en la instrucción para mover datos entre posiciones de la memoria, sin modificarlos. 6.2 Clase apb_seq Este esclavo se comporta como si fueran dos colas de comunicaciones, una de entrada y otra de salida. Al llamar a la función Init se cargan desde el fichero los valores de la cola de entrada, que simplemente aparecen como valores uno detrás de otro. Si hay un 0x delante del número se entiende como hexadecimal, si no como decimal, por ejemplo: 0x3f80 0x3f80 0xbf80 Cada vez que el dsp pide la lectura de un dato, se saca el primer dato de la cola de entrada y se devuelve, y cada vez que se escribe un dato en el esclavo, se guarda en el fichero de salida con el mismo formato que el de entrada, se puede ver que por tanto la función Update no tiene que hacer nada en absoluto. La función de lectura tiene como entrada un bool con el que se le puede indicar si debe extraer un dato de la cola o simplemente dar el que está en la posición superior, sin extraer. Esto es así porque si se quiere leer un dato para, por ejemplo, sacarlo por pantalla, no se debería modificar la cola.

34 MEMORIA. SIMULADOR 32 También es posible crear el esclavo como una simple cola de entrada, no pudiendo escribir en él, o como una simple cola de salida, en cuyo caso si se intenta leer se leerá el último dato escrito. La distinción entre las funciones que convierten los datos y las que no es igual que en esclavo tipo memoria. 6.3 Clase apb_timed Este esclavo es muy parecido a una memoria con la única diferencia de que los datos que devuelve dependen de los ciclos de reloj del sistema. Básicamente representa una memoria cuyos valores no solamente los puede cambiar nuestro sistema, sino que también cambian de manera externa. Los datos están en el siguiente formato: Ciclos de reloj : Posición de memoria valor, Posición valor, Por ejemplo: 0012 : fa1, a : b7 : , , La función Init simplemente lee el fichero de entrada y actualiza lo que corresponde a 0 ciclos de reloj. Es la función Update la que lee el fichero de entrada cada vez, actualiza las posiciones de memoria que corresponda y vuelca en un fichero externo en formato memoria los valores para que puedan ser comprobados.

35 MEMORIA. SIMULADOR 33 7 Clase var Figura 19. Elementos principales de la clase vars. Una de las funcionalidades del simulador es comprobar una simulación de VHDL. Es decir, tras obtener un fichero con los resultados de simulación en el programa Modelsim, que muestra la evolución de las variables al ejecutar el programa en el DSP, el simulador comprueba que las variables dan los resultados correctos. La clase var engloba toda la información sobre las variables necesaria para realizar esta comprobación, el procedimiento se verá más a fondo en la función CheckVHDL de la clase sim, pero básicamente guarda en un vector lo que dice el fichero, y realiza su propia simulación y compara resultados. 7.1 Datos principales Un mapa de las variables var_map, para poder acceder rápidamente a la dirección de memoria de la variable (dir), y a su tipo, que indica si la variable pertenece al apb o al regfile (type). Una lista con tareas, y las variables que se consideran salidas de esta tarea (task_outs). Como información de cada variable tendremos: o name, el nombre de la variable. o dir, su dirección en memoria.

36 MEMORIA. SIMULADOR 34 o value, el valor que la simulación con Modelsim ha obtenido. o tolerance, la tolerancia admitida antes de indicar error entre los resultados obtenidos por la simulación con nuestro programa y los que ofrece Modelsim. 7.2 Funciones principales Init Figura 20. Función Init. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Carga el mapa de variables desde el fichero, deduciendo si la variable pertenece al apb o al regifle a partir del prefijo del nombre (P_ y v_ para el regfile, in_ y out_ para el apb).

37 MEMORIA. SIMULADOR LoadOuts Figura 21. Función LoadOuts. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Carga los nombres de las salidas correspondientes a cada tarea. No se hace al inicio para que si no existe el fichero no de error al iniciar el programa, sino solo si se quiere comprobar la simulación de VHDL, ya que para lo demás no es necesario SaveVar Figura 22. Función SaveVar. Argumentos de entrada: Nombre y valor de la variable a guardar y tarea en ejecución.

38 MEMORIA. SIMULADOR 36 Argumentos de salida: Ninguno. Función principal: Guarda la información de la variable leída en el lugar que corresponda. Funcionamiento: 1. Tras comprobar que la variable está en el mapa, busca en task_outs si es una salida de la tarea en ejecución, si es así, lo guarda en el propio vector task_outs. 2. Si no es una salida de la tarea en ejecución, será una entrada. Así que la guarda en el apb o en el regfile CheckOutputs Figura 23. Función CheckOutputs. Argumentos de entrada: Tarea en ejecución. Argumentos de salida: Ninguno. Función principal: Comprueba diferencias entre los valores del las variables del vector task_outs correspondientes a la tarea en ejecución, y sus valores en el regfile y el apb, si el error es mayor que la tolerancia, muestra un mensaje de error.

39 MEMORIA. SIMULADOR 37 8 Clase sys Figura 24. Elementos de la clase sys. En la clase sys se engloban todos los elementos que simulan un DSP, se puede entender como la parte más hardware del programa, de modo que creando el objeto sys ya se tiene un DSP con todas sus funciones. Conseguimos así una gran analogía entre la estructuración del elemento a simular y la del programa simulador. 8.1 Funciones Init Figura 25. Función Init. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno.

40 MEMORIA. SIMULADOR 38 Función principal: Inicializa todos los objetos del sistema Step Figura 26. Función Step. Argumentos de entrada: Ninguno ó tarea a ejecutar. Argumentos de salida: bool con valor 1 si el dsp ha llegado al final de la tarea. Función principal: Ejecuta una instrucción de programa de la tarea ordenada por el Task Manager, también se puede forzar una tarea en concreto, esta funcionalidad se usa en el modo de comprobación de simulación VHDL. Funcionamiento: 1. Lee del dsp los ciclos de reloj 2. Se los indica al Task Manager, que le devuelve la tarea a ejecutar. 3. Si el Task Manager indica que hay que cambiar de tarea, le dice al dsp que cargue el contexto de la nueva tarea. 4. Indica al dsp que decodifique y ejecute una instrucción 5. Actualiza el apb 6. Devuelve 1 si el dsp ha ejecutado la instrucción halt, que indicaría que se ha llegado al final de la tarea.

41 MEMORIA. SIMULADOR 39 9 Clase sim Figura 27. Elementos principales de la clase sim. La clase sim es el simulador completo, contiene al sistema (objeto de la clase sys) junto con funciones para actuar sobre él u obtener información y al objeto var, donde se almacenan y se procesan las variables necesarias para la comprobación de la simulación de ModelSim. Se dejan sin embargo fuera de esta clase las funciones necesarias para que el usuario se comunique con el simulador, ya que estas dependen de la forma en la que el usuario introduzca los comandos, que puede ser por teclado directamente, a través de la Interfaz Gráfica, o mediante ficheros de entrada. La clase sim es por tanto ajena al método usado para pedirle la información, pues todo es traducido a comandos fáciles de interpretar antes de comunicarse con ella. Es la encargada de manejar el simulador en base a la configuración introducida y las peticiones hechas, que son leídas por su función más importante, Execute. 9.1 Datos principales break_pc, que es un set de puntos de ruptura del programa (breakpoints). Poner un breakpoint en cualquier punto de la memoria del programa conlleva que al intentar ejecutar la tarea completa, se para en el punto

42 MEMORIA. SIMULADOR 40 indicado, para luego seguir sólo si se le indica. Facilita mucho estudiar una parte concreta del código rápidamente. 9.2 Funciones principales Init Figura 28. Función Init. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Inicializa el sistema y el objeto con la información de las variables y borra los breakpoints.

43 MEMORIA. SIMULADOR LoadConfig Figura 29. Función LoadConfig. Argumentos de entrada: Nombre del archivo de configuración. Argumentos de salida: bool con valor 1 si ha habido algún error, y cero si no. Función principal: Carga la configuración del sistema desde el archivo externo Execute Figura 30. Función Execute. Argumentos de entrada: Un vector con las palabras que forman el comando pedido y un bool que indica si se está trabajando por medio

44 MEMORIA. SIMULADOR 42 de tuberías con la Interfaz Gráfica, en cuyo caso la información se presenta más simplificada. En el Parte ICapítulo 42.2 se explica más a fondo la comunicación entre el simulador y la interfaz gráfica. Argumentos de salida: Ninguno. Función principal: Interpreta los comandos pedidos y utiliza las funciones internas que les corresponden Disassemble Figura 31. Función Disassemble. La función está sobrecargada, por lo que tiene dos tipos de funcionamientos dependiendo del tipo de valores de entrada. Si se usa un argumento de entrada int: Argumentos de entrada: Dirección de la memoria ROM a desensamblar y un bool que indica si se ha de imprimir por pantalla el resultado o sólo devolverlo. Argumentos de salida: string con la instrucción desensamblada Función principal: Permite obtener la línea de ensamblador con la que fue codificada cada instrucción de la memoria. Y si la entrada es de tipo string: Argumento de entrada: Nombre del fichero a crear

45 MEMORIA. SIMULADOR 43 Argumentos de salida: Ninguno. Función principal: Crea un fichero externo con las instrucciones de toda la memoria ROM desensambladas en el orden en que están en memoria CheckVHDL Figura 32. Función CheckVHDL. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Comprueba la simulación del programa con la realizada por el programa de simulación de VHDL ModelSim. Funcionamiento: Esta funcionalidad del simulador se entiende mejor con un ejemplo. Esta es una parte extraída del fichero que genera ModelSim con su simulación: Executing task number ps in_motor_current_id ps in_motor_current_iq ps in_dc_link ps in_ema_position ps v_rate_command e ps v_id_order e ps v_motor_speed e ps v_vd_order e+02

46 MEMORIA. SIMULADOR ps v_current_order e ps v_vq_order e+00 Executing task number 5 Y a nuestro simulador le hemos indicado que las variables que se consideran salidas de la tarea 1 son v_vd_order y v_vq_order. El funcionamiento sería el siguiente: 1. Lee la tarea que se ejecuta (1). 2. Guarda las variables que no son salidas de la tarea en el regfile (v_rate_command, v_id_order, v_motor_speed y v_current_order), o en el apb (in_motor_current_id, in_motor_current_iq, in_dc_link e in_ema_position), y las que son salida (v_vd_order y v_vq_order) en una lista especial. 3. Ejecuta la tarea entera (la tarea 1) en el sistema sys. 4. Compara los valores de las variables de salida guardadas y las obtenidas por simulación (v_vd_order y v_vq_order en regfile y v_vd_order y v_vq_order guardadas en la el objeto variables). 5. Si la diferencia es mayor que la tolerancia, saca un error por pantalla AllTask Figura 33. Función AllTask.

47 MEMORIA. SIMULADOR 45 Argumentos de entrada: Ninguno, o bien la tarea concreta a ejecutar, si se quiere forzar un cambio de tarea (para usarlo con CheckVHDL). Argumentos de salida: Ninguno. Función principal: Ejecuta instrucciones de la memoria ROM hasta que termine la tarea, o hasta encontrar un punto de ruptura AddBreakpoint, DeleteBreakPoint y DeleteAllBreakpoints Figura 34. Funciones de manejo de breakpoints. Simplemente mencionar que al añadir un punto de ruptura, se guarda en el set break_pc la dirección del breakpoint. Y luego es la función AllTask la que se preocupa en cada instrucción de comparar la dirección de la instrucción a ejecutar con el conjunto de breakpoints.

48 MEMORIA. SIMULADOR LoadState y SaveState Figura 35. Funciones LoadState y SaveState. Guardando el estado completo de la simulación y pudiendo cargarlo luego, podemos partir la simulación, osea no tener que hacerlo todo seguido. Es algo que puede ser muy útil en simulaciones extremadamente largas CheckString Figura 36. Función CheckString. Argumentos de entrada: String esperada, string leída y stream de entrada. Argumentos de salida: bool con valor 1 si ocurre algún error.

49 MEMORIA. SIMULADOR 47 Función principal: En lecturas de ficheros grandes, como el de configuración y el de estado, permite dar un error más específico. Se llama a la función varias veces en la lectura del fichero, y solamente se sigue leyendo esta función no devuelve error. También se encarga de ignorar los comentarios Get y Print Figura 37. Funciones Get y Print. Tan sólo mencionar que se han incorporado unas funciones para obtener y para sacar por pantalla fácilmente los datos principales del sistema. Estas no sólo sirven para simplificar el resto de las funciones del simulador, sino también facilitan las posibles ampliaciones que se realicen. 10 Comunicación del simulador El simulador se puede comunicar de cuatro maneras distintas, que son:

50 MEMORIA. SIMULADOR Modo interactivo normal Figura 38. Comunicación modo interactivo. Llamando al simulador a través de una ventana de comandos con un archivo de configuración se abre el programa, que llama a la función RunInteractive presentando un menú como del de la Figura 38, en el que espera la introducción de comandos por parte del usuario, y se muestran los resultados en la misma ventana. Un ejemplo de comando usado para llamar al programa podría ser: >dsp_sim.exe c config.dspp 10.2 Modo entrada por fichero, salida por ventana Otra posibilidad es escribir en un fichero los comandos que se quiera que el simulador ejecute, para automatizar las pruebas. Un ejemplo de fichero de entrada: run task

51 MEMORIA. SIMULADOR 49 run step3 print apb 14 run task print regfile 4 run step 5 Luego se llama al programa con un comando como: >dsp_sim.exe c config.dspp i InputCmd.txt El programa lee los comandos del fichero y presenta los resultados por pantalla. Figura 39. Modo entrada por fichero, salida por ventana. Los resultados se presentan como se puede ver en la Figura 39, del mismo modo que en el modo interactivo normal Modo entrada por fichero, salida por fichero Es prácticamente igual que el modo anterior, pero los resultados se dejan en el fichero de salida indicado. Un ejemplo de comando podría ser: >dsp_sim.exe c config.dspp i InputCmd.txt o Output.txt 10.4 Modo interactivo por tuberías con la Interfaz Gráfica El funcionamiento de las tuberías se explica más a fondo en la parte de la interfaz gráfica. Por parte del simulador, el modo es igual que el interactivo normal en cuanto a la lectura de comandos, y prácticamente

52 MEMORIA. SIMULADOR 50 igual en la presentación de resultados, la única diferencia es que muchos datos se presentan de manera más sencilla de extraer por parte de la Interfaz, por ejemplo: print regfile 4 En el modo interactivo normal da lugar a: Dir = 4, Value in hex = 41921f, Value in float = Mientras que en éste modo se simplifica a: DIR f El comando con el que se puede llamar al simulador en este modo es: >dsp_sim.exe c config.dspp p 11 Estructura del main Para terminar de presentar el programa, se enumeran los pasos que se siguen en el fichero principal del programa. 1. Se crea un objeto de la clase simulador. 2. Se averigua el método de comunicación a usar en base a los argumentos con los que se ha llamado al programa. 3. Si el método de comunicación es de salida a fichero, se redirecciona ya hacia el fichero, para que posibles errores aparezcan en él. 4. Configura el simulador y lo inicializa. 5. Dependiendo del método de comunicación, elige la función adecuada, pasándole la dirección del objeto sim.

53 MEMORIA. INTERFAZ GRÁFICA 51 Capítulo 4 INTERFAZ GRÁFICA 1 Introducción 1.1 Para qué una interfaz gráfica Se puede deducir leyendo el Capítulo 2, Ensamblador y el Capítulo 3, Simulador que todos los objetivos que tenía que cumplir el entorno de desarrollo ya están cubiertos, pues ya hemos creado los programas necesarios para poder ensamblar nuestro código de programa, y simular su comportamiento en un DSP virtual. Entonces, Para qué queremos un Interfaz gráfica? Principalmente por los siguientes dos motivos: La interfaz gráfica entre en usuario y el programa reduce en gran medida el tiempo que un nuevo usuario tiene que invertir para aprender a usar en entorno de desarrollo, pues tanto las funciones que quiere ejecutar como los datos que quiere obtener se presentan de manera mucho más intuitiva. Ahorra tiempo para el usuario que también sabría usar el simulador en modo consola, pues siempre se tienen a la vista los datos principales de la simulación, mientras que en el modo consola hay que pedirlos expresamente. En definitiva, la interfaz gráfica no añade funcionalidades al entorno de desarrollo, sino que su único objetivo es simplificar y agilizar su uso. 1.2 wxwidgets Para el desarrollo de interfaz se ha elegido la herramienta wxwidgets, específicamente diseñada para el desarrollo de este tipo de programas.

54 MEMORIA. INTERFAZ GRÁFICA 52 Las principales ventajas que nos ofrece son: ser de código abierto, gratuita, muy sencilla y muy potente, y poder generar código absolutamente portable a los sistemas operativos principales (Linux, Windows y Mac). En el apartado [6] de la bibliografía se indica la página web desde la cual se puede descargar. WxWidgets incluye una biblioteca de funciones con las cuales se puede generar la interfaz al completo, pero también se puede descargar un plugin para la herramienta Codeblocks, que es la que se está usando como IDE, que facilita mucho el desarrollo al permitir organizar las ventanas, botones y demás ítems de manera gráfica. En la referencia [7] de la bibliografía se facilita una página web en la que se explica como descargar e instalar el plugin. Para aquel que quiera usar ésta herramienta, es recomendable hacer un par de tutoriales: 1. Uno muy básico sobre el uso de wxwidgets junto con CodeBlocks para desarrollar herramientas de manera gráfica. Un enlace a la página se encuentra en la referencia [8]. 2. Un tutorial sobre el uso de las funciones de wxwidgets, ya que la mayoría de la programación se tendrá que hacer a mano usando éstas funciones. El enlace puede ver en la referencia [9]. 2 Comunicación con los programas. Clase Console Figura 40. Comunicaciones entre programas.

55 MEMORIA. INTERFAZ GRÁFICA 53 Como se puede ver en la Figura 40, la interfaz gráfica se ha de comunicar con los dos programas ya comentados. Aunque esta comunicación se lleva a cabo de manera distinta para un programa y para otro, se ha creado una clase en la que se engloba todas las funciones necesarias. Figura 41. Elementos principales de la clase console. Pero antes de explicar los datos y funciones de ésta clase, se va a comentar brevemente los métodos de comunicación. 2.1 Comunicación con el ensamblador El proceso de ensamblar el código del programa es algo puntual, por lo tanto la interfaz solamente llama al programa ensamblador con los argumentos adecuados, y recoge la salida. Para ello se usa la función wxexecute, que ejecuta lo que se le indica como si fuera una ventana de comandos, se le pasan como argumentos dos vectores donde guarda la salida que el programa daría por pantalla, que luego se muestra en el panel de mensajes. 2.2 Comunicación con el simulador La comunicación con el simulador es un poco más compleja, pues la interfaz necesita estar continuamente haciendo peticiones y recogiendo la información que se le devuelve.

56 MEMORIA. INTERFAZ GRÁFICA 54 Existe algo especialmente diseñado para éste tipo de comunicaciones, las tuberías (a veces se le llama directamente en inglés, pipes), éstas son un método por el cual se puede mandar información desde un proceso del sistema a otro, y se deja en manos del sistema operativo el llevar la información. En la referencia [10] se cita una página web donde se explica más a fondo el funcionamiento de las tuberías. Puesto que el sistema operativo del ordenador está tan implicado en el uso de las tuberías, se definen y se usan de manera ligeramente distinta dependiendo del S.O. con el que trabajemos. Por suerte, wxwidgets tiene sus propias funciones para la creación y el uso de tuberías, que simplemente llaman a las funciones específicas que haya que usar dependiendo del sistema que usemos, esto nos permite seguir trabajando con código perfectamente portable. 2.3 Datos principales de la clase console Una estructura en la que se han englobado los datos principales del estado del microprocesador, ps: o Valor del contador del programa, PC. o Número de ciclos de reloj, clk_tick. o Tarea en ejecución, current_task. o Bandera para instrucciones condicionales, flag. o Una bandera que indica si ha habido algún error en la palabra de status, status_fail. o La palabra de status en sí, status. o Contexto de la tarea almacenado en el dsp, dsp_tc, que a su vez contiene el PC de cada tarea y el PC_reset, que indica a que dirección debe ir la tarea al empezar de nuevo

57 MEMORIA. INTERFAZ GRÁFICA 55 o Contexto de cada tarea almacenado en el Task Manager. Para cada tarea se tiene: priority, la prioridad de la tarea. active, que indica que la tarea no está deshabilitada. period, el periodo con el que se ha de ejecutar la tarea. state, el estado de la tarea (ejecutándose, esperando o parada). ready_tick, el ciclo de reloj en el que se ha de despertar la tarea. Un puntero a un objeto de la clase wxprocess, con la información necesaria para manejar el proceso del simulador. Tres punteros a los canales por los que se manda información (p_os), se recibe información normal (p_is) y se reciben errores (p_es). 2.4 Funciones principales de la clase console Assemble Figura 42. Función Assemble. Argumentos de entrada: Nombre del archivo a ensamblar.

58 MEMORIA. INTERFAZ GRÁFICA 56 Argumentos de salida: 1 si se produce algún error en el proceso, 0 si no. Función principal: Llama al programa ensamblador y recoge la información devuelta. Funcionamiento: 1. Lee de la clase f_names los nombres que se les quiere dar a los archivos que se van a generar al ensamblar, y si se van a codificar los registros en 24 o en 32 bits. 2. Se llama al ensamblador a través de la función wxexecute, pidiéndole que guarde en unos vectores de strings la respuesta que da el programa. 3. Se muestra por pantalla esta información usando llamando a la función ShowErrorsAndWarnings. 4. Si no hay errores, se llama a la función declarada como global SetAsmFinished, para la información de otros paneles y se abre la comunicación con el simulador. 5. También solo si no se han producido errores, se actualiza el panel con los registros y el APB y se carga el backannotation file en el panel del programa.

59 MEMORIA. INTERFAZ GRÁFICA OpenProcess Figura 43. Función OpenProcess. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Abre en proceso de comunicación con el simulador y monta los canales ( streams ) de envío y recepción de datos (p_is, p_os y p_es).

60 MEMORIA. INTERFAZ GRÁFICA KillProcess Figura 44. Función KillProcess. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Cierra el proceso del simulador a través de función wxprocess::kill y comprueba que se haya cerrado correctamente.

61 MEMORIA. INTERFAZ GRÁFICA Execute Figura 45. Función Execute. Argumentos de entrada: El comando, y dos bool, uno indica si se ha de imprimir en el panel de mensajes lo actualizado y otro si se han de actualizar los paneles. Argumentos de salida: 1 si ha ocurrido algún error, 0 si no. Función principal: Ejecuta el comando indicado en el simulador y actualiza los paneles con la información devuelta. Funcionamiento: 1. Comprueba que se haya ensamblado el proyecto, de no ser así no sigue adelante. 2. Escribe el comando en p_os seguido de un retorno de carro. 3. Si así se ha indicado, escribe en el panel de mensajes el comando escrito. 4. Espera a que haya algo como salida del proceso simulalor, p. 5. Lee la salida del proceso a través del canal p_is.

62 MEMORIA. INTERFAZ GRÁFICA Si se ha pedido, actualiza los paneles de toda la interfaz con la función UpdatePanels GetAndUpdateState Figura 46. Función GetAndUpdateState. Argumentos de entrada: Ninguno. Argumentos de salida: 1 si ha ocurrido algún error, 0 si no. Función principal: El comando print state en el simulador, y leyendo la información devuelta y comprobando con la función CheckString actualiza la estructura en la que se guarda el estado del simulador, ps.

63 MEMORIA. INTERFAZ GRÁFICA UpdatePanels Figura 47. Función UpdatePanels. Argumentos de entrada: Ninguno. Argumentos de salida: 1 si ha ocurrido algún error, 0 si no. Función principal: Actualiza los paneles de la interfaz a partir de la información del simulador almacenada en ps.

64 MEMORIA. INTERFAZ GRÁFICA CheckString Figura 48. Función CheckString. Argumentos de entrada: wxstring esperada, wxstring leída y stream de entrada. Argumentos de salida: bool con valor 1 si ocurre algún error. Función principal: Igual que la función implementada en el simulador, aunque trabaja con tipos de datos algo distintos, en lecturas de muchos datos, como al actualizar el estado, permite dar un error más específico. Se llama a la función varias veces en la lectura del fichero, y solamente se sigue leyendo si esta función no devuelve error. También se encarga de ignorar los comentarios.

65 MEMORIA. INTERFAZ GRÁFICA 63 3 Diálogo de configuración Figura 49. Diálogo de Configuración. Al abrir un proyecto o al crear uno nuevo se muestra su configuración, como se aprecia el la Figura 49 para poder modificarla fácilmente. En cuatro pestañas se indican: Opciones globales del simulador, como si los registros trabajan en 24 o en 32 bits, los tamaños de las memorias, y los nombres de los ficheros que maneja el programa. Las tareas implicadas en el programa, con sus prioridades y sus periodos.

66 MEMORIA. INTERFAZ GRÁFICA 64 Los esclavos del APB, con su tipo, su nombre y su posición en la memoria del APB. El archivo con el programa en ensamblador. Si se indica un fichero que no existe, se crea en blanco. Tras configurar todas estas opciones, la interfaz genera un fichero de configuración como el que se puede ver en los anexos, Capítulo 54.1, y al abrir el proyecto de nuevo simplemente carga la configuración en el diálogo a partir del fichero. 3.1 Estructuración en el programa Separación del diálogo y el panel Figura 50. Separación entre el diálogo y el panel de configuración. Por seguir una estructura homogénea en cuanto al método de programación de la interfaz en wxwidgets, se ha implementado el diálogo de configuración como un panel dentro de un diálogo, y no simplemente como un diálogo, como se puede ver en la Figura 50. De este modo toda la interfaz al completo son simplemente paneles, y se podría reorganizar

67 MEMORIA. INTERFAZ GRÁFICA 65 para meter el panel de configuración dentro de la ventana principal del programa si así se quisiera. Esta estructuración se ve reflejada en los ficheros de las fuentes del programa, se ha creado un fichero configure_dialog con su clase configure_dialog dentro, que crean en su interior un objeto de la clase confugure_panel que se implementa en los ficheros configure_panel. De querer por tanto colocar la configuración de otra manera habría que instanciar el panel, pudiendo eliminar el diálogo Clase project Se ha separado de las clases en las que se obtiene la configuración esta clase, en la que se guarda toda la información relativa al proyecto abierto en la interfaz. Aunque tiene valores por defecto, cuando se completa el diálogo de configuración se crea un objeto de esta clase, con los nombres de los archivos, la carpeta de proyecto y demás. Se deja así fácil crear una ampliación en la que se puedan tener más de un proyecto abierto. Aunque habría que cambiar más cosas en el aspecto gráfico, aquí simplemente habría que crear más objetos de la clase project. No se comentan sus funciones puesto que son muy básicas, tan sólo mencionar que existen las siguientes: SetProjectLoaded, IsProjectLoaded. SetAsmFinished, IsAsmFinished. SetProjectSaved, IsProjectSaved. SetProjectPath, GetProjectPath.

68 MEMORIA. INTERFAZ GRÁFICA Clase configure_panel Figura 51. Elementos principales de la clase configure_panel. La clase configure_panel se deriva de la clase wxpanel, estandar de wxwidgets. Comprende toda la distribución de la parte gráfica del panel, es decir, botones, cuadros de texto, listas, etc. y además una serie de funciones para manejar la configuración del proyecto. Se explican primero las funciones grandes, donde se concentra la mayor parte del código, y más adelante muy brevemente el conjunto de funciones que sirven para el manejo de eventos, como por ejemplo apretar un botón Datos principales de la clase configure_panel En los paneles está toda la información importante, de modo que tener el dato del nombre de un fichero, por ejemplo, se puede leer directamente del lugar donde el usuario introduce el texto. tasks es un vector donde se almacenan las tareas y las características de éstas que se introducen. Al ser un dato algo más complejo, se guarda en un vector aparte, para facilitar su manejo por las distintas funciones. slaves es un vector donde se almacena la información relativa a los esclavos, por razones idénticas a tasks Funciones principales de la clase configure_panel Apply

69 MEMORIA. INTERFAZ GRÁFICA 67 Figura 52. Función Apply Argumentos de entrada: Ninguno. Argumentos de salida: 1 si se produce algún error en el proceso, 0 si no. Función principal: Guarda en la clase project toda la información contenida en el diálogo de configuración si la función Check le dice que es correcta SaveFile Figura 53. Función SaveFile Argumentos de entrada: Nombre del archivo en el que se ha de guardar. Argumentos de salida: 1 si se produce algún error en el proceso, 0 si no.

70 MEMORIA. INTERFAZ GRÁFICA 68 Función principal: Guarda en un fichero externo (archivo de proyecto) toda la información contenida en el diálogo de configuración tras comprobar con la función Check LoadFile Figura 54. Función LoadFile. Argumentos de entrada: Nombre del archivo que se quiere cargar. Argumentos de salida: 1 si se produce algún error en el proceso, 0 si no. Función principal: Carga de un fichero externo (archivo de proyecto) toda la información sobre el proyecto al diálogo de configuración, para ello usa la función ya comentada en CheckString, y otra muy básica, ReadIgnoringComments Check Figura 55. Función Check Argumentos de entrada: Ninguno.

71 MEMORIA. INTERFAZ GRÁFICA 69 Argumentos de salida: 1 si se produce algún error en el proceso, 0 si no. Función principal: Comprueba que ningún campo esté vacío y que tengan nombres válidos, es decir, que los nombres no tengan espacios Funciones de manejo de eventos de la clase configure_panel A parte de las funciones ya explicadas, se han tenido que implementar algunas funciones auxiliares para que se ejecuten cuando ocurre un evento. Se mencionan a continuación sobre las diferentes pestañas Opciones globales Figura 56. Pestaña de opciones globales del panel de configuración. Como se pude ver, esta pestaña es muy sencilla, por lo que no se ha tenido que crear ninguna función para ningún evento Tareas

72 MEMORIA. INTERFAZ GRÁFICA 70 Figura 57. Pestaña de tareas del panel de configuración. Se han creado las siguientes funciones de manejo de eventos: 1. OnListTaskSelect, que se ocupa de cargar el periodo de la tarea y si está activa o no en la zona de abajo del panel cuando se elige una tarea nueva. 2. OnTaskAddButtonClick, que añade una tarea a la lista de la zona superior derecha del panel y añade un elemento al vector interno de tareas, tasks. 3. OnTaskDeleteButtonClick, que borra la tarea seleccionada de la lista de la zona superior derecha del panel y del vector interno de tareas, tasks. 4. OnTaskUpButtonClick y OnTaskDownButtonClick se ocupan de los botones que permiten reordenar las tareas en la lista y en el vector interno. El orden de las tareas determina su prioridad, siendo la tarea de mayor prioridad la posicionada en la parte superior de la tabla.

73 MEMORIA. INTERFAZ GRÁFICA OnTaskPeriodHexChange y OnTaskPeriodDecChange se encargan de que cuando se cambie el valor del periodo en uno de los paneles se guarde el periodo en el vector tasks. 6. OnTaskActiveCheckboxClick guarda el estado de la tarea en el vector tasks Esclavos de APB Figura 58. Pestaña de esclavos del panel de configuración. 1. OnListSlavesSelect carga en el resto de la pestaña la información relativa al esclavo que se selecciona. 2. OnSlaveAddButtonClick añade un esclavo a la lista y un elemento al vector slaves, donde se guarda la información sobre los esclavos. 3. OnSlaveDeleteButtonClick borra el esclavo seleccionado de la lista del panel y del vector slaves.

74 MEMORIA. INTERFAZ GRÁFICA OnSlaveUpButtonClick y OnSlaveDownButtonClick reorganizan los esclavos en la lista del panel y del vector, esto no tiene ninguna utilidad aparte de organizarlos como uno quiera. 5. OnSlaveNameTextChange cambia el nombre del esclavo en el vector y en la lista del panel según se cambia en el cuadro de texto. 6. OnSlaveTypeChoiceSelect cambia el tipo de esclavo dentro del vector y esconde o enseña el apartado del panel en el que se puede indicar si el esclavo es sólo de entrada, sólo de salida, o de entrada y salida, disponible únicamente para esclavos de tipo secuencial. 7. OnSlaveMemoryStartTextChange y OnSlaveMemoryEndTextChange guardan en el vector los valores de comienzo y fin de la memoria según los escribe el usuario. 8. OnSlaveInputFileTextChange y OnSlaveOutputFileTextChange Guardan en el vector slaves los nombres de los archivos de entrada y salida del esclavo. 9. OnSlaveSeqRadioSelect sirve para guardar en el vector slaves el tipo de esclavo secuencial. Si el esclavo no es de tipo secuencial no se puede seleccionar, al estar desactivado Archivo de ensamblador

75 MEMORIA. INTERFAZ GRÁFICA 73 Figura 59. Pestaña de Archivo ensamblador del panel de configuración Simplemente se ha añadido un función: 1. OnAsmOpenButtonClick abre un diálogo estandar de selección de archivo, y si se devuelve el nombre de un archivo que no existe, crea uno en blanco.

76 MEMORIA. INTERFAZ GRÁFICA 74 4 Panel del procesador Figura 60. Panel del procesador. En la Figura 60 se puede observar el panel de procesador de la interfaz gráfica, en él se muestra la información básica para conocer el estado del DSP. Este panel se ha implementado con una clase derivada de la clase wxpanel, que ha sido nombrada processor_panel. Figura 61. Elementos principales de la clase processor_panel. La clase processor_panel contiene los mínimos datos posibles, simplemente elementos gráficos, y luego tiene una serie de funciones para manejar su

77 MEMORIA. INTERFAZ GRÁFICA 75 apariencia y para obtener los datos de archivos o de la clase console, como se explica posteriormente, y presentarlos en el panel. 4.1 Datos principales Tabla ROM, se ha implementado con la clase wxgrid, en ella se muestra la memoria ROM, tanto sus valores en hexadecimal como cada instrucción desensamblada. Subrayada en verde está la instrucción actual del DSP, y en con letras en rojo aparecen los puntos de ruptura ( breakpoints ). Tabla de las tareas, aquí se puede ver el estado de las tareas en todo momento. Program Counter, tanto en decimal como en hexadecimal. Reloj del sistema, Clk, también en decimal y en hexadecimal. Flag del sistema, la bandera que se usa para instrucciones condicionales. Status word, la palabra de status que se recibe desde el exterior del DSP. 4.2 Funciones principales Load Figura 62. Función Load. Argumentos de entrada: Ninguno.

78 MEMORIA. INTERFAZ GRÁFICA 76 Argumentos de salida: Ninguno. Función principal: Lee de proyect los archivos del proyecto, y carga la tabla de tareas y la de ROM, para lo cual tiene que llamar a la función Disassemble Disassemble Figura 63. Función Disassemble. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Lee de proyect los archivos del proyecto, pide a console que mande al simulador crear un archivo de desensamblado, y lo carga a la tabla ROM Update Figura 64. Función Update.

79 MEMORIA. INTERFAZ GRÁFICA 77 Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Lee el dato ps de console, que contiene toda la información sobre en estado del procesador, y la carga en los distintos elementos del panel Breakpoints Figura 65. Funciones de breakpoints. Argumentos de entrada: AddBreakpoint y DelBreakpoint necesitan como entrada la dirección de la memoria en la que añadir o borrar un breakpoint. Argumentos de salida: Ninguno. Función principal: Cambia simplemente el color de la tabla ROM para indicar que hay un punto de ruptura o no.

80 MEMORIA. INTERFAZ GRÁFICA 78 5 Panel del programa Figura 66. Panel del programa. Como se puede ver en la Figura 66, el panel del programa es bastante simple, está implementado como un wxnotebook con dos pestañas, en la primera se carga el código en ensamblador y en la segunda tras ensamblar se carga automáticamente el fichero backannotation, en el que podemos ver el código escrito junto con el código que se ensambla, además se subraya en verde la instrucción que se está ejecutando en la simulación. Figura 67. Elementos principales de la clase program_panel. Se ha implementado el panel con una clase derivada de wxpanel, que se ha nombrado program_panel, cuyos elementos principales se pueden observar en la Figura 67.

81 MEMORIA. INTERFAZ GRÁFICA Datos principales program_text es el elemento de la clase wxrichtextctrl en el que se carga el código de ensamblador. Sobre él se puede crear y modificar el código como cualquier editor de texto básico. Backannotation_text es otro elemento de la clase wxrichtextctrl. Es de sólo lectura, por lo que simplemente sirve para comprobar el programa ensamblado y seguir su ejecución sobre el código. 5.2 Funciones principales LoadBA Figura 68. Función LoadBA. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Accede al objeto proyect para mirar el nombre del archivo a cargar, lo carga en el elemento backannotation_text y cambia de pestaña para mostrarlo.

82 MEMORIA. INTERFAZ GRÁFICA Update Figura 69. Función Update. Argumentos de entrada: Contador de programa de la simulación (PC). Argumentos de salida: Ninguno. Función principal: Busca en el backannotation_text la línea de código correspondiente al PC actual, la subraya y la muestra ShowError Figura 70. Función ShowError. Argumentos de entrada: Número de línea del error. Argumentos de salida: Ninguno. Función principal: Busca en el program_text la línea de código que tiene un error que impide el ensamblado, la subraya y la muestra.

83 MEMORIA. INTERFAZ GRÁFICA ClearUnderline Figura 71. Función ClearUnderline. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Limpia el backannotation_text de líneas subrayadas. 6 Panel de registros Figura 72. Panel de registros. El panel de registros cuenta con tres pestañas, en cada una de las cuales se puede ver la variable, su dirección en memoria y su valor tanto en hexadecimal como en coma flotante, como se puede ver en la Figura 72, se marca de color azul la variable que ha cambiado de valor en la última instrucción ejecutada. Las tres pestañas son:

84 MEMORIA. INTERFAZ GRÁFICA 82 Registers, donde están las variables internas del microprocesador. APB, donde se encuentran las variables tanto de entrada como de salida del APB. Watched, donde el usuario elige que variables quiere ver y en que orden, tanto de los registros como del APB, para poder controlar más cómodamente las que interesen. Figura 73. Elementos principales de la clase registers_panel. En la Figura 73 se pueden ver los elementos principales de la clase registers_panel, derivada como todos los paneles de wxpanel. 6.1 Datos principales Dos vectores de estructuras de datos (reg_info y apb_info) tienen toda la información que el panel necesita sobre cada elemento de los registros o del APB, los datos de la estructura son los siguientes: o name, el nombre de la constante o variable. o dir, su dirección en memoria. o value, su valor en hexadecimal. o value_f, su valor en coma flotante. o row, la fila en la que está representada la constante o variable en las tablas del panel.

85 MEMORIA. INTERFAZ GRÁFICA 83 o used, un valor con el que se marca al inicializar el vector las direcciones que se usan, puesto que el vector tiene el tamaño de la memoria, y no toda ella se usa. o watched, que indica que el usuario ha puesto también el elemento en la tabla de variables watch. o watched_row, para indicar en que fila de la tabla de variables a controlar se ha situado. o changed, que indica que el valor de la variable ha cambiado desde la última instrucción, para saber que se debe marcar. Las tres tablas, que son objetos de la clase wxgrid 6.2 Funciones principales Init Figura 74. Función Init. Argumentos de entrada: Nombres de los archivos a cargar y tamaños de las memorias de registros y del APB. Argumentos de salida: Ninguno. Función principal: Carga los valores iniciales de los registros y el mapa de variables tanto en los vectores internos reg_info y apb_info como en las tablas de los paneles.

86 MEMORIA. INTERFAZ GRÁFICA Update Figura 75. Función Update. Argumentos de entrada: El vector de strings que devuelve el simulador al objeto console cuando ejecuta print regfile y print apb. Argumentos de salida: Ninguno. Función principal: Almacena los valores actualizados de los registros y el APB en los vectores reg_info y apb_info Refresh Figura 76. Función Refresh. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Actualiza las tablas del panel con la información de los vectores.

87 MEMORIA. INTERFAZ GRÁFICA Watch y Clear Figura 77. Funciones Watch y Clear. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Manda la variable a la pestaña watch o la borra de él, modificando acordemente los vectores reg_info y apb_info Up y Down Figura 78. Funciones Up y Down. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Cambia de lugar los elementos de la tabla watch, almacenando los cambios en los vectores reg_info y apb_info.

88 MEMORIA. INTERFAZ GRÁFICA 86 7 Panel de mensajes Figura 79. Panel de mensajes. El panel de mensajes es donde la interfaz comunica la mayoría de la información. Como se ve en la Figura 79, el panel tiene dos partes diferenciadas, en la parte superior el programa muestra información para el usuario, mientras que en la parte inferior el usuario el puede introducir información o peticiones al programa. Cuando el usuario introduce un comando en la parte de abajo y pincha en ejecutar, la interfaz le transfiere el comando directamente al simulador, de modo que los comandos que se usan aquí son exactamente los mismos que con el simulador en modo interactivo. Figura 80. Elementos principales de la clase messages_panel. La simplicidad del panel se ve reflejada en la Figura 80, no obstante, se han definido unas funciones para el manejo de ciertos elementos del panel.

89 MEMORIA. INTERFAZ GRÁFICA Funciones de manejo de eventos Figura 81. Panel de mensajes con eventos a manejar. 1. OnExecuteButtonClick, que también se acciona cuando el usuario pulsa intro en la línea de entrada de comandos, lee lo introducido por el usuario en la línea de entrada y llama a la función Execute del objeto console. 2. OnExeFileButtonClick abre un diálogo para que el usuario elija un fichero con comandos para el simulador, y luego se lo pasa también a la función Execute del objeto console. 3. Clear simplemente borra el output_text. 4. OnLeftDClick se ejecuta cuando el usuario hace doble clic sobre el output_text, y su función es detectar si se ha pinchado sobre una lína con un error de ensamblador, y en tal caso llamar a la función ShowError del program_panel para que se marque el error. 8 Panel principal Los paneles ya detallados se juntan este panel que los engloba a todos, que a su vez está incluido en el marco principal, que contiene toda la interfaz gráfica.

90 MEMORIA. INTERFAZ GRÁFICA 88 Figura 82. Diseño del panel main_panel. Como se puede deducir de la Figura 82, el panel main_panel es muy sencillo, tan sólo tiene los sizers que dan la estructura a dónde debe estar cada panel, y su flexibilidad, y dentro de cada uno de los cuatro huecos hay punteros a los 4 paneles ya comentados. Figura 83. Panel main_panel.

91 MEMORIA. INTERFAZ GRÁFICA 89 En la Figura 83 se puede apreciar el resultado final con los cuatro paneles. 9 Marco principal ( Main Frame ) Figura 84. Marco principal del programa. El panel principal se instancia dentro de el marco gomal del programa, que también incluye la barra de herramientas y la barra de menús, para dar como resultado la ventana completa de la interfaz, como se puede observar en la Figura 84. Figura 85. Elementos principales de la clase GUIFrame.

92 MEMORIA. INTERFAZ GRÁFICA 90 El marco principal se ha implementado con la clase GUIFrame, derivado de la clase wxframe, en la Figura 85 se puede apreciar que alberga los objetos main_panel, console y project. La clase configure_panel, sin embargo, no está incluida en GUIFrame ya que se abre como un diálogo, aunque se crea desde esta clase. 9.1 Datos principales Esta clase contiene la barra de herramientas, derivada de wxtoolbar y la barra de menús, derivada de wxmenu, además de los objetos ya mencionados. 9.2 Funciones principales LoadConfig Figura 86. Función LoadConfig. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Tanto al querer abrir un archivo existente como uno nuevo, abre el diálogo de configuración y le indica al configure_panel que archivo tiene que cargar.

93 MEMORIA. INTERFAZ GRÁFICA Save Figura 87. Función Save. Argumentos de entrada: Ninguno. Argumentos de salida: Ninguno. Función principal: Le pide al configure_panel que guarde el archivo de configuración del proyecto, y al program_panel (dentro de main_panel) que guarde el archivo ensamblador. Se ejecuta cuado se pide guardar y cuando se va a ensamblar el proyecto. 9.3 Funciones de manejo de eventos Se han implementado funciones para manejar los eventos de la barra de menús y la barra de herramientas, aparte de OnClose, que se ejecuta cuando el usuario quiere cerrar el programa de cualquier manera, pidiendo confirmación Funciones de la barra de herramientas Figura 88. Botones de la barra de herramientas.

94 MEMORIA. INTERFAZ GRÁFICA Las funciones OnNew, OnOpen y OnSave abren los diálogos para elegir el nombre del archivo y respectivamente, abren un archivo nuevo, abren uno existente, o guardan todo el proyecto. 2. Las funciones OnUndo y OnRedo deshacen o rehacen el último cambio en el archivo de código del programa. 3. OnAssemble se encarga de pedirle al objeto console que llame al ensamblador y actualiza los paneles al terminar. 4. OnInit, OnStep y OnRunTask mandan al objeto console las peticiones de inicializar el simulador, ejecutar un paso o ejecutar una tarea. 5. Las funciones OnAddBreakpoint, OnDeleteBreakpoint y OnDelAllBreakpoint piden al simulador que borre añada un punto de ruptura, lo borre, o que borre todos, y al processor_panel que haga lo propio en la tabla de la memoria ROM. 6. OnRegistersWatch, OnRegistersClear, OnRegistersUp y OnRegistersDown llaman a las funciones Watch, Clear, Up y Down de registers_panel Funciones de la barra de menús Figura 89. Barra de menús. En la barra de menús se accede a las mismas funcionalidades del simulador que en la barra de herramientas y alguna más. En la Figura 89 se ve que está dividida en cinco partes File

95 MEMORIA. INTERFAZ GRÁFICA 93 Figura 90. Submenú File de la barra de menús. El submenú contiene las opciones de la Figura 90, que llaman respectivamente a las funciones OnNew, OnOpen y OnSave ya comentadas, y a OnQuit, que intenta cerrar el programa, pero OnClose captura el evento y pide confirmación Edit Figura 91. Submenú Edit de la barra de menús. Desde el submenú Edit se accede a deshacer o rehacer un cambio en el código del programa ensamblador, con OnUndok y OnRedo, y al diálogo de configuración del proyecto, a través se OnConfigure Assemble Figura 92. Submenú Assemble de la barra de menús. Tan sólo se presenta la opción de ensamblar el proyecto, usando la función OnAssemble Simulate

96 MEMORIA. INTERFAZ GRÁFICA 94 Figura 93. Submenú Simulate de la barra de menús. Desde el submenú Simulate se presentan las opciones que se ven en la Figura 93, que por orden llaman a OnInit, OnStepk, OnRunTask, OnAddBreakpoint, OnDeleteBreakpoint y OnDelAllBreakpoint, ya comentadas, y por último la opción de que el simulador compruebe la simulación generada por ModelSim, a través de la función OnCheckVhdl, que simplemente pasa la petición al objeto console para que se comunique con el simulador Help Figura 94. Submenú Help de la barra de menús. Figura 95. Diálogo de About.