2010-II/es/Digital2 2010 PaInTES

From Qi-Hardware
Jump to: navigation, search
PaInTES

http://www.youtube.com/watch?v=eh19OhX71IY

Contents

[edit] PaInTES

==Calificación==
Porcentaje Presentación 20% Informe 30% Funcionamiento 50%
1 Entrega 10% 3.5 3.5 3.5
2 Entrega 30% 3.0 3.0 3.0
3 Entrega 20% 5 5 4
4 Entrega 40% 5 5 5

Se desea implementar en la tarjeta de desarrolo SIE, emulando el procesador lm32 (Lattice) en la FPGA , el conocido programa PAINT o PAINTBRUSH. La interfaz del usuario se hará con los siguientes periféricos: Mouse y LCD gráfico a color. Además el programa contará con un menú que le permitirá al usuario elegir la forma de la brocha ( circulo, estrella, cuadro, slash ), el tamaño ( x1 x2 x3 ) y el color.

[edit] Especificaciones

  • Fisicas:
El dispositivo medirá 80 mm X 80 mm X 3 mm
  • Temporáles:
La visualización será en tiempo real
  • Funcionales:
Contará con una interfaz gráfica y un menú de opciones de dibujo.
Fig1 Interfaz Gráfica con el usuario
  • Eléctricas:

La alimentación del mouse se hará desde el SIE y sera de 3.3v

  • Especificaciones de Memoria:

Al trabajar con un LCD grafico es de suma importancia considerar, la cantidad de memoria requerida y su implemtenacion en hardware, en nuestro caso la resolución maxima del LCD es de 320x240 pixeles, este se puede tratar como una matriz viendolo desde el punto de vista de hardware, el funcionamiento del LCD consiste en realizar un barrido de la pantalla de acuerdo a la sincronización de dos señales (vertical-horizontal), a medída que se hace el barrido se pone el dato correspondiente a cada pixel, para PAINTES presentamos dos opciones de las cuales se escogera la mas optima en el debido momento del desarollo del modulo de video, siempre con el proposito de evitar el uso de una memoria externa debido a la cantidad de pines disponibles, y a que usar memorias SPI elevaria mucho la complejidad del proyecto. Opción 1

320X240=76800  : Cantidad de espacios de memoria (Resolución)
2              : Cantidad de bits del dato       (Manejo de 4 colores)
De acuerdo a esto necesitamos una memoria RAM que almacene 76800 palabras de 2 bits, es decir la cantidad de memoria de video requerida es de 
153600bits = 150K

Opción 2

160X120=19200  : Cantidad de espacios de memoria (Resolución)
4              : Cantidad de bits del dato       (Manejo de 16 colores)
De acuerdo a esto necesitamos una memoria RAM que almacene 19200 palabras de 4 bits, es decir la cantidad de memoria de video requerida es de 
76800bits = 75K

Sobre el hardware disponible que tenemos es decir la FPGA, y de acuerdo a su hoja de especificacion, tenemos en su interior bloques dedicados fuera de la logica a la sintetizacion de RAM llamados BRAM (ram blocks), en el modelo XC3S500E, que es el del SIE , se pueden implementar BRAM, maximo de 18K, pero se pueden implementar 20 de estos, lo que produce una capacidad maxima de 368640 bits 360K, pero con el limitante que el maximo numero de espacios de memoria de cada bloque es de 8192, considerando esto se propone hacer arreglos de memorias RAM dentro de la FPGA, que llamaremos memórias de video, partiendo el LCD en matrices mas pequeñas que se iran refrescando dependiendo de posicion del mouse, de acuerdo a esto la opcion 2 parece ser la mejor ya que requiere menor cantidad de espacios de memoria, (nuestra principal limitante) sin embargo por precaución y debido a la consideracion de que la memoria de programa pueda extenderse, (frente a esto también se podría ampliar la BRAM interna desde donde se bootea ), en el diseño de nuestro PCB se agrega una memória RAM SPI debido a la falta de pines del SIE, en caso de no requerirla no se soldara.


[edit] Cronograma de Actividades

El siguiente Cronograma muestra el tiempo que se invertirá en realizar las tareas hardware y software del proyecto. Este cronograma estará sujeto a cambios de acuerdo al cronograma académico de la matéria.

[edit] Diseño Esquemático y PCB


Para el diseño del esquemático se hicieron las siguientes consideraciones:

  • Las lineas de datos y clock del PS/2 son ambas colectores abiertos. Esto significa que deben tener resistencias de pull-up a VCC, ya que toman el estado bajo('0') o alta impedancia ('Z').
  • Se agrega el pad para una memoria ram SPI que en caso de ser requerida, se soldara o no.



[edit] Particionamiento de Taréas (Diagramación por Bloques)

  • Adquisición de la señal de posición del mouse (HW)
  • Controlador del dispositivo PS/2 (host) (SW)
  • Tratamiento de la posición del mouse (SW)
  • Crear Datos de la interfaz gráfica (SW)
  • Llenado de una memoria de video con los Datos para el LCD (SW)
  • Generar los datos para las señales de sincronización horizontal y vertical del LCD (HW)
  • Memoria de video (HW)
  • Visualizar los datos tomados desde la memoria de video y enviarlos al LCD considerando el refresco dinámico y la visualizacion de la interfaz y el puntero en tiempo real (PINTAR) (HW).
Fig2 Diagrama de bloques general del proyecto

[edit] Diagrama de flujo del funcionamiento general

Inicialmente se recibe la señal que contiene la información sobre la posición del puntero del mouse que posteriormente es visualizada inmediatamente gracias al refresco dinámico. Si se llega a oprimir el botón izquierdo del mouse, se procede a comparar su posición y en qué sección del entorno gráfico se encuentra. De esta manera se puede controlar qué acción desea realizar: cambiar la brocha, su tamaño o dibujar sobre el espacio de dibujo.


[edit] Mapa de memoria

En la descripción de hardware, PaInTES maneja dos perifericos, PS/2 y una memoria de video, en donde se almacena y realiza el refresco dinámico de la visualición del LCD , en base a esto y a la consideración de la memoria de programa desde donde se realiza el booteo de nuestro programa (bloque de ram interno sintetizado en la FPGA BRAM) se presenta el mapa de memoria, del proyecto.

Fig3 Mapa de memoria
  • BRAM

El espacio de memoria designado para este periferico, se basa en el tamaño de nuestro código de programa inicialmente proponemos 8K de almacenamiento, a medida que se vallan desarrollando los perífericos, se tendra la posibilidad de ampliar esta memoria hasta un tamaño de 16K, nuestra limitante es dada por el tamaño de bloques de ram internos que se pueden sintetizar el la FPGA.

  • PS/2

El Protocolo de comunicación requiere del manejo de tres registros básicos desde software, dos encargados de datos uno para lectura, otro para Escritura, y un registro general de estado y control, desde donde se leen las señales de interrupcion_activada, y un indicador de cuando hay una transmision esta en proceso y el periferico se encuentra activado, las señales de CS, y WE tipicas, sin controladas por el modulo wishbone comparando la dirección del bus del procesador, con un decodificador interno en donde se lista cada periferico.

// Wishbone PS/2
//
// Register Description:
//
//  BASE = 0xF0002000
//
//  BASE + 0x00 PS/2_CR (control and status)   
//  BASE + 0x04 TX      (Transmition) (WR)					
//  BASE + 0x08 RX      (Reception)   (RD)
//
// PS/2_CR:  
//    +-------------+-------+-------+-------+----------+---------+
//    |    3b'0     |  IRQ  |   Rx_avail    |   2b'0   | tx_busy |
//    +-------------+-------+-------+-------+----------+---------+
//
//   IRQ      (RD)   Chequea si el periferico activo la señal de interrupción
//                
//   tx_busy  (RD)   Chequea si se esta transmitiendo un dato

[edit] Módulo PS/2

TAREA-HW      : Adquisición de la señal de posición del mouse (PROTOCOLO PS/2)
TAREAS-SW     : Controlador de PS/2:   Desde software se emulara el host sobre el dispositivo del mouse, ya que este requiere de una 
                inicialización,  un cambio al modo de transmision continua de datos (Modo Stream), y también la definición de los limites 
                de la pantalla para configurar la resolución.

[edit] Funcionamiento

El movimiento del ratón debe ser decodificado, para luego generar señales que representen el desplazamiento en las coordenadas X y Y, y los estados de los botones. En este caso no se implementará la llamada coordenada Z que corresponde al scroll del mouse y tampoco el botón derecho.

El desarrollo del módulo PS/2 se hará en 3 etapas:

  • Módulo de la Interfaz PS/2: Este utiliza un protocolo serial bidireccional y se encarga de la comunicación entre el ratón y el controlador.
  • Controlador: Recibe los datos del mouse y entrega su posición y los estados de los botones.
  • Informador de la resolución: Indica el tamaño de las barreras de la pantalla y se encarga de calcular los valores máximos de X y Y, y entrega la posición inicial del mouse.

Al iniciar el programa el mouse envía una señal de identificación al host, y este devuelve otra señal que le indica al ratón en qué modo operar (es por esto que dos de los puertos del módulo deben ser bidireccionales), estos modos son los siguientes:

  • Modo Reset: Es el modo inicial
  • Modo Stream: Es el modo de operación por defecto, en el cual el mouse envía sus paquetes de datos de datos cuando ocurre algun movimiento o cambia algun estado de los botones.
  • Modo Remote: El controlador hace un sondeo de los paqutes de datos de movimiento.
  • Modo Wrap: Es un modo de diagnóstico en donde el mouse y el controlador están enviandose datos constantemente en forma de eco.

Las señales que recibe el módulo de interfaz son: PS/2_CLK y PS/2_DATA (ambos bidireccionales). Por otro lado, el controlador recibe del mouse un paquete de información de movimiento de 3 bytes. Este paquete está descrito de la siguiente forma:

Paquete de información de movimiento del mouse

Las señales de overflow son debidas al desbordamiento que generan los contadores de la posición de las coordenadas X y Y. Este contador depende de la resolución, por defecto, son 4 conteos por milímetro (4counts/mm).

La línea de datos de 11 bits se muestra a continuación:

Linea de datos

[edit] Comandos de envío al Mouse

Comando Descripción
0xFF Reset El mouse entra en modo reset.
0xFE Resend En caso de que halla un envío inválido del dato, el host pide un nuevo envío
0xFC Error Si vuelve a haber envío inválido, el host envía una señal de error al mouse y lo resetea
0xF6 Set Defaults El mouse se carga con los valores por defecto de: Samplin rate = 100, resolución 4counts/mm, Scalamiento = 1.1, data reporting= Desactivado; Se resetea y entra en modo Stream.
0xF5 Disable Data Reporting Resetea y Desactiva el Stream mode
0xF4 Enable Data Reporting Habilita su envio de datos.
0xF3 Set sample Rate Lee un byte del host indicándole su Sample Rate (10,20,40,60,80,100,200 Samples/sec)
0xF2 Get Device ID El mouse envía su ID (0x00 para el mouse estàndar) y se resetea.
0xF0 Set Remote Mode Entra en modo remote
0xEE Set Wrap Mode Entra en modo wrap
0xEB Read Data El mouse envía su paquete de datos de movimiento, esta es la única forma de acceder al dato en caso de estar en remote mode
0xEA Set Stream Mode Entra en modo Stream
0xE9 Status Request Envía su paquete de 3 bytes de estatus

Después de que el host envíe cada comando, el mouse responderá siempre con un acknowledge (0xFA) y cumplirá las órdenes de acuerdo al comando. Para este proyecto se trabajará en la mayoría de su tiempo con el modo de operación Stream, para que el mouse esté enviando constantemente los datos de movimiento.

[edit] Maquina de estados y Camino de Datos

El modulo PS/2 tiene 6 estados principales, en los cuales se tiene la comunicación host-device, en la inicialización el mouse envia un dato al controlador que por defecto es "FA", con esto se le indica al controlador que el dispositivo esta listo, y se realiza una escritura indicandole al mouse en que modo debe funcionar, luego el dispositivo comienza un envio continuo de datos al controlador indicando la posición y estado de los botones.

Fig4 Maquina de Estados PS/2
  • Receive: Se toman los datos de ps2_data, que estan e n serie, se convierten en paralelo y almacenan en un registro temporal, todo esto a flancos

de reloj de ps2_clk, ademas se almacena en un registro (tx_data), el dato proveniente del controlador que se quiera transmitir mas adelante.

  • Wait_Ready:Se esperar un tiempo a que se complete el paquete de datos que esta en paralelo, eso mediante una variable que cuenta la cantidad

de bits del paquete (rx_bitcount) de acuerdo al parametro de velocidad de baudios del dispositivo

  • Clock_Low: Inicia el proceso de transmisión, el controlador pone en bajo ps2_clk, durante al menos 100us este tiempo se controla por un divisor

(watchdog_timer)

  • Clock_High: Se le da el control de la linea al dispositivo para que genere su propio clock
  • Wait_Clock_Low: Se esperar la señal ps2_clk=0 que indica que el dispositivo esta listo para recibir el paquete de datos enviado por

el controlador

  • Transmite: Se convierte de paralelo a serie tomando los datos de tx_data (previamente almacenado), y se realiza la transmisión, a flancos de

ps2_clk reloj generado por el mismo dispositivo.

Fig5 Camino de Datos PS/2


[edit] Puertos bidireccionales PS2_data y PS2_clk

El protocolo de comunicación PS2 Host-to-Device involucra intercambio de datos mediante puertos bidireccionales. Estos puertos de la interfaz PS/2 son llamados PS2_data (PS2d) y PS2_clk(PS2c).


Fig6 Tristate de los puertos bidireccionales PS2


  1. Cuando el mouse quiere enviar un dato, la línea del ps2c se coloca en bajo y el host reconoce que hay transferencia.
  2. Cuando el host quiere enviar un dato, hace su petición, mantiendo en bajo la línea del clock al menos por 100 uS.
  3. Después la línea ps2c se desactiva, esto es, ponerse en alta impedancia, y el mouse empieza a generar sus propios pulsos de reloj.
  4. Cuando se reciben los datos, los bits son leidos de PS2d en el flanco de bajada del reloj y cuando se envían los datos lo hace en el flanco de subida.

Esto es básicamente lo que se intentó plasmar en el código de simulación para diferenciar la transmisión de la recepción.

[edit] Simulación del módulo PS/2

A continuación se muestra la simulación del módulo PS/2 (Host To Device: Transmisión y Recepción) Programa Utilizado: Icarus (visualizado en GTKWave)


Fig7 Simulacion Módulo PS2 Tranmisión y Recepción


Para el caso de Recepción, el mouse genera el clock para su envío de datos al host. Es entonces, cuando se reciben datos seriales y que se convierten a paralelo gracias a variables contadoras (rx_bitcount). Cuando rx_bitcount llega a 11, el host reconoce que se ha recibido un paquete de 11 datos seriales. Si se observa claramente en la zona de recepción de la imagen, la variable rx_data (hexadecimal), va teniendo un corrimiento de datos de acuerdo a como ps2_data se lo indica.

Para el caso de Transmisión el host debe recibir una señal de control csr_we = 1 de la cpu enlazada por medio de wishbone (mostrada como we_reg señal interna del módulo). Cuando esta señal se coloca en alto el host reconoce que debe transmitir un dato paralelo (csr_di = 0x86 = 10000110 ) por el puerto ps2_data y la señal tx_busy se activa en alto. Es ahi donde se debe generar de nuevo un clock. Con la variable contadora asginamos el dato de transmisión de tx_data[rx_bitcount] a ps2_data en cada flanco de reloj. Finalmente, la señal encerrada en un recuadro rojo ps2_data_out2, es la señal de transmisión de 11 datos (stop+data+paridad), ya convertida en serie y que posteriormente recibirá el mouse.

[edit] Interrupciones lm_32

El periferico PS/2 por tratarse de un periférico de entrada y salida de datos, en su estado de recepción, requiere de ser atendido a tiempos que no se pueden controlar desde el procesador, es por eso que se presenta una señal de interrupcion, y su respectiva rutina de atención, dentro de la estructura general el lm32 cuenta con un controlador de interrupciones que tiene como entrada, un vector IRQ que almacena cada señal de interrupcion proveniente de los perifericos que lo requieran, en nuestro caso solo el PS/2 requiere de ser atendido, cuando se halla hecho la recepcion de un dato desde el dispositivo, y la rutina de atención consistiria, basicamente en leer el registro rx (0xF000200C).

En el siguiente ejemplo mostramos la simulacion de una rutina de atencion a una interrupion presentada por el periferico timer que se encuentra dentro de los cores que trae el lm32, nos parece importante mostrar esto porque para el correcto funcionamiento del PS/2 hay que entender esto a plenitud, ademas de que en los ejemplos que trae el procesador nunca se hace el manejo de una interrupción.

#include "soc-hw.h"
//Rutina de interrupción definida por nosotros
void irq_handler(uint32_t irq)
{	
      volatile unsigned int     *data_irq;
      volatile unsigned int     irqc; 
 	irqc=0;
	data_irq = (unsigned int   *)(0x20000700);
	if(irqc == 0x00000002)        *data_irq = irqc;
	else *data_irq = 0xFFFFFFFF; 
}
int main()
{
	volatile unsigned int     *data_test;
	volatile unsigned int     test;
    	data_test = (unsigned int   *)(0x20000900);
//   Activación y enmascaramiento para habilitar la interrupción del timer   
	irq_enable();
	irq_set_mask( 0x00000002 ); 
	
 return 0;
}

En la simulación se ve como se activan al realizar escrituras en los registros compare y counter del timer, se activa la interrupción, y se atiende la primera rutina que se definio, con lo cual se comprueba que si esta funcionando las interrupciones, y ademas que el enmascaramiento es correcto, ya que el dato escrito en la rutina al que apunta la direccion 200000700 es el vector de interrupciones en este caso 00000002

Fig8 Simulación_atención_de_una interrupción

[edit] Implementación PS2

Para la implementación del modulo PS2 unido como periférico al procesador lm32 se realizo el montaje mostrado en la figura 1, se hicieron pruebas de recepción y transmisión depurando el dato en la UART, al energizar el mouse este realiza una rutina de aseguramiento BAT (Basic Assurance Test), si la rutina es correcta el mouse devuelve al controlador el dato 0xAA, seguido del ID del mouse en donde se identifican las caracteristicas principales del mouse dependiendo del código, en nuestro caso envia 0x00 la trama de datos se registro con osciloscopio y se muestra en la figura 2, en base a esta trama se hizo la simulación considerando la frecuencia del clock y el espaciamiento entre palabras, finalmente se implementaron las tareas software del PS2 declaradas en la siguiente estructura.

#define PS2_DR    0x20                    // Rx available
#define PS2_BUSY  0x01                    // TX Busy
#define PS2_IRQ   0x10                    // IRQ
typedef struct {
   volatile uint32_t ucr;//0xF0020000
   volatile uint32_t rx;//0xF00200004
   volatile uint32_t tx;//0xF0020008
   volatile uint32_t bitcount;//0xF002000C
} ps2_t;


Se agrego el respectivo pin de interrupción a la unidad encargada del procesador, en el codigo en C se hace la inicialización del mouse, cuando se energiza el mouse, este envia la trama de datos generando una interrupción cada vez que se cuente el bit número 10 de la palabra, por lo tanto en la rutina de manejo de interrupción se hace la lectura del dato y lo comparamos con AA o 00 que es lo que deberiamos esperar, en caso de que los datos leidos sean iguales los imprimimos enla UART representando el 0xAA como "@" junto con algunos flags de depuración los resultados vistos con minicom se muestran en la figura 3

Después de recibir estos datos de identificaciòn, el mouse entra en modo stream, sin embargo, este modo tiene deshabilitado por defecto el envío de datos; así que el host debe transmitirle el comando 0xF4 de activación y luego de esto, el mouse empieza a enviar un paquete de 3 bytes por cada cambio de posición. En la figura 2, se muestra los datos recibidos continuamente del mouse, correspondientes al primer byte o byte de status, con el fin de conocer el comportamiento de los contadores internos y el manejo de las coordenadas de posición. En esta imagen se puede observar una serie de números en un rango de 0 a 3. Estos números decodifican los 4 bits más significativos del byte de status (X overflow, Y overflow, X sign, Y sign); y muestran que el movimiento no tiene overflow. Debido a que se trata de un paint, el movimiento del mouse jamás será grande, así que el overflow de los contadores internos no se tendrá en cuenta.

[edit] Módulo LCD

TAREAS-HW      : Generación de las señales de sincronización horizontales y verticales del LCD, manejo de tiempos (Divisiones de frecuencia,
                Back porch ,Front porch), Implementación de una BRAM en donde se almacenaran los datos a pintar. 
TAREAS-SW     : Se genera una matriz de la resolución del LCD con los datos correspondientes a la interfaz gráfica, y la posición del mouse,
                se realizan las escrituras dependiendo del estado de la BRAM.

[edit] Funcionamiento

El LCD del sie de referencia GPM940B0 tiene distintos modos de operación. En este caso, se utilizará el modo RGB en paralelo, ya que es el modo de operación por defecto. Las señales con las que debe contar este módulo son las siguientes:

Señal Descripción
HSYNC Señal de Sincronismo Horizontal (Activa en bajo).
VSYNC Señal de Sincronimo Vertical (Activa en bajo).
CLKIN Clock de los Datos de Entrada.
DE_CLK Comando de Enable Serial.
LCD_DATA[7:0] Datos.

Por supuesto,el LCD cuenta con más señales seriales de configuración que deben ser implementadas por medio del protocolo I2C. Sin embargo, los valores de configuración por defecto, tales como el contraste, el brillo, los márgenes, Voltajes de control, modo de operación, Back Light, entre otros, son valores útiles para este proyecto y no es necesario modificarlos, excepto el registro que controla la secuencia de encendido que se hablará más adelante.

Las señales del módulo, deben cumplir con ciertos paràmetros de tiempo, mostrados a continuación:

Fig9 Tabla Tiempos
Fig10 Diagrama de Tiempos

[edit] Diagrama de Bloques

El módulo de LCD cuenta con 2 bloques internos controlados por medio de una máquina de estados. El primero de ellos es una memoria RAM interna en la FPGA, en donde se almacenarán los datos generados desde software. El segundo bloque, se encarga de la activación y la sincronización de las señales del LCD.

Fig11 Diagramación por Bloques módulo LCD

[edit] Ram_Video

TAREAS-HW     :Lectura e Inicialización. 
TAREAS-SW     :Escritura mediante cuatro registros tres de direccion uno por 
               cada memoria y un registro de datos compartido por las tres .


Este modulo fue construido con las siguientes caracterìsticas : una resolucion inicial de 320x240 y disponibilidad de 2 colores (76900 espacios de memoria de 1 bit) multiplexándolos con el fin de obtener 8 bits (0x00 o 0xFF) para ser leido por el LCD, de doble puerto con operacion de lectura sincrona, dada la necesidad de escribir y leer al mismo tiempo. En la implementacion de la memoria, nos enfrentamos con cinco problemas básicos debido a que tuvimos que anidar cinco ram internas de la FPGA de 16383x1 bits cada una.

Cabe resaltar que, los datos de envío al LCD deben ser 3 tramas de 8 bits debido al modo de uso por defecto: RGB de 8 bits. Como para la trama RGB para blanco o negro los tres bytes deben ser todos uno o todos cero, cada dato de salida de la memoria, se leerá 3 veces, y así se reducirá la memoria a utilizar.

Inicializacion

Se busco una forma de inicializar las memorias desde hardware ya que en software, esto ocuparia memoria de programa y ocuparia al procesador sin necesidad, la idea es que las memorias inicialmente contengan la informacion estatica que se visualizara en el LCD (Figura 1), para esto implementamos la siguiente instruccion que permite hacer un llamado a un archivo externo de extension .ram que contiene los datos en formato hexadecimal para cada posición de memoria de los distintos bloques.

initial 
if (mem_file_name != "none")  
 	begin
		$readmemh(mem_file_name, ram);
	end   

Escritura (Puerto A)

Luego de tener la imagen base en el LCD que logramos desde la inicialización necesitamos que para cada cambio en la posición del mouse, se realize una escritura a la memoria desde SW a una direccion determinada con el dato correspondientem, como tenemos 5 memorias andidadas, esto nos divide la pantalla del LCD en cinco espacios y nos da cinco registros de direccion que son conectados directamente a wishbone, pero un unico registro de datos que se conecta simultaneamente a las cinco memorias; la escritura se multiplexa con una señal de Write_enable para cada bloque de memoria que se activa si el procesador apunta a la dirección correspondiente de cada bloque y simultaneamente inhabilita las demas.

Lectura (Puerto B)

Como la lectura es un operación que se debe realizar todo el tiempo, se realiza en HW y se implemento el puerto de direccion de lectura como un contador que va recorriendo todas las posiciones de memoria de cada bloque, mientras la cuenta este entre 0-16383 el dato es leido del bloque0, entre 16384-32766 se lee del bloque1, entre 32767-49149 se lee del bloque2, entre 49150-65532 se lee del bloque3, entre 65532-76799 se lee del bloque4. La maquina de control se encargara posteriormente de enviar los datos al modulo de sincronización del LCD.

Fig12 Data_Path LCD

La maquina de control solo se encarga de habilitar la lectura de las memorias cuando el modulo de SYNC le indique mediante las señales de H_DONE y V_DONE, al estar en alto estas dos señales, se inidica que el dato entregado al LCD es valido, de lo contrario no se debe realizar lecturas de los datos para no perder la continuidad de la informaciòn y se debe permanecer en espera hasta el proximo tiempo de dato valido.

Fig13 MachineState_LCD

[edit] Secuencia de Encendido

Como se dijo anteriormente, el LCD necesita habilitar una señal para encenderse. Esta señal se puede modificar mediante el registro R05h que se encarga de las configuraciones para el funcionamiento del Back light.

Secuencia de Encendido

Como el registro tiene por defecto (en el LSB) la señal STB en cero, es necesaria ponerla en alto para poder iniciar la secuencia de encedido y poder controlar el Backlight a partir del convertidor interno. Es por esto que es necesario enviarle el comando serial correspondiente al registro R05h el valor: 0000010101011111.

Comando Serial: Registro R05h de control de LCD

[edit] Simulaciones

A continuación se muestran las distintas simulaciones del módulo LCD. Programa Utilizado: Icarus (visualizado en GTKWave) e ISE webpack 10.1


Fig14 Sim sincronizacion de señales LCD

En la primera imagen se muestra el diagrama de tiempos para el llenado de las dos primeras lineas verticales del LCD junto con la lectura del dato desde los bancos de memoria que sola es valida cuando H_DONE y V_DONE estan en alto, se puede observar que el dato leido no cambia mientras que el dato no sea valido para el LCD

Fig16 Sim secuencia de encedido serial

La segunda imagen, corresponde a la simulación Post-Place & Route de la herramienta ISE Webpack. Esta es la simulación más veraz que se puede realizar ya que se efectúa en tiempo real. Como se puede observar, la señal SPENB se activa en bajo cuando se envía un dato serial SPDA (correspondiente al valor del Registro R05h modificado) sincronizado con el clock SPCLK, tal y como se muestra en la imagen de explicación de envio de comandos seriales.

Despues de enviar este comando, y de haber encendido el backlight del LCD, se procede a verificar las señales de sincronizaión por medio del envio de datos. Esto se hace con el fin de observar si la imagen es estática, o si la inicialización de la memoria de video es correcta.

Fig14 Columnas

[edit] Union de los Periféricos: PaInTES

Habiendo probado cada uno de los periféricos junto con el procesador, se hace la unión final por medio de software. Desde allí, se comparan las líneas de datos obtenidos del mouse para tomar acciones que permitan pintar en el LCD.

  • Con los botones izquierdo y derecho del mouse, se pintan 4 pixeles del LCD de negro o blanco respectivamente.
  • Con los bits de signo del byte de estatus (o primer byte), se halla el signo del movimiento relativo de las coordenadas x y y.
  • Con los bytes de movimiento en coordenadas x y y, se halla la posición final que posteriormente se convierte a una direccion de memoria que representa cada pixel.


Y, finalmente, se obtiene PaInTES.


[edit] Limitaciones y futuras Optimizaciones

Para futuras optimizaciones del dispositivo se considerarán las siguientes falencias:

  • PaInTES no cuenta con un puntero de mouse, debido a que la lógica de la fpga necesaria para realizar sobrepasaba el 100%.
  • No se logró crear una plantilla de menú de opciones.
  • No se manejó paleta de colores ni tipos o tamaños de brochas.

[edit] Análisis de Costo de Proyecto

[edit] Costo del Prototipo

Para la construcción del prototipo se tuvio en cuenta lo siguiente:

Elemento Precio
Tarjeta de Desarrollo SIE $ 198.000.
Elementos Pasivos: Condensadores, Resistencias, Bobinas $ 32.000
Conector tarjeta Hija (2) $ 16.000
Semiconductores: Diodos, Transistores $ 3.000
Conector PS/2 $ 2.800.
Fabricación PCB montaje superficial $ 32.000
TOTAL MATERIALES $ 283.800.

El dispositivo se desarrolló durante 4 meses trabajando 2 horas diarias en 6 días hábiles al mes. El valor de la hora por ingeniero es de $ 45.000 pesos, por lo cual, el costo total de la mano de obra es: $ 17'280.000.

COSTO TOTAL DEL PROTOTIPO: $ 17'536.800.

[edit] Costo de producción de 100 unidades

El Costo de producción de una unidad es:

Elemento Precio
Tarjeta de Desarrollo SIE $ 198.000.
Elementos Pasivos: Condensadores, Resistencias, Bobinas $ 20.850
Conector tarjeta Hija (2) $ 11.000
Semiconductores: Diodos, Transistores $ 2.100
Conector PS/2 $ 2.400.
Fabricación PCB montaje superficial $ 28.000
Valor Agregado $ 50.000
TOTAL $ 312.350.

El costo de 100 unidades es: 31'235.000.


CREADORES:
Angela Patricia Alzate Giraldo 261450
Nicholas Peralta León 261496

To download source of project copy that in a terminal: git clone git://github.com/nperaltal/PaInTES.git

Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export