DISEÑO LÓGICO II 2002



Documentos relacionados
UNIDADES FUNCIONALES DEL ORDENADOR TEMA 3

Tema 4. Gestión de entrada/salida

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

I2C. Ing. Pablo Martín Gomez

Capítulo 9. Archivos de sintaxis

WINDOWS. Iniciando Windows. El mouse

Oficina Online. Manual del administrador

Manual de Usuario. XCPDriver

CAPÍTULO 4. EL EXPLORADOR DE WINDOWS XP

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos.

Curso sobre Microcontroladores Familia HC9S08 de Freescale

MANUAL DE AYUDA. SAT Móvil (Movilidad del Servicio Técnico)

GENERACIÓN DE TRANSFERENCIAS

DESCRIPCION DEL SITEMA MASTER.

Resumen ÁREA DE FACTURACIÓN::INFORMES::Pedidos Detalle Resumen ÁREA DE

GedicoPDA: software de preventa

Manual del Usuario. Sistema de Help Desk

Tema 7. SISTEMAS SECUENCIALES SISTEMAS SECUENCIALES SÍNCRONOS

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Introducción a la Firma Electrónica en MIDAS

18. Camino de datos y unidad de control

GUIA APLICACIÓN DE SOLICITUDES POR INTERNET. Gestión de Cursos, Certificados de Aptitud Profesional y Tarjetas de Cualificación de Conductores ÍNDICE

Toda base de datos relacional se basa en dos objetos

SERVIDOR WEB PARA ACCESO EN TIEMPO REAL A INFORMACIÓN METEOROLÓGICA DISTRIBUIDA

MANUAL DE AYUDA MODULO TALLAS Y COLORES

Manual de uso de la plataforma para monitores. CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib

Capítulo 5. Cliente-Servidor.

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

TEMA 20 EXP. WINDOWS PROC. DE TEXTOS (1ª PARTE)

V Manual de Portafirmas V.2.3.1

TPV Táctil. Configuración y Uso. Rev /01/09

2_trabajar con calc I

Curso sobre Microcontroladores Familia HC9S08 de Freescale

Intérprete entre el Operador y el Ordenador.

Anexo B. Comunicaciones entre mc y PC

ORGANIZAR LA INFORMACIÓN: EL EXPLORADOR DE WINDOWS

Creación de Funciones de Conducción

Presentaciones. Con el estudio de esta Unidad pretendemos alcanzar los siguientes objetivos:

Capítulo V. Implementación

TABLA DE DECISION. Consideremos la siguiente tabla, expresada en forma genérica, como ejemplo y establezcamos la manera en que debe leerse.

5.4. Manual de usuario

Elementos requeridos para crearlos (ejemplo: el compilador)

UNIDADES DE ALMACENAMIENTO DE DATOS

Contenido. cursos.cl / Teléfono:

COPIAS DE SEGURIDAD AUTOMÁTICAS DE DIRECCIONES CALLEÇPAÑA

Tema 1 Introducción. Arquitectura básica y Sistemas Operativos. Fundamentos de Informática

Centro de Capacitación en Informática

Actividad 4: Comunicación entre PLC s vía Ethernet

Introducción a los sitios de SharePoint en Office 365

Estructuras de Sistemas Operativos

Guía rápida de CX-Programmer

Manual Oficina Web de Clubes (FBM)

GENERACIÓN DE ANTICIPOS DE CRÉDITO

Internet Information Server

GESTIÓN DOCUMENTAL PARA EL SISTEMA DE CALIDAD

GUÍA BÁSICA DE USO DEL SISTEMA RED

Entidad Formadora: Plan Local De Formación Convocatoria 2010

INTRODUCCION A LA PROGRAMACION DE PLC

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar

TEMA: PROTOCOLOS TCP/IP

1 La Resolución de Problemas utilizando la Computadora

Capitulo 3. Desarrollo del Software

5. Diseño e Implementación del sistema (software)

Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL

Accede a su DISCO Virtual del mismo modo como lo Hace a su disco duro, a través de:

Capítulo Comunicaciones de datos 1. Conexión de dos unidades 2. Conectando la unidad con una computadora personal

MANUAL DE USUARIO DE LA APLICACIÓN DE ACREDITACION DE ACTIVIDADES DE FORMACION CONTINUADA. Perfil Entidad Proveedora

WINDOWS : TERMINAL SERVER

Sesión No. 4. Contextualización INFORMÁTICA 1. Nombre: Procesador de Texto

MANUAL DE LA APLICACIÓN HELP DESK

Manual CMS Mobincube

4. Programación Paralela

MANUAL DE USUARIO SISTEMA DE ALMACEN DIF SONORA

SCT Software para la calibración de transductores de fuerza. Versión 3.5. Microtest S.A.

SIIGO Pyme. Templates. Cartilla I

TEMA7. SISTEMAS SECUENCIALES

Sistema de Gestión Portuaria Sistema de Gestión Portuaria Uso General del Sistema

Mantenimiento Limpieza

MANUAL DE AYUDA HERRAMIENTA DE APROVISIONAMIENTO

MANUAL DE AYUDA TAREA PROGRAMADA COPIAS DE SEGURIDAD

28.- Manejo de los Feriados

AUTOMATIZACIÓN - CURSO: Práctica 4: Sistema de Monitorización de tiempo mediante Arduino

Gestión de la Configuración

Capitulo V Administración de memoria

LiLa Portal Guía para profesores

TPVFÁCIL. Caja Real. Definiciones.

MANUAL DE USUARIOS DEL SISTEMA MESA DE SOPORTE PARA SOLICITAR SERVICIOS A GERENCIA DE INFORMATICA

SPI. Teoría y Aplicaciones. INGENIERIA EN MICROCONTROLADORES Protocolo SPI( Serial Peripherical Interface) Protocolo

SUB_ESTADOS DE CHEQUES DE TERCEROS

SUB_ESTADOS DE CHEQUES DE TERCEROS

10 razones para cambiarse a un conmutador IP

CATÁLOGO CATÁLOGO CATÁLOGO CATÁLOGO CATÁLOGO

COMO CONFIGURAR UNA MAQUINA VIRTUAL EN VIRTUALBOX PARA ELASTIX

La ventana de Microsoft Excel

SISTEMA ETAP en línea Estándares Tecnológicos para la Administración Pública

Guía de uso del sistema CV-Online

Acronis License Server. Guía del usuario

PANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet. Revisión 1.1 Fecha

El programa Minitab: breve introducción a su funcionamiento. Para mostrar la facilidad con la que se pueden realizar los gráficos y cálculos

Apéndice 5 Manual de usuario de ColeXión. ColeXión 1.0. Manual de usuario

Transcripción:

DISEÑO LÓGICO II 2002 Proyecto II2C - Controlador de Motores mediante bus I2C Autor: (alegus@adinet.com.uy)

Indice INDICE...2 OBJETIVOS:...4 DESCRIPCIÓN:...4 ARQUITECTURA DEL SISTEMA:...7 Sistema con comunicación mediante interfaz paralela:...7 Sistema con comunicación mediante interfaz del bus I2C:...9 Bus I2C...10 COMUNICACIÓN CON EL CONTROLADOR DE MOTORES:...12 COMPONENTES:...13 Cola.vhd...14 DivisorReloj.vhd...15 MoverMPaP.vhd...16 InterfazI2C.vhd...17 Motor.vhd...19 ControladorMotorX.vhd...20 PatternX.vhd...22 Pattern0.vhd...23 Pattern1.vhd...23 Pattern2.vhd...24 Pattern3.vhd...24 Pattern4.vhd...24 Pattern5.vhd...25 PatternNull.vhd...25 ProyectoI2C.vhd...25 InterpreteDeComandos.vhd...26 TESTEO DEL SISTEMA:...27 Software de Testeo...28 Componentes VHDL para el testeo...31 CONCLUSIONES:...33 BIBLIOGRAFÍA:...34 ANEXO:...35 Cola.vhd...35 DivisorReloj.vhd...38 MoverMPaP.vhd...40 InterfazI2C.vhd...42 Motor.vhd...52 ControladorMotorX.vhd...58 Pattern0.vhd...64 Pattern1.vhd...67 Pattern2.vhd...71 Pattern3.vhd...75 Pattern4.vhd...79 2

Pattern5.vhd...83 PatternNull.vhd...88 InterpreteDeComandos.vhd...89 3

Objetivos: El proyecto tiene como objetivo final controlar una cantidad parametrizable de motores paso a paso (MPAP) de dos maneras distintas: mediante una interfaz paralela (tipo LPT) y mediante una interfaz con el bus I2C. El modelado se realizó en VHDL-87 modular y estándar, de tal manera que los distintos componentes del proyecto puedan ser reusados independientemente. Dado que se deseaba obtener componentes reusables, no se utilizo ninguna característica especial de la arquitectura de los FPGAs de Altera (LPMs, EABs, etc). Los motores paso a paso a utilizar son los utilizados en disketeras y discos duros, y son de excitación en 2 bobinas. Para el testeo del sistema, se desarrollo un software para PC que envía los comandos al controlador mediante el puerto paralelo. Para el testeo del sistema mediante la interfaz del bus I2C, el software emula la funcionalidad básica de un dispositivo I2C maestro. Descripción: La idea del proyecto es poder controlar a la vez un cierto número de motores, indicándoles a cada uno de ellos las órdenes que deberán seguir. Estos motores deberán ejecutar los patrones de movimientos que el usuario les indique a cada motor en forma paralela e independientemente. Los tipos de patrón que se podrán indicar a cada motor pueden ser muy variados, desde un simple movimiento en una sola dirección a movimientos más elaborados. Cada motor deberá tener asociada una cola de estos patrones de tal manera que el usuario del sistema pueda dejar allí encoladas distintas tareas para que el motor las ejecute secuencialmente. Los motores son del tipo de excitación de 2 bobinas, de 200 pasos. Es decir que se necesitan 200 pasos en una dirección para dar una vuelta completa. Cada motor tiene como entrada físicamente 4 lineas, y la combinación de valores en esas lineas hace que el motor gire en un sentido o en otro. De las 16 combinaciones posibles de entrada sólo 4 son válidas, por lo que se pueden definir 4 estados en cada motor. Para mover el motor en sentido horario se debe pasar de un estado al siguiente; y para moverlo en sentido antihorario se debe pasar al estado anterior. Las siguiente tabla muestra los valores de entrada posibles de cada motor: Paso Linea 1 Linea 2 Linea 3 Linea 4 1 1 0 0 0 2 0 1 0 0 3 0 0 1 0 4 0 0 0 1 Para este proyecto, uno de los requerimientos era el de codificarar estos cuatro estados en 2 líneas de salida, ya que luego externamente un decodificador iba 4

a realizar la operación inversa (decodificar) antes de conectar las líneas con el motor. El siguiente es un esquemático del: 12V MOTOR PAP L1 L2 L3 L4 S3 SALIDA_MOTOR[1] S2 ULN2003_d SALIDA_MOTOR[2] DECODIFICADOR S1 ULN2003_c S0 ULN2003_b ULN2003_a Los tipos de órdenes que el controlador de motores puede recibir se distinguen en 2 grupos. Por un lado están las ordenes que seleccionan uno de los N motores con los cuales se desea trabajar, y que seleccionan la velocidad con que los motores van a funcionar. Además están las órdenes dirigidas especialmente al motor seleccionado, es decir, las órdenes que le indican qué es lo que debe hacer cada motor. Los motores serán controlados indicándoles distintos patrones que deberán seguir. Cada motor tendrá asociada una cola de patrones, de tal manera que el controlador de motores le pueda dejar encoladas una serie de patrones y el motor los ira ejecutando uno atrás del otro hasta que la cola quede vacía. Los patrones pueden ser de tipo y complejidad variable. Por ejemplo, un patrón podría ser mover el motor N pasos en sentido S, o dejar el motor quieto N pasos y luego moverlo M pasos en sentido S. Estos patrones serán parametrizables, donde se les indicara el sentido inicial (S), la amplitud (P) y la cantidad de iteraciones (M). Los patrones son del tipo pluggable, es decir que se puede tener una biblioteca de patrones y luego para una aplicación específica se pueden instanciar en un Motor solo los patrones que se desean. Para ello es importante que todos los patrones modelen una interfaz bien definida de entrada/salida que contemple los 3 tipos de parámetros con que esta definido 5

un patrón. Como ejemplo, para este proyecto se implementaron 6 patrones distintos que se detallaran más adelante. La comunicación desde el exterior con el Controlador de Motores se puede realizar de dos maneras. Una de ellas utiliza la cantidad de líneas de entrada/salida provistas por un puerto paralelo (LPT) estándar de PC, y la otra lo hace mediante la utilización de una interfaz con el bus I2C. Varios de los componentes del proyecto fueron modelados para ser reutilizables por separado, con interfaces genéricas pero bien definidas que se detallarán más adelante. Para mantener la portabilidad de los distintos componentes éstos fueron implementados íntegramente en VHDL-87 estándar, se generó un package VHDL para facilitad la importación/instanciación. Además, cada módulo viene acompañado de una pequeña descripción de su interfaz y notas relacionadas. 6

Arquitectura del Sistema: A continuación de detallan la configuración del Sistema tanto para comunicación desde el exterior vía la interfaz paralela, como la interfaz del bus I2C. Sistema con comunicación mediante interfaz paralela: 7

El Controlador de Motores es el corazón del Sistema. Recibe los comandos que los motores deben ejecutar, setea la velocidad de los mismos, etc. La interfaz del Controlador es del tipo paralela con 8 bits de datos y 3 bits de control. La salida del Sistema son 2 bits por Motor, con la codificación del estado de los motores paso a paso asociados a cada motor. Adicionalmente, el Sistema tiene como salida el estado de la cola del Motor actualmente seleccionado. El formato de estas entrada y salidas se describen en el informe más adelante. El controlador esta formado internamente por una lógica que conecta los distintos motores y de acuerdo a los comandos recibidos desde el exterior, selecciona el motor con el cual trabajar, setea las velocidades de cada motor (que son independientes entre sí), y encola los patrones que cada Motor debe ejecutar. Por su parte, cada Motor esta compuesto por una Cola circular que contiene los patrones que dicho motor deberá ejecutar; un pequeño módulo que lleva el estado de las bobinas del motor paso a paso asociado al motor; y la lista de patrones de que dispone dicho motor (esta lista también es reconfigurable, mediante la instanciación de los diferentes módulos de patrón disponibles). La cantidad de Motores que forman parte del Controlador de Motores, así como los patrones que conforman cada Motor son parámetros del Sistema. 8

Sistema con comunicación mediante interfaz del bus I2C: El Sistema completo con comunicación vía el Bus I2C es una extensión al Sistema basado en comunicación paralela. Un módulo general (Intérprete de Comandos) contiene al Controlador de Motores y al módulo Interfaz I2C, que es la encargada de obtener los comandos a través del bus I2C. La diferencia con el Controlador de motores via puerto paralelo es que los datos se reciben en forma serial mediante la utilización de un bus I2C. Es decir 9

que como entradas al sistema tenemos los dos bits del bus (SDA, SCL), y como salidas, además de los 2 bits de salida por cada motor, y del bit de estado se tiene la salida del SDA, SCL, y OutputEnable del esclavo, que se desbriben más adelante en este informe. El módulo principal, es decir el Intérprete de Comandos, simplemente realiza la interconexión y transfiere los datos recibidos en forma serial por el bus I2C a la entrada paralela del Controlador de Motores. Bus I2C El bus I2C es un bus serial simple de 2 líneas bidireccionales, una de reloj (SCL) y otra de datos (SDA). En este proyecto en vez de utilizar 2 lineas bidireccionales, se utilizaron un par de líneas de entrada (SDA, SCL) y un par de lineas de salida (SDAOut y SCLOut), y adicionalmente una salida OutputEnable que indica cuando se tiene el control sobre las líneas de salida. Cada dispositivo conectado a él (que puede ser maestro o esclavo) se identifica unívocamente mediante un identificador de 7 bits. La comunicación siempre debe comenzarla un maestro, que inicialmente envía un paquete de 8 bits con el identificador del esclavo a comunicarse y la dirección del flujo de la comunicación (del maestro al esclavo o del esclavo al maestro). El estándar define un protocolo de arbitraje por el cual varios maestros pueden estar conectados al bus sin que los mensajes enviados se corrompan. La comunicación se realiza mediante paquetes de 8 bits, y el comienzo / fin de la transmisión se detecta mediante combinaciones especiales en las señales SCL y SDA, como se muestra en la siguiente figura: Mientras se están enviando datos por el bus, sólo está permitido cambiar el valor de la línea de datos (SDA) cuando la línea de clock (SCL) esta baja. Como se ha explicado anteriormente, la comunicación se realiza de a bytes, aunque existe un noveno bit para indicar la aceptación o no aceptación de dicho byte. Cada vez que un byte es transferido por el bus (mediante 8 flancos de bajada de la señal SCL) la contraparte en la comunicación debe enviar un bit de ACK. Para esto el maestro deja levantado la línea SDA durante un periodo de reloj, y el receptor debe bajar dicha línea. En caso de no querer dar un ACK, el receptor deberá dejar levantada dicha línea con lo cual se indica que no se acepto el byte (nack). 10

En caso de que se de un ACK, el maestro deberá enviar una condición de Stop (o de restart). Para terminar la comunicación, el maestro debe enviar una condición de STOP luego de haber recibido (o enviado) el último ACK/nACK. Por más información respecto al bus I2C y el protocolo que se debe implementar, referirse a la bibliografía. Para este proyecto se implemento un módulo esclavo del bus I2C tanto receptor (envío datos del maestro al esclavo) como transmisor (envío de datos del esclavo al maestro). Esto permite poder reutilizar el módulo para proyectos posteriores. 11

Comunicación con el Controlador de Motores: Como se ha explicado anteriormente, para este proyecto se deseaba que la comunicación con el Controlador se pudiera realizar utilizando solo las entradas/salidas estándar de un puerto paralelo de PC. En el modo normal de funcionamiento de un puerto paralelo de PC se tienen disponibles 8 líneas de salida (D0...D7), 4 líneas de entrada/salida (nstrobe, nauto, ninitialize y nselectprinter) y 5 líneas de entrada (nack, Busy, PO, Select y nerror). A su vez cada comando debía constar de 4 partes: Identificador comando Sentido inicial: izquierda - derecha Cantidad de Pasos: de 1 a 256 Cantidad de Iteraciones: de 1 a 256 Por lo que fue necesario partir cada comando en 3 subpartes. Se decidió utilizar 8 líneas de entrada para cada subparte, y 3 líneas más para líneas de control. Las líneas de control sirven para no perder la sincronización desde el exterior, pues dada la naturaleza de la comunicación era factible que se perdiera una subparte en la comunicación. A continuación se detalla una tabla con los distintos comandos y sus subpartes. Descripción del Byte A Byte B Byte C Comando Seleccionar un motor 00000000 Número de --- motor Setea la velocidad del motor seleccionado 00000001 Velocidad --- Encolar un pattern al 100SYYYY Cantidad de Cantidad de motor seleccionado (S=Sentido) Pasos Iteraciones (YYYY=Pattern) El Controlador de Motores además de las salidas que se conectan a cada motor paso a paso para hacerlo mover, tiene una línea que indica si el motor actualmente seleccionado tiene su cola de patrones llena. 12

Componentes: A continuación se describiran los distintos componentes implementados, sus interfaces, algunos testeos y estadísticas realizadas y sus posibles aplicaciones. Para la implementación de los distintos módulos se emplearon algunas condiciones generales de diseño: Todos los módulos tienen una línea de reset asíncrono, activa en 1. En todas las señales en las que se detecta un flanco, éste es de bajada. Se priorizó la portabilidad. Esto es importante pues no se utilizaron todas las características del VHDL-87 estándar porque el compilador de Altera no las soportaba. Además, algunas construcciones no son compiladas por el compilador de Altera, si bien otros compiladores (como el Synplify) las compilan correctamente. El zip que contiene los fuentes VHDL del proyecto también se van a encontrar varios módulos cuyo nombre termina con Tiny. La distinción para esos módulos es que están recortados de tal manera que puedan entrar en las celdas disponibles del chip FLEX10K240RC disponibles en las placas UP1 de Altera. Por ejemplo, para el módulo MotorTiny solo se tienen disponibles 3 patrones diferentes. La cantidad de líneas de cada entrada/salida (ancho de palabra) es de un bit a menos que se especifique lo contrario en la descripción de la interfaz 13

Cola.vhd Descripción: Este componente reusable implementa una cola circular de ancho de palabra parametrizable (vía generics). Para esta implementación NO se utilizaron punteros de VHDL porque el compilador de Altera no los soporta. El compilador de Altera también tenía problemas con la indexación de la palabra por medio de una variable, por lo cual se decidió simplificar el modelo ajustándolo a una cantidad fija de elementos, pero que es fácilmente modificable para distintos valores. Este componente puede ser utilizado en una gran variedad de aplicaciones, en las cuales se desea tener un buffer ordenado de datos de entrada. El este proyecto cada Cola forma parte del módulo Motor, y es la que le provee los datos sobre los patrones que el Motor deberá ejecutar. Interfaz: Entradas: -> reset : linea de reset -> enqueue: encolar un item -> dequeue: desencolar un item -> datain : item a encolar (cantidad de bits parametrizable) Salidas: -> dataout: ultimo item desencolado (cantidad de bits parametrizable) -> empty : indica si la cola esta vacia -> full : indica si la cola esta llena Funcionamiento: Cada vez que se desea encolar un item a la cola se debe colocar los datos en las líneas de entrada DataIn y se debe dar un flanco en la línea enqueue. Cada vez que se desee desencolar un item de la cola se debe dar un flanco en la línea dequeue. El dato estará disponible en las líneas de salida DataOut Las líneas Empty y Full se ponen a 1 cuando la cola está vacía o llena respectivamente 14

DivisorReloj.vhd Descripción: Este componente toma como entrada una señal de reloj y deja como salida una señal de reloj de frecuencia menor (de acuerdo a un divisor parametrizable). El rango posible del divisor es una propiedad parametrizable del componente (mediante generics), mientras que el valor real del divisor a utilizar puede ser seteado en cualquier momento mediante la utilización de las entradas provistas para ello. En este proyecto hay un modulo DivisorReloj instanciado por cada Motor que tenga el ControladorDeMotores. De esta manera cada motor Paso a Paso puede tener su propia velocidad. Interfaz: Entradas: -> clkin: el reloj a dividir -> reset: linea de reset -> setdivisor: setea el divisor (sincronizado con el falling_edge) -> setup: setea el divisor (cantidad de bits parametrizable) Salidas: -> clkout: el reloj dividido Funcionamiento La línea de entrada clkin debe ser conectada con el reloj que se desea dividir. La salida clkout contendrá la señal de reloj luego de ser dividida su frecuencia Cuando se desee setear un nuevo divisor, se debe colocar en las líneas de datos setup el nuevo valor del divisor y se debe dar un flanco a la línea setdivisor 15

MoverMPaP.vhd Descripción: Este componente es el encargado de mover el motor paso a paso. Para este proyecto se estableció que la salida de los motores debían ser 2 bits codificado que indican el estado del motor En este proyecto cada Motor tiene asociado un modulo de estos para llevar el estado del motor paso a paso asociado. Interfaz: Entradas: -> reset : linea de reset -> clk : entrada del reloj -> mover : indica si se debe mover el motor -> reverse: indica si el motor se debe mover hacia atrás Salidas: -> salida : los 2 bits de salida Funcionamiento: Cuando se desee mover el motor un paso a la derecha, se debe mantener levantada la línea mover mientras la entrada clk da un flanco Cuando se desee mover el motor un paso a la izquierda, se debe levantar la línea de entrada reverse y luego se debe mantener levantada la línea mover mientras la entrada clk da un flanco 16

InterfazI2C.vhd Descripción: Este componente reusable implementa la interfaz del bus I2C de un dispositivo esclavo tanto receptor como transmisor. Una breve descripción de las características del bus I2C pueden encontrarse en este informe. Si bien para este proyecto en particular solo se necesitaba modelar un esclavo receptor (pues solo se desea recibir comandos), se modelo también la parte transmisora para poder reutilizar este componente en otros proyectos. De la especificación del la interfaz con el bus I2C no se tuvo en consideración el tipo de comunicación to-all-devices porque escapa al alcance de este proyecto. Como se ha explicado anteriormente el bus I2C es un bus de dos líneas bidireccionales (SDA y SCL) ; pero en este proyecto se utilizaron dos pares de líneas SDA y SCL (una de entrada y otra de salída) y una línea de Output Enable para indicar si se está utilizando las líneas de salida (es decir, si el esclavo tiene el control de la línea de datos); por lo que pueden multiplexarse fácilmente en 2 líneas bidireccionales utilizando buffers triestado. En este proyecto este módulo es utilizado para obtener la comunicación con el exterior; y forma parte del módulo InterpreteDeComandos, que realiza el puente entre los datos recibidos por la InterfazI2C con el Controlador De Motores. Interfaz: Entradas: -> clk : entrada de reloj -> reset : linea de reset -> SCL : linea de clock del bus I2C -> SDA : linea de datos del bus I2C -> ReadyToRead: indica si puedo aceptar un byte del bus cuando soy slave-receiver -> ReadyToWrite: indica si debo aceptar una peticion del bus de que yo sea slave-transmitter -> ByteIn : próximo byte a enviar al bus si soy slave-transmitter (8 bits) Salidas: -> OutputEnable: indica si este slave tiene el control de la linea de datos (SDAOut) -> SCLOut : igual a SCL -> SDAOut : Linea de datos en caso de ACK/NACK en caso de ser slave-receiver o línea de datos si soy slave-transmitter -> ByteReady : Da un pulso cunado se obtuvo un byte del bus si soy slave-receiver -> ByteOut : El byte leido del bus (8 bits) 17

Funcionamiento: -> Transferring : Indica si se esta llevando a cabo una transferencia desde/hacia el bus -> TransferringWrite: Indica si la transferencia es de escritura (slave-transmitter) o de lectura(slave-receiver), se mantiene bajo mientras se obtiene el ACK del master en un slave-transmitter Inicialmente el II2C esperará una condición de START en la líneas SCL y SDA. A partir de ese momento irá latcheando los próximos 8 bits de entrada. Luego de obtener el octavo bit, el II2C chequeará los primeros 7 bits con su identificador. El bit menos significativo indicará si es una petición de transferencia desde o hacia el master. El II2C aceptará peticiones de transferencia de bytes desde el master al II2C (slave-receiver) si la entrada ReadyToRead está activa. En ese caso enviará un ACK al master. En caso contrario enviará un nack al master y esperará una nueva condición de START. Mientras que el II2C está recibiendo los 8 bits de cada byte de transferencia, se levantara la salida Transferring y se mantendrá baja la línea TransferringWrite, para indicar una transferencia desde el master. Cuando el II2C recibe un byte completo, lo coloca en ByteOut, baja la línea Transferring y levanta la línea ByteReady. En ese momento el II2C envía un ACK al bus si la línea ReadyToRead esta levantada, o un NACK en caso contrario. El II2C seguirá recibiendo bytes mientras que se acepten los bytes recibidos hasta que una condición STOP sea detectada. El II2C aceptará peticiones de transferencia de bytes hacia el master (slave-transmitter) si la entrada ReadyToWrite está activa. En ese momento el II2C latcheará el byte contenido en ByteIn, y enviará el ACK al master. En caso de que la línea de entrada ReadyToWrite este baja, se enviará un NACK para indicar que no se acepta la petición de transferencia. Si la petición de transferencia fue aceptada, se levantarán las líneas TransferringWrite y Transferring para indicar una transferencia hacia al master y se enviará el byte. Luego de enviado el byte, el II2C espera el ACK del master. El II2C seguirá enviando bytes hasta que detecte un NACK del master (luego del cual vendrá una condición de STOP). 18

Motor.vhd Descripción: Este componente reusable implementa el manejo de un motor mediante una cola de patrones que debe ir ejecutando. El componente tiene asociado una cola circular de patrones y mientras que ésta no esté vacía, los irá ejecutando secuencialmente. Cada patrón a ser encolado constara de una palabra de 21 bits con el siguiente formato: STTTTPPPPPPPPIIIIIIII, donde: S indica el sentido inicial del patrón TTTT indica el número de patrón a encolar (de 0 a 15) PPPPPPPP indica la cantidad de pasos por iteración (de 0 a 255) IIIIIIII indica la cantidad de iteraciones (de 0 a 255) El usuario podrá dejar encolados varios patrones y el módulo los irá ejecutando uno después del otro, de esta manera es posible colocar varios de estos módulos para que realicen los movimientos de distintos motores forma paralela. El motor indicará cuándo tiene su cola de patrones llena. En este proyecto se instancia un Motor por cada motor real del sistema. Cada Motor forma parte del ControladorDeMotores que es quién redirige los comandos a la cola de cada uno de los Motores para que ellos ejecuten los patrones que allí se encolan. Interfaz: Entradas: -> clk: el clk que da la velocidad de pulso del motor -> reset : linea de reset -> addpattern : Genera un pulso cuando hay un nuevo pattern -> pattern: los 21 bits que conforman el pattern (21 bits) Salidas: -> patternqueuefull: indica si la cola de patterns del motor seleccionado esta llena -> salidamotor: indica el estado del MpaP (2 bits) Funcionamiento: Cada vez que se desee encolar un elemento en la cola de patrones asociada al motor, se debe colocar los datos del patrón (según el formato especificado) en las líneas de entrada pattern, y se debe dar un flanco a la línea addpattern. El motor cuando detecte que la cola no está vacía comenzará a ejecutar el primer patrón disponible en la cola. La velocidad con que se ejecutará el patrón dependerá de la frecuencia de la entrada de reloj proporcionada. Cuando la cola de patrones esté llena, el motor levantará la línea de salida patternqueuefull para indicar que no aceptará más patrones hasta no terminar de ejecutar el patrón actual. 19

ControladorMotorX.vhd Descripción: Este es el componente encargado de controlar varios motores paso a paso. Por problemas de compatibilidad con el compilador VHDL de Altera, hay 2 versiones. Una de ellas (ControladorMotorUno.vhd) tiene la lógica simplificada para controlar un solo motor. El problema fue que el compilador de Altera tiene problemas para compilar construcciones for...loop que accedan a un componente instanciado en un generate. Más precisamente, el compilador de Altera no va a compilar un código de este estilo: for i in 0 to CantMotores-1 loop XXX(i)... end loop La otra versión (ControladorMotorN.vhd) contiene N motores, donde N es un generic, por lo que puede ser modificada la cantidad de motores en al instanciar el componente. Este módulo es el punto de entrada para sistemas con comunicación mediante interfaz paralela (LPT) La función de este componente ya fue descripta anteriormente. Su función es la de obtener las subpartes que conforman un comando desde el exterior y asignárselos al motor asociado. También debe llevar control de qué subparte se espera en este momento, para no perder la sincronización. Otra de sus funciones es la de seleccionar el motor actual con el que se desea trabajar y asignarle una velocidad a dicho motor. Interfaz: Entradas: -> clk : el reloj base de los motores -> reset : linea de reset -> newmsg : Genera un pulso cuando hay datos disponibles -> ctrl : bits de control (3 bits) -> cmdarg : bits de argumentos (8 bits) Salidas: -> patternqueuefull: indica si la cola de comandos del motor seleccionado esta llena -> Salida_Motor: 2 bits de salida para cada motor (2 x CantMotores bits) Funcionamiento: Cada vez que desde el exterior se desee enviar un comando al controlador de motores, se deben dejar los datos de la primer subparte 20

del comando en cmdarg, dejar el valor 0 en ctrl y dar un flanco en la línea newmsg. El Controlador de Motores guardara el estado actual del comando y esperara a recibir la segunda subparte sólo si el valor recibido en ctrl es 0. Ahora desde el exterior se deberá enviar esta parte de la misma manera que envió la primer subparte, para lo cual en vez de dejar 0 como valor en ctrl se deberá dejar el valor 1. El Controlador de Motores chequeará el valor de ctrl y en caso de que no sea 1, volverá a esperar la primer subparte. Por último se debe enviar la tercer subparte exactamente de la misma manera en que se enviaron las dos primeras, sólo que esta vez el valor en ctrl debe ser 2. El Controlador de Motores, chequeará el valor de ctrl para ver si su valor es 2. En ese caso, chequeará la validez del comando y lo ejecutara, asignando un nuevo motor, seleccionando su velocidad, o encolando el nuevo patrón a ejecutar en la cola del motor seleccionado Las salidas de cada motor son multiplexadas en el array de bits Salida_Motor, donde los primeros 2 bits indican el estado del motor paso a paso asociado al Motor 0, los siguientes 2 bits indican el estado del motor paso a paso asociado al Motor 1, y así sucesivamente La línea de salida patternqueuefull indica si la cola de patrones del motor seleccionado está llena. 21

PatternX.vhd Descripción: Bajo este subtitulo se engloban todos los patrones implementados en este proyecto. Todos ellos tienen la misma interfaz, lo que los hace pluggables, intercambiables, etc. Cuando se desea agregar un nuevo patrón a la lista de patrones disponibles para un motor, simplemente se debe agregar una línea en el bloque de instanciación del módulo Motor.vhd y se debe cambiar el valor de la constante que define la cantidad de patrones que el motor tiene. Para más detalles se puede ver el código VHDL del módulo Motor.vhd, donde se detalla los puntos donde se debe realizar los cambios. A continuación se detalla la interfaz que se aconseja que todos los patrones sigan y su funcionamiento general. Luego se detallara el funcionamiento particular de todos los patrones implementados en este proyecto. Para todos los patrones se toma como convención que N es la cantidad de pasos, M es la cantidad de iteraciones, y S es el sentido inicial. Interfaz: Entradas: -> clk : el clk que da la velocidad de pulso del motor -> startpattern : Genera un pulso cuando hay un nuevo pattern -> reset : linea de reset -> iteraciones: cantidad de iteraciones (8 bits) -> pasos: cantidad de pasos por iteración (8 bits) -> sentidoinicial: sentido inicial del pattern Salidas: -> done: indica si el pattern ha terminado -> mover: indica que el motor debe ' moverse' -> sentido: indica el sentido del movimiento Funcionamiento: A continuación de da la descripción general del funcionamiento de los patrones (el funcionamiento particular de cada patrón podría diferir si algunos de los parámetros no es aplicable para cierto patrón) : Cada vez que se desee comenzar a ejecutar el patrón, se deberán dejar en las líneas de entrada pasos, iteraciones y sentidoinicial, la cantidad de pasos, iteraciones y el sentido inicial que se desea que el patrón siga. Una vez que los datos estén disponibles allí, se deberá dar un flanco en la línea de entrada startpattern, que dará el toque inicial para que el patrón sea ejecutado. La velocidad con que el patrón será ejecutado dependerá de la línea de reloj de entrada clk. Mientras que el patrón se esta ejecutando, cada vez que quiera mover el motor paso a paso, deberá levantar la línea de salida Mover durante un ciclo de reloj. Para determinar el sentido del movimiento, se deberá 22

mantener levantado o bajo la línea de salida sentido durante ese ciclo de reloj. En general, estas salidas se deberán interconectar con el módulo MoverMPaP para que realmente se mueva el estado del motor paso a paso asociado. Mientras que el patrón se esté ejecutando, la línea de salida done se debe mantener a 0. Una vez que el patrón se haya terminado de ejecutar, la línea deberá volver a 1 para indicar que el patrón se ha terminado de ejecutar.. Mediante este sistema, cada módulo Patrón puede hacer que el motor asociado realice tanto movimientos simples como complejos. Como cada Motor tiene una cola de patrones asociada, estos patrones pueden combinarse para realizar movimientos aún más complejos, ya que el motor los irá ejecutando secuencialmente (uno por vez). Adicionalmente, como cada Motor ejecuta sus patrones independientemente de los otros (la ejecución se realiza en forma paralela), esto permite realizar distintas coreografías con los motores asociados al Sistema. A continuación se describen los patrones implementados como ejemplo para este proyecto: Pattern0.vhd Descripción: El patrón de tipo 0 no mueve el motor, sino que hace una espera de M x N pasos. Su utilidad es la de hacer una pausa, por ejemplo en el medio de una secuencia de patrones encolados en un motor. Funcionamiento: Luego de iniciado el patrón se hace una espera de M x N pasos sin mover el motor en ningún sentido. Pattern1.vhd Descripción: El patrón de tipo 1 realiza un movimiento de vaivén. Funcionamiento: Se comienza el patrón en el sentido indicado por S, donde se mueven N pasos. Luego se invierte el sentido y se realizan otros N pasos; y así sucesivamente hasta haber realizado M iteraciones 23