Você está na página 1de 167

Captulo 1

INTRODUCCIN

1 INTRODUCCIN
El presente proyecto trata sobre el desarrollo de un robot mvil llamado Hermes, creado en la Escuela Superior de Ingenieros industriales de San Sebastin (TECNUN), en el laboratorio de Robtica del departamento de automtica, que tendr capacidad de navegacin autnoma y de interactuar con las personas.

Se ha diseado el robot Hermes con una arquitectura de control distribuida en tiempo real. Para ello dispone de tres tarjetas de adquisicin de datos y una tarjeta de acondicionamiento de seal para los drivers de los motores, comunicadas con un PC maestro a travs del bus USB, creando un sistema modular.

El PC maestro es el encargado de albergar el algoritmo de control del movimiento del robot, para lo cual gestiona las tarjetas esclavas. Todas estas tarjetas estn gobernadas por un microcontrolador PIC18F4550, cuyo cometido principal es atender a las peticiones del PC maestro. Se han diseado las tarjetas para que cada una tenga una funcin especfica. Estas tarjetas se pueden clasificar en dos grupos atendiendo a su funcin especfica.

El primer grupo tiene como funcin la adquisicin de datos de las distancias y lo componen tres tarjetas. Cada tarjeta hace uso de un tipo de sensor de distancias diferente para cumplir su cometido, siendo stos los sensores de infrarrojos GP2D12, GP2Y0A02YK y el sensor de ultrasonidos SRF02.

El segundo grupo lo compone una tarjeta que tiene como funcin especfica, el gobierno de los drivers de los motores.

Es un robot con una estructura octogonal a base de aluminio, perfiles metlicos y policarbonato que mantienen todo el peso del robot. El sistema posee tres servomotores, que hacen girar ruedas omniwheels, que son las encargadas de dotar al robot de la funcin de movimiento. Para la adquisicin de informacin del entorno que rodea al robot se tienen 24 sensores de distancia en el exterior de la estructura. Concretamente tiene 8

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

sensores de ultrasonidos, 8 sensores de infrarrojos de corto alcance y 8 sensores de infrarrojos de largo alcance.

Figura 1.1 Robot Hermes

Dispone de dos webcams que servirn para futuros desarrollos del robot y que dotarn a ste de visin a travs de un PC externo va Wifi. Tambin alberga una pantalla tctil para poder interactuar con el robot, una vez sea desarrollada la aplicacin en el PC.

En el proyecto que se ha llevado a cabo, se pueden distinguir dos fases bien diferenciadas. La primera fase se ha denominado fase de hardware, y ha tenido como propsito el anlisis, diseo y fabricacin de la parte de hardware del robot. La parte de hardware la forman las cuatro tarjetas esclavas y las tarjetas de alimentacin y acondicionamiento de seal de los drivers. En una segunda fase, que se ha denominado fase de software, se ha creado un protocolo de comunicacin USB para poder conectar las diferentes tarjetas esclavas al ordenador maestro, y que pueda servir de banco de pruebas para los alumnos que participen en la asignatura de Control y Programacin de Robots que imparte el Dr. Emilio Jos Snchez Tapia en TECNUN.

Captulo 1

INTRODUCCIN

En la primera fase de hardware, se ha diseado y construido la circuitera que conforma el hardware electrnico del robot. Las tarjetas han sido provistas con la electrnica necesaria para la comunicacin USB y la circuitera para llevar a cabo su finalidad especfica. Las tarjetas se han construido utilizando los mtodos de insolacin, mecanizado y soldadura de componentes.

En la fase de software se ha creado un protocolo de comunicacin por USB entre el PC maestro y las tarjetas esclavas. Se han programado las tarjetas esclavas de adquisicin de datos para estar en contacto con el PC maestro va USB y a su vez ejecutar su funcin de adquirir la informacin de las distancias a travs de los sensores. La tarjeta de gobierno de motores no ha sido programada, quedndose como futuro desarrollo abiertamente asequible, gracias a los conocimientos adquiridos en el presente proyecto.

Para realizar la fase de software, se ha programado en cada microcontrolador un firmware, que maneja el protocolo USB. Es un algoritmo que ofrece el fabricante, para desarrollar perifricos con comunicacin USB. Hay diferentes tipos y clases de firmware, cada uno con sus caractersticas y forma de trabajo. En el presente proyecto se ha implementado la clase USB CDC (Communications Device Class) en los esclavos, lo que permite al PC maestro detectar estos perifricos, como si fuesen dispositivos puertos serie RS232 virtuales. De esta manera cualquier aplicacin que controle el bus serie puede llegar a comunicarse con las diferentes tarjetas esclavas.

Para concretar la fase de software, se ha creado una aplicacin en Visual Basic que comunica el ordenador con las tarjetas de adquisicin de datos. De esta manera se ha creado un ejemplo de las posibilidades de control de las tarjetas esclavas. sta aplicacin ha sido utilizada a su vez, como herramienta de testeo en la fase de programacin y depuracin del cdigo.

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

2 PLANTEAMIENTO DEL PROBLEMA


Se dice que hay fijarse objetivos y no detenerse hasta cumplirlos, de este modo uno deja de ser un mero espectador de la vida y se convierte en un protagonista. En el presente captulo se presentan los objetivos fundamentales del proyecto, as como una descripcin global de los factores que motivaron la realizacin de este proyecto.

2.1

OBJETIVOS

Como objetivo general de este proyecto, se ha planteado la creacin de un protocolo de comunicacin USB que dote al robot Hermes de una arquitectura de control distribuida en tiempo real.

A partir del objetivo principal, se desprenden otros objetivos no menos importantes que se describen a continuacin:

Realizacin del estado del arte correspondiente a los dispositivos perifricos comunicados con el ordenador a travs del bus USB.

Diseo del hardware y fabricacin de las tarjetas esclavas.

Desarrollo de los dispositivos USB con microcontroladores PIC, con el compilador C18 en MPLAB.

Redactar un informe final que sirva de base para futuros desarrollos de sistemas, que dispongan de dicho protocolo y que estn basados en los microcontroladores PIC.

Captulo 2

PLANTEAMIENTO DEL PROBLEMA

2.2

DEFINICIN DEL PROBLEMA

En la arquitectura diseada en el robot Hermes, el PC maestro es el encargado de albergar el algoritmo de control del robot, para lo cual hace uso de cuatro tarjetas esclavas. Tres de las tarjetas esclavas tienen como funcin, la adquisicin de la informacin de las distancias a los obstculos que rodean al robot, mientras que la cuarta tarjeta esclava controla los drivers de los motores.

Con este proceder, el robot est basado en mdulos o funciones, lo que otorga al sistema de una mayor capacidad de procesamiento. El PC con este sistema, est liberado de las operaciones de adquisicin de datos y gobierno de los drivers, aprovechando toda su capacidad de clculo en albergar un algoritmo de control que utilice dichas funciones.

De esta manera en el proyecto Hermes se ha visto la necesidad de introducir un protocolo de comunicacin entre el PC y las tarjetas. Se podra haber optado por una sencilla comunicacin serie RS-232 o USART, pero se ha optado por una comunicacin USB, ms acorde con los desarrollos actuales.

El bus USB fue creado en 1995 para remplazar la multitud de conectores que disponan los ordenadores, y servir de estndar en las comunicaciones con perifricos. Se puede decir que se logr cumplir el objetivo con creces. En la actualidad dicho protocolo de comunicacin ha relegado a un segundo plano los buses serie, paralelo, PS2, etc. para la conexin de dispositivos externos al ordenador.

Hasta la realizacin del presente proyecto, la escuela no dispona de ningn proyecto realizado con el protocolo USB. De all la necesidad de realizar un proyecto de este tipo, que sirva de base para el dominio de esta tecnologa, que permita el abandono de los antiguos buses serie y paralelo. De esta forma, los futuros proyectos podrn adoptar los conocimientos adquiridos en este proyecto y poder as caminar paralelamente con la tendencia actual.

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

3 EL BUS USB
En este captulo se explican los aspectos ms relevantes de este bus de comunicacin. Se hace una clasificacin de las clases de dispositivos USB haciendo un repaso de sus caractersticas ms importantes.

3.1

INTRODUCCIN

El bus USB Universal Serial Bus es un protocolo serie estndar, que sirve de interfaz de comunicacin entre los perifricos y el PC. Fue diseado a finales de 1995, para permitir anexar dispositivos perifricos al PC, usando un conector nico estandarizado y dotarles de caracterstica Plug & Play 1. Esta caracterstica permite conectar los dispositivos al bus sin necesidad de configurar la comunicacin, siendo el sistema operativo el encargado de esta funcin.

Figura 3.1 Sistema USB

El bus USB tambin dispone de una caracterstica que lo aleja del bus serie tradicional RS-232. Es lo que en castellano se conoce como conexin en caliente o Hotswap, que permite la conexin y desconexin de los dispositivos sin reiniciar el ordenador y sin
1

www.usb.org

Captulo 3

EL BUS USB

quemar el puerto o el dispositivo. Este bus adems tiene la ventaja que permite alimentar a dispositivos con consumos reducidos, sin que estos perifricos tengan que implementar una fuente de alimentacin externa propia.

Una de las caractersticas de este protocolo es que existen diferentes clases de perifricos USB. Cada clase agrupa un tipo de dispositivo USB segn sea su funcin, lo que permite al sistema operativo del PC asignarles el mismo driver para su manejo, eliminando la dependencia de un driver especfico de cada fabricante.

Histricamente el bus USB fue creado para sustituir los puertos serie y paralelos de los PC, permitiendo conectar perifricos de ordenador tales como ratones, teclados, mandos y joysticks, scanners, cmaras digitales, impresoras y memorias. Sin embargo hoy en da se han convertido en el protocolo estndar utilizado en PDAs, video consolas, telfonos mviles y un largo etctera. Segn el USB Implementers Forum (USB-IF) 2, se estima que en el mundo hay cerca de 2 billones de dispositivos USB. El diseo del bus USB est estandarizado por sta organizacin, creando una base y una serie de normas de industria para las principales empresas electrnica y el ordenador. Miembros notables de esta organizacin son Hewlett-Packard, Intel, NEC, Microsoft, Apple, LSI Corporation entre otros.

Las especificaciones USB 1.0 fueron creadas en el mes de noviembre de 1995. Fueron desarrolladas y promovidas por Intel, Microsoft, Phillips y US Robotics. Originalmente el estndar USB fue creado con la intencin de reemplazar la multitud de conectores en las partes traseras de los PCs, as como para simplificar el software de configuracin de los dispositivos. El primer ordenador que ofreci puerto USB como estndar, fue el iMac G3 en mayo de 1998, incluyendo el conector USB para su ratn y teclado.

En la actualidad la especificacin USB est en su versin 2.0, que incrementa la tasa de transferencia respecto a la versin 1.0. Soporta tasas de transferencia de altas velocidades, comparables a las de un disco duro o almacenamiento magntico, lo cual ha permitido ampliar el uso del USB a aplicaciones de video y almacenamiento en discos duros externos. Una de las razones, a la cual se atribuye su gran popularidad, es que
2

http://en.wikipedia.org/wiki/Universal_Serial_Bus

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

todas las versiones del protocolo son compatibles hacia atrs. Es decir, que cualquier dispositivo 2.0 puede ser conectado a un dispositivo 1.0 y funcionar correctamente, aunque lo har a velocidad 1.0.

Existe tambin un protocolo USB denominado WirelessUSB. Es un protocolo de comunicacin inalmbrica por radio con gran ancho de banda, que combina la sencillez de uso del protocolo USB, con la versatilidad de las redes inalmbricas. Suele abreviarse W-USB o WUSB, si bien el USB-IF, que desarrolla su especificacin, prefiere referirse a esta tecnologa como Certified Wireless USB, para distinguirla de otros competidores.

Utiliza como base de radio, la plataforma Ultra-WideBand desarrollada por WiMedia Alliance, que puede lograr tasas de transmisin de hasta 480 Mbps en rangos de tres metros y 110 en rangos de diez metros, operando en rangos de frecuencia de 3,1 a 10,6 GHz. Se utiliza en mandos de videoconsola, impresoras, scanners, cmaras digitales, reproductores MP3, discos duros y flash, entre otros. Tambin puede utilizarse para la transmisin paralela de vdeo.

Figura 3.2 Conector USB 3.0

Actualmente en fase experimental, est la versin 3.0, con velocidades muy superiores a sus predecesores. Esta especificacin ser lanzada a mediados de 2009 por la compaa Intel, de acuerdo a la informacin recabada en la pgina web del frum USB-IF 3. La velocidad del bus ser diez veces ms rpida que la de USB 2.0 debido a la sustitucin

www.usb.org

Captulo 3

EL BUS USB

del enlace tradicional por uno de fibra ptica que trabaja con conectores tradicionales de cobre para hacerlo compatible con los estndares anteriores. Se espera que los productos fabricados con esta tecnologa lleguen al consumidor en 2009 o 2010.

Como se puede ver en la imagen 3.2, el conector USB 3.0 es similar tanto al USB 1.0 como al USB 2.0, de ah su total compatibilidad, por lo que slo se podr disfrutar de sus altas tasas de transferencia si los dispositivos conectados son compatibles con USB 3.0.

3.2

CARACTERSTICAS DEL BUS USB

En el presente apartado se presentan las caractersticas ms importantes del bus USB, dando una visin global de las caractersticas de velocidad de transmisin, topologa y funcionamiento del bus. Se presenta una comparacin del ancho de banda de los principales buses externos actuales. La tabla comparativa completa se puede consultar en la pgina web de Wikipedia 4.

3.2.1

Ancho de banda buses de comunicacin actuales

En el presente sub apartado se resumen las capacidades de los principales buses externos del mercado en trminos de transporte de datos. Esta caracterstica es conocida informalmente como ancho de banda, y se emplean unidades de Kilobits por segundo (Kbit/s), Megabits por segundo (Mbit/s), o Gigabits por segundo (Gbit/s) segn proceda. En el CD adjunto al proyecto, en la carpeta Memoria original\Imgenes se muestra una captura de pantalla, con nombre de archivo Velocidades Buses actuales. Es una tabla comparativa de los diferentes buses de comunicacin actuales en el cual se puede apreciar la posicin del protocolo USB en cuanto a tasa de transferencia. Entre ellos se encuentran los diferentes buses externos del computador, de almacenamiento, redes de rea local, mdems etc.

http://en.wikipedia.org/wiki/List_of_device_bandwidths

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El bus serie RS-232 tiene tasas de transferencia de 225 Kbit/s, mientras el bus serie RS422 tiene una velocidad de transferencia mxima de 10 Mbit/s. El puerto paralelo puede alcanzar los 16 Mbit/s, mientras que el protocolo FireWire 400 alcanza los 393 Mbit/s. Tal y como se muestra en el sub apartado siguiente la velocidad de un dispositivo USB de alta velocidad 2.0 puede alcanzar los 480 Mbit/s, muy superiores a los protocolos descritos con anterioridad. Esta caracterstica, anexada a la relativa facilidad de implementar un protocolo USB y a su baja repercusin en el presupuesto final de los dispositivos, lo hacen una tecnologa muy deseable.

3.2.2

Caractersticas de Transmisin bus USB

En el presente sub apartado se resumen las diferentes velocidades de los dispositivos USB as como los diferentes tipos de transferencias existentes en el protocolo. Los dispositivos USB se pueden clasifican en cuatro tipos, segn su velocidad de transferencia de datos. Los dispositivos segn esta clasificacin, pueden ser de baja, completa, alta y sper velocidad. Baja velocidad Low speed (1.0): Los dispositivos de baja velocidad generalmente son dispositivos de interaccin con la computadora, conocidos como dispositivos de interfaz humana (HID Human interface device), como lo son los teclados, los ratones y los joysticks. Este tipo de dispositivos tienen tasas de transferencia de hasta 1.5Mbit/s (192KB/s).

Velocidad completa Full speed (1.1): Esta fue la ms rpida antes de la especificacin USB 2.0 y muchos dispositivos fabricados en la actualidad trabajan a esta velocidad. Estos dispositivos, dividen el ancho de banda de la conexin USB entre las diferentes transferencias, basados en un algoritmo de bferes FIFO. La transferencia de este tipo de dispositivos tiene un lmite superior de 12Mbit/s (1.5MB/s).

10

Captulo 3

EL BUS USB

Alta velocidad High speed (2.0): Creado en abril del ao 2000 aumenta la tasa de transferencia mxima de este tipo de dispositivos alcanzando los 480Mbit/s (60MB/s). Este es el estndar actual de la mayora de los dispositivos modernos.

Sper velocidad (3.0): Actualmente en fase experimental y con tasa de transferencia de hasta 4.8Gbit/s (600MB/s).

A continuacin se resumen las caractersticas fundamentales, de las diferentes transferencias que se pueden llevar a cabo en el protocolo USB. El enlace virtual (pipe) puede ser de enlace de control, Bulk, interrupt e iscrona.

Control: Este modo es el utilizado para realizar configuraciones. Se da lugar siempre sobre el endpoint0, siendo imperativo para todos los dispositivos USB, el soportar este tipo de transferencia.

Los datos de control sirven para configurar el perifrico en el momento de conectarse al USB. Algunos drivers especficos pueden utilizar este enlace para transmitir su propia informacin de control. Este enlace no tiene prdida de datos, puesto que los dispositivos deteccin de recuperacin de errores estn activos a nivel USB.

Bulk: Este modo de transferencia se utiliza para la transmisin de importantes cantidades de informacin. Este es el tipo de transferencia que se utiliza en los perifricos USB creados en el proyecto.

Como el tipo control, este enlace no tiene prdida de datos. Este tipo de transferencia es til cuando la razn de transferencia no es crtica como por ejemplo, el envo de un archivo a imprimir o la recepcin de datos desde un escner.

En estas aplicaciones, la transferencia es rpida, pero puede esperar si fuese necesario. Solo los dispositivos de media y alta velocidad utilizan este tipo de transferencia.

11

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Interrupt: Este modo es utilizado para transmisiones de pequeos paquetes y rpidos, orientados a percepciones humanas (ratn, punteros). Este tipo de transferencia es la utilizada por dispositivos que deben recibir atencin peridicamente y lo utilizan los dispositivos de baja velocidad. Este tipo de transmisin garantiza la transferencia de pequeas cantidades de datos. El tiempo de respuesta no puede ser inferior al valor especificado por la interfaz. Isochronous o Flujo en tiempo real: Este modo es el utilizado para la transmisin de audio o video comprimido. Este tipo de transmisin funciona en tiempo real, siendo ste el modo de mayor prioridad.

3.2.3

Topologa del bus

El sistema USB tiene un diseo asimtrico host centric, que consiste en un host o anfitrin, una cantidad de puertos USB aguas abajo y mltiples perifricos conectados en una topologa de estrella escalonada. Se pueden conectar a un host, un mximo de 127 dispositivos, incluyendo los dispositivos hubs o concentradores. A continuacin en la figura 3.3, se muestra una figura de la topologa del bus USB.

Figura 3.3 Tipologa en estrella escalonada

12

Captulo 3

EL BUS USB

El host controller o maestro del bus, de ahora en adelante host, utiliza la CPU de computador, haciendo uso de su capacidad de procesamiento. Maneja la memoria de sistema para el almacenaje de datos del protocolo y sus buses de datos para el trasiego de la informacin. Emplea sistema operativo para el manejo del puerto USB y su puesta en prctica total.

Todos los host deben tener un hub o concentrador raz integrado dentro del sistema. Es conocido como el hub root, que esta embebido en el controlador del bus o host, a partir del cual parte el sistema USB. Entre las competencias del host destacan las siguientes:

Detectar la conexin y desconexin de los dispositivos USB. Manejar el flujo de control entre los dispositivos USB y el host. Manejar el flujo de datos entre los dispositivos USB y el host. Recoger el estado y la estadstica de actividad proporcionando conexin ente los dispositivos USB y la aplicacin software que lo maneje. Maneja cinco reas de interaccin entre el host y los dispositivos: o o o o o La enumeracin y configuracin. Las transferencias iscronas. Las transferencias asncronas. Manejar la alimentacin de los dispositivos. Manejar la informacin del bus y del dispositivo.

3.2.4

Comunicacin USB

La comunicacin USB entre el host y el dispositivo est basada en pipes o canales lgicos. Los pipes son conexiones del host a una entidad lgica sobre el dispositivo llamado endpoint o punto final. No son conexiones fsicas, sino que son establecidas por el host en la configuracin inicial, para el manejo del protocolo.

En un dispositivo full speed se establecen 32 pipes lgicas unidireccionales, entre el software de la aplicacin y el interface del dispositivo. Existe un pipe por defecto que se utiliza en las transferencias de configuracin del dispositivo, como por ejemplo la enumeracin.

13

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En la figura 3.4 se muestra la visin global de una comunicacin USB entre el PC y el perifrico. Se establece una conexin lgica entre la aplicacin cliente y los diferentes interfaces del dispositivo. Cada interface no es ms que el agrupamiento de los endpoints segn el modo de operacin, como por ejemplo, modo normal o modo suspensin.

Estas conexiones lgicas son las utilizadas especficamente por el usuario, por lo que no responden a ningn estndar. En el presente proyecto, estas peticiones especficas son VERS y DATA. (Vase captulo 7 Software de control robot Hermes).

Figura 3.4 Visin global comunicacin USB

La aplicacin cliente tal y como se puede apreciar en la figura 3.4, le da rdenes sin formato USB al software del sistema USB, lo que se denomina driver, en el proyecto usbser.sys. Este driver tiene diferentes funciones. Adapta las rdenes del software

14

Captulo 3

EL BUS USB

cliente, en datos en tramas para el host y se comunica con el dispositivo en peticiones estndar. Estas peticiones estndar a travs del endpoint0, segn las especificaciones, deben ser siempre aceptadas por el perifrico. Estas peticiones son configuracin de interfaces, consumo de energa, enumeracin, etc. (Vase system\usb\usbctrltrf\usbctrltrf.c del firmware).

3.2.5

Transferencias USB

La comunicacin USB se basa en mensajes que se denominan transferencias. Cada transferencia es un mensaje completo que se enva desde o hacia el dispositivo. Las transferencias se envan en frames o tramas, que en el caso de dispositivos full speed tienen una duracin de 1ms. Esta caracterstica de transmisin divide las transferencias en segmentos, llamadas transacciones.

Cada transaccin USB est formada por los siguientes paquetes.

Token Packet: Cabecera que define la informacin que se va a transmitir. Data Packet: Paquete donde se transmite la informacin Status Packet: Usado para hacer la aceptacin o Acknowledge de las transacciones.

Figura 3.5 Transferencias en comunicacin USB

15

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Token packets
Hay tres tipos de token packets:

IN: Informa al dispositivo USB, que el host quiere leer informacin. OUT: Informa al dispositivo USB, que el host va a mandarle informacin. SETUP: Usada para empezar transferencias de control

Los token packets siguen el siguiente formato:

Figura 3.6 Formato token packet

Data packets
Hay dos tipos de data packets, cada uno de ellos capaz de transmitir de 0 a 1023 bytes de datos. Concretamente son los paquetes Data0 y Data1. Estos paquetes tienen el siguiente formato:

Figura 3.7 Formato data packet

Handshake packets
Hay tres tipos de handshake packets, que consisten simplemente en la transaccin de un PID. Concretamente son los PID de ACK, NAK y STALL.

ACK: Acknowledge de que el paquete ha sido recibido con xito. NAK: Reporta que el dispositivo no puede mandar o recibir datos temporalmente. STALL: Es un error ms severo que el anterior, requiriendo intervencin del host.

16

Captulo 3

EL BUS USB

Los handshake Packets tienen el siguiente formato.

Figura 3.8 Formato handshake packet

SOF packets
Existe un paquete especial llamado Start of Frame Packets. Se utilizan para iniciar cada nueva trama. Consiste en un nmero de trama de 11 bits mandado por el host cada 1mS. El SOF packet tiene el siguiente formato:

Figura 3.9 Formato SOF packet El campo Sync es un bloque de 8 bits de tamao, que es usado para sincronizar el reloj del elemento receptor con el transmisor.

Figura 3.10 Identificadores paquetes PID

17

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El campo PID representa los packets ID. Usados para identificar el tipo de paquete que va a ser mandado. En la figura 3.10 se muestra una tabla que desglosa los diferentes PID vlidos.

El campo ADDR representa la direccin del dispositivo para el que corresponde el paquete de informacin. Es un campo de 7 bits que permite distinguir 127 dispositivos USB. La direccin 0 no es una direccin vlida, ya que cualquier dispositivo que no tenga asignada una direccin debe responder a estos paquetes. El campo ENDP est formado endpoints. El campo CRC Cyclic Redundancy Checks se utiliza para el chequeo de envo de datos. por cuatro bits, que permite direccionar 16 posibles

El campo EOP o end of packet se utiliza para sealar el fin da cada paquete de datos. Se sealiza con lo que se denomina como Single Ended Zero (SE0).

En la figura 3.11 se muestra una representacin de la transmisin por frames o tramas del protocolo USB. Se puede apreciar que cada trama empieza con un SOF packet. Cada frame est formado por un nmero indeterminado de transacciones. Cada transaccin, tiene una direccin de dispositivo y un nmero de endpoint, lo que determina exactamente el dispositivo y el rea de memoria que se va a leer o escribir.

Figura 3.11 Frames USB

Las transferencias, como se puede apreciar, se dividen en las tramas sucesivas hasta que se han completado. Esta estrategia de comunicacin tiene una razn de ser. Se comparte los frames para los diferentes dispositivos conectados al bus, de tal manera que cada uno tiene parte de la trama. Las transferencias Interrupt y asncronas tienen

18

Captulo 3

EL BUS USB

privilegios de transmisin en las tramas, sindoles asignadas un porcentaje configurable de la trama.

3.2.6

Elementos de las transferencias

Bsicamente los elementos en las transferencias son los endpoints y los enlaces virtuales, es por ello que en el presente captulo se resumen sus caractersticas ms relevantes. Endpoint

Las especificaciones USB definen un endpoint como una porcin del dispositivo USB con una direccin nica que es fuente o pozo de informacin en una comunicacin entre el host y el dispositivo. Esto sugiere que la informacin solo fluye en una direccin. Esto es cierto aunque los endpoints de control es un caso especial de flujo bidireccional.

Todas las transmisiones viajan desde o hacia un endpoint del dispositivo. Un endpoint es un buffer que guarda mltiples bytes. Tpicamente es un bloque de memoria de datos o unos registros en el microcontrolador. En el caso del PIC18F4550 5, estos buffers se encuentran en la memoria de acceso aleatorio RAM, concretamente del banco 4 (400h) hasta el banco 7 (7FFh) cada uno de ellos, de 256 bytes. En la figura 3.12 se puede apreciar la memoria asignada para el modulo USB del PIC.

Cuando el modulo USB est inhabilitado estas posiciones de memoria pueden usarse como registros de propsito general. Cuando el modulo USB est habilitado, la memoria de esos bancos es asignada como Buffer RAM para las operaciones USB.

-- Microchip PIC18F4550 Data Sheet -- 5.3.-Data Memory Organization

19

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 3.12 Memoria RAM USB PIC 18F4550

Esta rea de memoria es compartida entre la CPU del microcontrolador y el USB Serial Interface Engine (SIE) y es usada para compartir datos entre ambos. Tericamente se pueden usar las areas USB RAM que no sean asignadas como buffer endpoint como memoria de propsito general. En la prctica la naturaleza dinmica de la asignacin de USB RAM lo hace especialmente inestable.

Un endpoint configurado para hacer transferencias de control debe transferir datos en ambas direcciones, por lo que el endpoint de control consiste en un endpoint IN y un OUT que comparten el mismo nmero de endpoint. Cada dispositivo debe tener el endpoint0 configurado como endpoint de control. Puede darse el caso de que se necesite endpoints de control adicionales.

Cuando un dispositivo recibe una transaccin OUT o Setup conteniendo su direccin, su hardware almacena la informacin recibida en la ubicacin especifica del endpoint y se genera una interrupcin. Una rutina de servicio a la interrupcin en el dispositivo procesa la informacin recibida y ejecuta la accin requerida en la transaccin.

20

Captulo 3

EL BUS USB

Cuando un dispositivo recibe una transaccin IN conteniendo su direccin, si el dispositivo tiene el dato listo para mandar al host, el hardware manda el dato desde el endpoint especifico al bus y se genera una interrupcin. Una rutina de servicio a la interrupcin en el dispositivo configura el mismo para estar listo para la siguiente transaccin IN.

Pipes

Antes de que la transferencia pueda llevarse a cabo, el host y el dispositivo deben establecer un pipe (Tubera). Una USB pipe no es un objeto fsico, es solo una

asociacin entre el endpoint del dispositivo y el software del controlador host.

El host establece las tuberas despus de que se encienda el sistema o se conecte el perifrico al mismo. Si el dispositivo se desconecta del bus, el host elimina los pipes no necesarios. Cada dispositivo tiene un pipe de control por defecto que usa el Endpoint 0.

Figura 3.13 Comunicacin USB canales lgicos

21

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

3.2.7

Proceso de enumeracin

Cuando un nuevo dispositivo USB es conectado al puerto USB, el proceso de enumeracin de dispositivo USB comienza. Consiste en que el host le pregunta al dispositivo que se presente y le diga cules son sus parmetros, tales como:

Consumo de energa expresada en unidades de Carga Nmero y tipos de endpoints. Clase del producto. Tipo de transferencia Razn de escrutinio, etc.

El proceso de enumeracin primero enva una seal de puesta a cero al dispositivo USB. La velocidad del dispositivo USB es determinada durante la sealizacin de puesta a cero. Despus del reinicializado, la informacin de sistema de dispositivo USB es leda por el host y se le asigna una nica direccin de host controller de 7 bits.

Si el dispositivo es soportado por el host, los drivers del dispositivo necesarios para comunicarse con el dispositivo son cargados y el dispositivo pasa a estar configurado. Si el host es reiniciado, el proceso de enumeracin es repetido para todos los dispositivos conectados.

La informacin de configuracin recibida por el host incluye un descriptor por cada endpoint que el dispositivo quiere usar. Cada descriptor es un bloque de informacin que le dice al host lo que necesita saber para poder comunicarse con el endpoint. Concretamente incluye la direccin del endpoint, el tipo de transferencia que usa, el mximo tamao de los paquetes de datos y cuando sea necesario se incluye el intervalo deseado entre transferencias.

En todos los casos, el host acepta una peticin de configuracin, solo despus de asegurarse de que el bus tiene suficiente ancho de banda, para hacer las transferencias a la tasa requerida. Este es el caso de que la configuracin requiera pipes con transferencias iscronas, las cuales tienen una tasa de transferencia asegurada

22

Captulo 3

EL BUS USB

(transacciones por segundo). Este caso tambin se da en transferencias interrupt, las cuales tienen garantizada una mxima latencia (tiempo entre transacciones).

En estos casos, el host examina el ancho de banda disponible antes de establecer los pipes. Si existe suficiente ancho de banda disponible, el host acepta la peticin de configuracin y asegura que las transferencias tengan el tiempo que necesitan. Si el ancho de banda no est disponible, el host deniega la peticin de configuracin y el software que la realiz debe intentarlo de nuevo. Ya bien sea esperando hasta que haya suficiente ancho de banda disponible o seleccionando una nueva peticin de configuracin que requiera menos ancho de banda. Para las pipes que mueven peticiones sin garanta de tiempos, el host no chequea el ancho de banda disponible, solo promete ajustar las transferencias, en el tiempo disponible, lo mejor que sea posible.

3.2.8

Sealizacin y conectores

El estndar USB especifica tolerancias para impedancia y de especificaciones mecnicas relativamente bajas para sus conectores, intentando minimizar la incompatibilidad entre los conectores fabricados por distintas compaas. El estndar USB, a diferencia de otros estndares tambin define tamaos para el rea alrededor del conector de un dispositivo, para evitar el bloqueo de un puerto adyacente por el dispositivo en cuestin.

Las seales del USB son transmitidas en un cable de par trenzado con impedancia de 90 15%, cuyos pares son llamados D+ y D-. Utilizan sealizacin diferencial en halfdplex para combatir los efectos del ruido electromagntico en enlaces largos.

Figura 3.14 Par trenzado cable USB

Los niveles de transmisin de la seal varan de 0 a 0.3V para bajos (ceros) y de 2.8 a 3.6V para altos (unos). En las primeras versiones, los alambres de los cables no estn conectados a masa, pero en el modo de alta velocidad se tiene una terminacin de 45 a tierra o un diferencial de 90 para acoplar la impedancia del cable.

23

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El diseo elctrico permite cables USB de longitud mxima de 5 metros sin precisar un repetidor intermedio. La razn principal para este lmite es el mximo retraso de ida y vuelta permitido para las seales. Si un perifrico USB no responde a los comandos del host en un tiempo inferior a 1.5 microsegundos, se considera que el dispositivo ha perdido la comunicacin y el host lo considera perdido. Teniendo en cuenta los retrasos de usar el mximo nmero de hubs y el nmero de dispositivos conectables, el retraso mximo por cable resulta de 26 nanosegundos. Las especificaciones USB 2.0 determinan que el retraso mximo por cable/metro debe ser menor que 5.2 nanosegundos, de ah resultan los 5 metros mximos por cable.

En la figura 3.15, se pueden apreciar los diferentes tipos de conectores USB que existen en la actualidad. De izquierda a derecha se encuentra el Micro USB, Mini USB, Tipo B, Hembra tipo A y el Tipo A.

Figura 3.15 Tipos de conectores USB

El estndar USB determina que del lado del host controller o PC, los conectores sean los de tipo A, mientras que en el lado de los dispositivos el conector USB sea del tipo B. Todos los cables son machos, mientras que los enchufes en el PC o dispositivo son hembras.

Una extensin del USB llamada "USB-On-The-Go" (sobre la marcha) permite a un puerto actuar como servidor o como dispositivo. Esto se determina por qu lado del cable est conectado el perifrico. Incluso despus de que el cable est conectado y las unidades

24

Captulo 3

EL BUS USB

se estn comunicando, las 2 unidades pueden cambiar de papel bajo el control de un programa. Esta facilidad est especficamente diseada para dispositivos como PDAs, donde el enlace USB podra conectarse a un PC como un dispositivo, y conectarse como servidor a un teclado o ratn. El USB-On-The-Go utiliza los 2 conectores pequeos, el mini-A y el mini-B.

A continuacin, en la figura 3.16, se muestran las conexiones que se definen en las especificaciones USB 2.0 para los conectores. Estos conectores USB tienen cuatro pines que se definen en la siguiente tabla.

Figura 3.16 Conexiones USB

En las tablas 3.17 y 3.18 se muestran la descripcin de los pines de los conectores USB.

Pin Nombre
1 2 3 VCC DD+

Color
Rojo Blanco Verde

Descripcin
+5 V Data Data + Permite la distincin de Micro-A- y Micro-B-Plug.

ID

ninguno

Tipo A: conectado a Tierra Tipo B: no conectado

GND Negro Seal Tierra Figura 3.17 Tabla resumen pines conector mini/micro USB

25

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Pin
1 2 3 4

Nombre
VCC D D+ GND

Color del Cable


Rojo Blanco Verde Negro

Descripcin
+5V Data Data + Tierra

Figura 3.18 Tabla resumen pines conector USB estndar

3.2.9

Potencia del bus USB

El bus USB suministra 5v de continua, regulados por cada uno de sus puertos, a travs de los pines 1 y 4. El estndar exige que este voltaje no sea en ningn caso, mayor que los 5.25v ni menor de 4.375v.

El bus permite a los dispositivos de bajo consumo, que de otra forma deberan implementar fuente de alimentacin externa, obtener del bus la corriente necesaria para su funcionamiento. El lmite de corriente suministrada es de 500mA por puerto.

Cuando un dispositivo se conecta al bus, ste le reporta al host cuanta potencia va a consumir. De esta manera el host lleva un registro de los requisitos de cada puerto. Cuando un dispositivo se excede en el consumo, se apaga, cortndole el suministro de corriente, de forma que no afecte al funcionamiento del resto de los dispositivos conectados al puerto.

El estndar exige que los perifricos conectados lo hagan en un modo de bajo consumo, de 100mA, y luego le comuniquen al host cuanta corriente precisan. Posteriormente pueden cambiar a un modo de alto consumo, si se lo permite el host. Los dispositivos que no cumplan con los requisitos de potencia y consuman ms corriente de la negociada con el host pueden dejar de funcionar sin previo aviso o en algn caso dejar el bus inoperativo.

En el presente proyecto se han configurado los dispositivos con fuente de alimentacin externa, debido a los consumos elevados de los mismos. Vase el anejo A2.4.1 Pruebas de consumo.

26

Captulo 3

EL BUS USB

3.3

CLASES DE DISPOSITIVOS USB

En el presente capitulo se muestran las diferentes clases de USB. Los dispositivos USB son nicos, pero a pesar de ello comparten similitudes con otros dispositivos. Por ejemplo, todas las impresoras reciben e imprimen datos y responden al host con informacin de status. Todos los ratones mandan datos sobre sus movimientos y clics de botn al host. Todos los discos duros externos intercambian archivos con el host.

Cuando un grupo de perifricos comparten atributos o cuando responden a peticiones similares, se les agrupa en clases. Estas clases definen un comportamiento esperado en trminos de dispositivo y descriptores de interfaz de modo, por lo que se puede utilizar el mismo driver para cualquier dispositivo miembro de una cierta clase. Los sistemas operativos tienen drivers genricos para cualquier clase de dispositivo USB. Adems de ello, se simplifica el firmware ya que el trabajo de definir los atributos y servicios ya est hecho, por lo que solo se han de implementar los detalles especficos en cada caso concreto. A continuacin se muestra un listado de las clases USB ms comunes. Consultar la pgina web de Wikipedia 6 para ms informacin al respecto.

3.3.1

Clase Audio Device 01h

Es el interface para el audio de las tarjetas de sonido, los micrfonos y los altavoces USB. El sistema operativo usa el driver USBAudio.sys para comunicarse con el dispositivo.

3.3.2

Clase CDC 02h

Esta es la clase USB utilizada en el proyecto. Se utiliza en comunicaciones y control CDC, como por ejemplo el adaptador Ethernet, el modem y el adaptador de puerto serie. Utiliza el driver usbser.sys.

http://en.wikipedia.org/wiki/USB

27

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

3.3.3

Clase HID 03h

Esta clase de dispositivo es la clase HID Human interface device. Esta clase agrupa a los dispositivos que requieren la intervencin del usuario, como por ejemplo teclado, ratn y joystick. Este tipo de dispositivos transfieren bloques de informacin al host con tasas de transferencia moderadas, usando transferencias Interrupt.

3.3.4

Clase PID interface Device 05h

Esta es una clase derivada de la HID mencionada con anterioridad. Esta clase soporta feedback en tiempo real, como por ejemplo joystick con feedback en fuerza.

3.3.5

Clase Printer 07h

El interface printer es la clase de las impresoras y utilizan el driver usbprint.sys.

3.3.6

Clase USB mass-storage 08h

Esta clase de USB implementa la conexin entre perifricos de almacenamiento de datos usando un estndar llamado USB mass storage device class o UMS. Esta clase fue creada inicialmente para perifricos de almacenamiento ptico como pueden ser lectores de CD y DVD. Utiliza el driver usbstor.sys que se dispone desde la versin Windows 2000. Esta forma de almacenamiento no tiene como objetivo ser el bus primario para el almacenamiento interno del ordenador. Los buses ATA (IDE), Serial ATA (SATA) y SCSI realizan ese papel de una manera ms eficaz. Sin embargo, el USB tiene en la facilidad de instalar perifricos sin tener que abrir el ordenador, como por ejemplo lectores externos, lo que ha propiciado su gran popularidad actual.

3.3.7

Clase Video Device 0Eh

La clase de dispositivo USB de vdeo UVC es una clase de dispositivo USB, que describe dispositivos capaces de transmitir vdeo como webcams, videocmaras digitales, 28

Captulo 3

EL BUS USB

convertidores analgicos de vdeo, sintonizadores de televisin, y cmaras de imagen fija. La ltima revisin de la especificacin de clase USB de vdeo es la versin 1.1. Ha sido desarrollada por el USB-IF, cuyas especificaciones vienen recogidas en el estndar de su clase. Utiliza el driver Usbvideo.sys.

29

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

4 FIRMWARE USB DEL PIC


En el presente capitulo se explica el cdigo que ha de albergar el microcontrolador para manejar el puerto USB.

4.1

INTRODUCCIN

Como ya se ha comentado con anterioridad el microcontrolador 18F4550 dispone de un mdulo USB. Dicho modulo se puede controlar directamente por perifrico consultando el data sheet del fabricante y las especificaciones del USB o bien utilizar un firmware o cdigo esqueleto para manejar el USB. Es la forma elegida en el proyecto, por ser la ms sencilla y prctica, haciendo uso de la gran labor de los ingenieros de Microchip.

Es un sistema de archivos construido de tal forma que puede ser usado para crear nuevas aplicaciones de una manera sencilla. Esto es debido, en gran medida, a su diseo totalmente estructurado por archivos. Tiene todo el cdigo necesario para el funcionamiento del protocolo USB y un espacio para colocar el cdigo propio de cada usuario. El fabricante Microchip ofrece el cdigo de forma gratuita para desarrollar aplicaciones USB en sus productos. Para el desarrollo de este tipo de firmware se ha de contar con el siguiente software, que tambin puede descargarse de la pgina del fabricante 7.

MPLAB IDE (Compilador y debugger Microchip). Microchip C18 (Lenguaje C para microcontroladores PIC18).

En el CD adjunto al proyecto en la carpeta Anejos Electrnicos/programas/firmware Hermes USB CDC se encuentran las diferentes versiones del firmware CDC creadas en el presente proyecto. A su vez se adjunta una versin de firmware de clase USB genrica para futuras lneas de trabajo.

www.microchip.com

30

Captulo 4

EL FIRMWARE USB DEL PIC

Dicho firmware encapsula varias funciones, ocultando toda la complejidad necesaria, para la comunicacin USB de forma que provee de una comunicacin serie tradicional entre el PIC y el PC. Entre las caractersticas ms importantes del firmware CDC destacan las siguientes:

Tasa de transferencia mxima de 80 Kbytes/s. Las libreras compiladas ocupan un tamao reducido (4Kb). Resuelve toda la comunicacin en software, sin requerir hardware adicional. El flujo de datos es manejado enteramente por el protocolo USB (no es necesario usar XON/XOFF ni control de flujo por hardware).

4.2

ESTRUCTURA FIRMWARE USB

A continuacin en la figura 4.1 se muestra un diagrama de flujo simple, que explica la operacin bsica del firmware, en la cual, el bucle negro es el principal y los bucles azul y rojo son dos niveles de subrutinas ejecutadas con las funciones en el bucle principal.

Figura 4.1 Diagrama de flujo bsico Microchip USB Firmware

31

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Dicho proyecto tal y como se muestra en la figura 4.2, se encuentra localizado dentro de un solo directorio raz, con varios subdirectorios que contienen cdigo fuente y aplicaciones. El directorio raz para el proyecto puede ser grabado en cualquier parte del disco duro de la computadora y tener cualquier nombre de carpeta vlido, sin embargo la estructura de los subdirectorios se ha de mantener siempre. A continuacin, en la figura 4.2 se muestra la estructura de directorios que tiene el firmware USB de Microchip.

Figura 4.2 Microchip USB Firmware

A continuacin se desglosan las diferentes carpetas presentes en todos los firmwares USB de la marca Microchip.

El directorio _output contiene los archivos de salida compilados entre los que se encuentra el archivo con extensin .hex para grabar el PIC. El directorio autofiles contiene la configuracin global del USB y sus descriptores.

32

Captulo 4

EL FIRMWARE USB DEL PIC

El directorio system contiene el firmware del USB. Contiene las funciones que dan respuesta a las peticiones estndar de control. El directorio user es la carpeta, en la que residen los diferentes programas especficos de usuario. Contiene las funciones que dan respuesta a las peticiones especficas de usuario.

La carpeta inf contiene el descriptor necesario para la asignacin de driver en el proceso, del sistema operativo, de enumeracin del perifrico USB

En la carpeta raz de los proyectos existen una serie de archivos, que por su importancia se alojan en primer plano. Estos son el archivo main, io_cfg y el archivo de linker del firmware. El archivo main.c es el que contiene el archivo inicio del proyecto y el archivo io_cfg.h mapea los nombres de los pines del microcontrolador a utilizar en el proyecto. El archivo 18f4550.lkr es el archivo necesario para el linkado de los diferentes archivos del proyecto. El fichero de script de linker indica que libreras debe utilizar, la inicializacin del micro y como debe distribuir el cdigo en la memoria.

El firmware dispone de un archivo llamado CleanUp.bat, que limpia la carpeta de salida (_output) y todos los subdirectorios de compilaciones anteriores del cdigo.

Dicho firmware est diseado para tener un ambiente cooperativo, de forma que no se deben hacer programas con funciones bloqueantes ya que afecta al estado del dispositivo en el bus USB. En la funcin main existe un bucle infinito while que maneja diferentes tareas. Cada una de ellas es una tarea USB o una tarea de usuario. Las tareas USB son manejadas por USBTasks, mientras que las tareas de usuario las maneja ProcessIO. La estructura del firmware USB provee un conjunto de interfaces modulares que manejan la mayor parte del trabajo de la comunicacin USB, tal y como se puede apreciar en la figura 4.3.

33

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 4.3 Flujo lgico Microchip USB Firmware

La rutina USBTasks es la funcin que mantiene el dispositivo activo en el bus. Es la funcin de la que parten todas las funciones para el manejo del bus a nivel de transacciones. Dicha funcin y sus ramificaciones para controlar el bus, han sido creadas por los ingenieros de Microchip, para simplificar el desarrollo de productos con conexin USB. La nica cuestin que el programador debe considerar, a la hora de desarrollar una aplicacin USB con este firmware, es la frecuencia de refresco de la funcin USBTasks. Dicha frecuencia debe ser mayor que 500Hz aproximadamente segn las pruebas realizadas. Si no se ejecuta dicha funcin con una frecuencia igual o mayor que sta, la conexin USB entre el dispositivo y el sistema operativo se pierde. Esta es la razn por la que el coste computacional de la funcin ProcessIO correspondiente a la tarea de usuario, debe ser lo ms liviana posible. En caso de que dicha funcin sea irremediablemente pesada se debe recurrir a una interrupcin por desbordamiento del

34

Captulo 4

EL FIRMWARE USB DEL PIC

timer en la que se ejecute USBTasks. En sta, se ejecutan las siguientes funciones que se desglosan a continuacin: USBCheckBusStatus:

Esta funcin se encarga de detectar el estado del dispositivo en el bus. Si el firmware se ha programado para deteccin de estado por pin digital (Vase USBC en el captulo 5 Arquitectura y Hardware robot Hermes), esta funcin actualiza el estado del dispositivo USB, cuyos estados posibles son: El estado de DETACHED_STATE, correspondiente al estado de desconexin. El ATTACHED_STATE estado inicial de conexin del dispositivo al puerto USB. El caso POWERED_STATE es el siguiente estado, que corresponde al estado de dispositivo alimentado por el bus USB, en caso de que se configure como tal. Los siguientes estados son ADR_PENDING_STATE, ADDRESS_STATE y

CONFIGURED_STATE, que son las fases del dispositivo durante el proceso de enumeracin y configuracin del dispositivo, por el sistema operativo de la computadora. En caso de conexin se actualiza el estado del dispositivo como Attached_State y se habilita el modulo USB poniendo a uno lgico el bit USBEN (USB Module Enable Bit) del registro del microcontrolador USB Control Register. En caso de desconexin se actualiza como Detached_State y se deshabilita el modulo USB del PIC. En la siguiente vez que se ejecuta la funcin, si el estado es Attached_State pasa a un siguiente estado Powered_State. Cuando el sistema operativo encuentra un dispositivo en el estado Powered_State, inicia con l la fase de negociacin o numeracin, descrita con anterioridad. USBDriverService:

Dicha funcin se encarga de controlar las transacciones de datos en el bus al nivel ms bajo, as como de la deteccin y manejo de las interrupciones USB. A continuacin se listan las interrupciones de USB que son manejadas en dicho archivo:

1. Actividad en el bus para despertar al dispositivo en suspensin.

35

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

2. Deteccin y manejo de situacin de reset. 3. Deteccin y de bus en suspensin. 4. Deteccin de paquetes SOF (Start of frame). 5. Deteccin y manejo de errores en el bus. 6. Deteccin de transaccin completada. Se manejan las transacciones de control necesarias con la funcin USBCtrEPService. Todas las transferencias sobre el endpoint de control por defecto, necesitan seguir el protocolo de transferencia tal y como est descrito en la especificacin del protocolo USB.

El servicio de transferencia de control est proporcionado por las funciones contenidas en el archivo usbctrltrf.c. La primera fase de todas las transferencias de control entrantes son peticiones. Las peticiones USB pueden ser del tipo estndar o tipo especfico. Las peticiones estndar son atendidas por USBCheckStdRequest, que maneja las peticiones solicitadas tal y como est especificado en el estndar del bus USB Universal Serial Bus Revision 2.0 specification 8, en su captulo 9 USB Device Framework. Las peticiones de una clase especfica necesitan ser manejadas por el archivo del firmware especfico de esa clase, que maneje esa peticin. El proceso de enumeracin USB es manejado principalmente en usb9.c. Uno de los pasos ms importantes en la enumeracin de procesos es el manejo de la peticin SET_CONFIGURATION, que es generada por USBStdSetCfgHandler. La configuracin de los dispositivos USB es manejada tambin de forma modular, modificando variables en un pequeo nmero de archivos. De esta manera la informacin se encuentra de manera global en tiempo de compilacin. Los archivos son altamente independientes y transfieren informacin entre ellos mismos en tiempo de compilacin para crear la configuracin completa del USB. En la figura 4.4 se muestran las interrelaciones de los diferentes archivos de configuracin USB.

http://www.usb.org/developers/docs

36

Captulo 4

EL FIRMWARE USB DEL PIC

Figura 4.4 Relaciones en tiempo de compilacin entre los archivos de configuracin El directorio autofiles contiene tres archivos cruciales para la operacin del USB: usbcfg.h: Dicho archivo alberga la configuracin global del USB. usbdsc.c: Es el archivo descriptor del USB. usbdsc.h: Es el archivo cabecera del descriptor USB.

El archivo usbcfg.h es el archivo ms importante del proyecto entero. Define el mapeo de los endpoints a sus funciones de clase. Tambin define el nmero de identificacin (Microchip USB ID MUID), el cual es usado para determinar a qu clase de dispositivo USB pertenece el proyecto. Para centralizar la configuracin de las caractersticas importantes del USB, todas las opciones en tiempo de compilacin relacionadas con el USB se encuentran en este archivo. Est dispuesto como una serie de directivas del compilador #define, siendo las opciones de configuraci las siguientes: EP0_BUFF_SIZE [buffer_size] MAX_NUM_INT [max] MODE_PP [PPBMn] UCFG_VAL [option1 | option2 ]

37

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

USE_SELF_POWER_SENSE_IO MAX_EP_NUMBER [max_ep]

EP0_BUFF_SIZE: Define el tamao del buffer para el endpoint 0. Puede tener un valor valido de 8, 16, 32 o 64 bytes. Es utilizado durante la compilacin del proyecto para reservar el tamao apropiado del buffer para dicho endpoint. Hay que tener en cuenta que un dispositivo USB de baja velocidad solamente puede usar un buffer de 8 bytes, mientras que uno de velocidad total puede usar cualquiera de los tamaos expuestos con anterioridad. MAX_NUM_INT: Define el tamao del array de la configuracin activa de cada interface, que puede ser cambiado durante la operacin. Los valores vlidos son los enteros [0,1,2,]. Por ejemplo, si un dispositivo con dos configuraciones tiene tres interfaces en la primera y dos interfaces en la segunda MAX_NUM_INT en este caso es tres. MODE_PP: Define el buffer del modo ping-pong a ser usado durante la ejecucin. Los valores permitidos son _PPBM0, _PPBM1, _PPBM2. Cada uno de ellos se encuentra definido en el archivo de cabecera usbdrv.h. (Vase registro UCFG de la seccin 17.4.4 del manual del microcontrolador). UCFG_VAL: Define el valor inicial del registro especial UCFG. Los valores permitidos son: _LS o _FS: Selecciona entre velocidad baja y velocidad total. _TRINT o TREXT: Selecciona entre el modo de transmisin-recepcin interno o externo. _PUEN: Se usan los resistores pull-up internas del microcontrolador. _OEMON: Se usa el indicador de salida SIE. _UTEYE: Habilita el modo de salida eye-pattern. (Vase seccin 17.2.2.7 del manual del microcontrolador). USE_SELF_POWER_SENSE_IO: Indica que el microcontrolador est detectando la presencia de una alimentacin on-board a travs de un pin digital del PIC. En el presente proyecto, no ha sido implementada dicha funcin.

38

Captulo 4

EL FIRMWARE USB DEL PIC

USE_USB_BUS_SENSE_IO: Indica que el firmware puede usar el pin definido en io_cfg.h, para determinar cundo se ha activado el mdulo USB. Cuando dicho registro no sea utilizado, el modulo USB estar siempre habilitado, lo que tiene un gasto de energa innecesario. En el presente proyecto se ha configurado el USB para la habilitacin del modulo USB del PIC solo cuando el dispositivo se encuentra conectado. Hay que recordar que el robot funciona a bateras y es un factor limitante en el proyecto. USB_USE_CDC: Es usado para indicar qu clase de dispositivo USB es utilizado. Le dice al archivo cabecera USB global usb.h, que archivos de cabecera de clase especficos necesitan ser incluidos. El archivo de cabecera usb.h es usado globalmente como un archivo necesario cuando se compila el proyecto. En este caso, la clase es CDC por lo que se agregan al proyecto los archivos cdc.c y cdc.h.

MAX_EP_NUMBER: Dicho nmero indica cuantos endpoints de memoria sern utilizados por el firmware. Esta definicin es usada por usbmap.c para reservar el buffer de los registros descriptores de USB

El archivo usbdsc.c, contiene la informacin del descriptor USB para el microcontrolador. Este archivo tambin es de vital importancia en el desarrollo de dispositivos USB. Existe una cadena descriptor USB definida de la siguiente manera:

rom struct {byte bLength;byte bDscType;word string[20];}sd002= {sizeof(sd002),DSC_STR, 'H','e','r','m','e','s',' ','U','S','B',' ','D','e','m','o','B','o','a','r','d'};

Esta estructura provee un mecanismo para que el compilador C18 le informe al sistema operativo el nombre del dispositivo que se ha implementado. A continuacin en la figura 4.4 se muestra una captura de pantalla en la que se puede apreciar este hecho en el titulo de la ventana.

39

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 4.4 Detalle propiedades dispositivo USB

En este archivo tambin se define el Vendor ID y el Product ID. El estndar USB exige que todos los dispositivos, durante la etapa de negociacin, se identifiquen con un Vendor ID y un Product ID, en adelante VID y PID. Dicho par de valores sirve para conocer el fabricante del dispositivo VID y el modelo particular del producto que ha sido conectado PID, por lo tanto, modelos diferentes de un mismo producto generalmente tienen PIDs diferentes. La utilidad principal de estos valores no es solamente la de identificar el dispositivo, sino la de encontrar y cargar los drivers apropiados para el mismo. Por consiguiente, cada driver que se dispone en Windows, viene programado con uno o ms PID y VID para los cuales sirve dicho driver. Esta es la forma que tiene Windows para saber si el driver seleccionado es correcto.

El par VID/PID basta para identificar el driver que es necesario cargar y por lo tanto cuando se conecta un dispositivo con VID/PID conocido el sistema lo detecta

40

Captulo 4

EL FIRMWARE USB DEL PIC

automticamente e inmediatamente queda listo para usar. Cuando se conecta un dispositivo desconocido por el sistema operativo, ste pide al usuario que le suministre los drivers. En la figura 4.5 se muestra una captura de pantalla que muestra el mensaje del sistema operativo al conectar el dispositivo nuevo.

Figura 4.5 Nuevo hardware detectado de Windows

Los sistemas operativos Windows, desde la versin 98SE, ya traen incluido el driver para el control de dispositivos CDC. El proyecto se ha realizado en Windows vista y por causas que no han sido aclaradas, dicho sistema operativo no dispona de dicho driver, y ha requerido la descarga de una versin adecuada del driver. Dicho driver es el archivo usbser.sys, que ha de albergarse en c:\windows\system32\drivers.

En el CD adjunto al proyecto en la carpeta 6.- Driver Windows Vista\Driver necesario Clase CDC se presenta el driver necesario para Windows vista.

Todos los dispositivos que utilizan dicho driver automticamente agregan un puerto COM virtual al sistema, mientras estn conectados, de forma que cualquier aplicacin puede trabajar directamente con el puerto virtual como si se tratase de cualquier puerto serie

41

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

real. Sin embargo, Windows a priori no sabe que driver debe asignar a los dispositivos, porque no reconoce el par VID/PID. En la figura 4.6 se muestra como presenta Windows el dispositivo. .

Figura 4.6 Administrador de dispositivos de Windows

Por lo tanto, es necesario indicarle a Windows que driver debe utilizar el VID/PID definido en el archivo usbdsc.c del firmware. Esto se hace a travs de un archivo .inf donde se especifica entre otras cosas:

VID/PID del dispositivo. Driver a utilizar. Nombre con el que los perifricos aparecern en la lista de dispositivos del men administrador de dispositivos de Windows.

42

Captulo 4

EL FIRMWARE USB DEL PIC

Figura 4.7 Actualizar software de controlador

Siguiendo las pautas mostradas en la figura 4.7, se debe indicar al sistema operativo, la localizacin del archivo .inf. Cada firmware dispone de una carpeta inf donde se puede hallar el archivo .inf especfico para cada dispositivo que se configure.

Lo ms relevante de dicho archivo es la configuracin VID/PID. Dichos valores deben coincidir con los valores del firmware en el archivo usbdsc.c para que Windows reconozca el dispositivo y automticamente le asigne el driver usbser.sys. A continuacin se muestra un ejemplo de la codificacin que se ha de realizar para la configuracin de un dispositivo USB.

%DESCRIPTION%=DriverInstall, USB\VID_04D8&PID_1000

43

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 4.8 Archivo .inf

En la figura 4.9 se muestra el cdigo que se ha de modificar en el firmware USB que se debe elegir en consonancia con lo que se defina en el archivo .inf. En el valor del VID se ha de elegir 04D8 correspondiente al vendedor Microchip. Este valor es un valor fijo para todos los dispositivos USB que se desarrollen con microcontroladores PIC. El fabricante permite valores entre 0000 y FFFF para el valor PID pudindose as discernir entre ms de 65000 dispositivos USB.

44

Captulo 4

EL FIRMWARE USB DEL PIC

Figura 4.9 Archivo usbdsc.c

4.3

FIRMWARE USB CLASE CDC MICROCHIP

En el presente apartado se detallan las principales funciones para la comunicacin por el puerto USB, que ha de considerar el programador del dispositivo. Se definen a su vez, las consideraciones ms relevantes a la hora de utilizar dichas funciones. Estas funciones se explican ms en detalle en el articulo creado por Microchip, Migrating Applications to

45

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

USB from RS-232 UART with Minimal Impact on PC Software 9. En el CD adjunto, en la carpeta 4.- Manuales\USB, se adjunta dicho artculo para su consulta.

Toda la comunicacin a travs del puerto USB se realiza utilizando un juego de funciones que provee el firmware CDC. Para que la comunicacin USB funcione correctamente y que el dispositivo no pierda la conexin con el computador, el firmware CDC impone ciertas restricciones que es necesario seguir estrictamente. PutrsUSBUSART (char *data):

Esta funcin escribe una cadena de caracteres incluyendo el carcter nulo de fin de cadena. Esta funcin se usa para transferir cadenas de caracteres literales al host.

Cabe destacar que el mecanismo de transferencia del dispositivo al host es ms flexible que el mecanismo de transferencia del host al dispositivo. Se puede manejar cadenas de datos ms largos que el tamao mximo del endpoint Bulk IN. El firmware para ello, utiliza una maquina de estados, para transferir las cadenas largas de datos usando varias transacciones USB. Esto se consigue con la funcin del firmware CDCTxService, por lo que el usuario no debe preocuparse de este hecho.

Dicha funcin tiene como argumento de entrada una cadena de caracteres o un puntero a una cadena de caracteres con carcter fin de cadena. Si no se encuentra este carcter, se escriben los primeros 255 bytes de datos encontrados. Las especificaciones CDC obligan a anteponer a la funcin putrsUSBUSART la funcin mUSBUSARTIsTxTrfReady. Esta funcin se asegura de que el bus se encuentre listo para una nueva transmisin. Byte getUSBUSART (char *buffer, byte len):

Copia una cadena recibida a travs de un endpoint Bulk OUT, a una variable de usuario. No es una funcin bloqueante, es decir no se queda esperando al dato si no hay dato disponible.

http://ww1.microchip.com/downloads/en/AppNotes/00956b.pdf

46

Captulo 4

EL FIRMWARE USB DEL PIC

El tamao del valor del argumento de entrada len, debe ser menor o igual que el tamao mximo del endpoint responsable de recibir los datos Bulk. Este tamao mximo se define en CDC_BULK_OUT_EP_SIZE, en el archivo usbcfg.h del firmware USB. En el proyecto se ha programado con el valor 64, lo que en cualquier caso supera los mensajes posibles del protocolo. (Vase captulo 7 Software de control Hermes).

4.4

CONSIDERACIONES AL USAR EL FIRMWARE CDC

En el presente proyecto, se descarg de la red un proyecto que utilizaba la clase CDC que se quera implementar en el robot Hermes. Aunque puede parecer trivial, se present un par de cuestiones que si no se resuelven no se podra haber desarrollado la comunicacin.

La primera cuestin que se debe realizar para utilizar el firmware es la definicin del PIC que se quiere programar. Se le debe indicar en todos los archivos necesarios la siguiente sentencia. Otra cuestin de vital importancia es que las sentencias del tipo #include "system/typedefs.h" aparecan con la barra invertida del revs, para su compilacin en Linux.

#include <p18f4550.h> #include "system/typedefs.h" #include "system\typedefs.h" Correcto en Windows Correcto en Linux

En cuanto a las comunicaciones USB se debe chequear si el driver se encuentra listo para aceptar un nuevo dato escrito en el USB. Para ello se ha de utilizar la macro mUSBUSARTIsTxTrfReady. Es importante no escribir dicha funcin de un modo bloqueante.

Incorrecto: Correcto:

while (mUSBUSARTIsTxTrfReady()) if (mUSBUSARTIsTxTrfReady())

47

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

No se debe utilizar cdigo bloqueante, dado que las funciones del puerto USB se ejecutan en la rutina USBTasks. Se debe evitar a toda costa utilizar funciones bloqueantes que dependan del estado del puerto USB, puesto que ste no se actualiza hasta que se vuelva a entrar en USBTasks, y por lo tanto resultara en una situacin de deadlock.

Las

funciones

de

envo

de

datos

(putsUSBUSART,

putrsUSBUSART,

mUSBUSARTTxRam y mUSBUSARTTxRom), no son funciones bloqueantes ni tampoco envan los datos inmediatamente, sino que habilitan determinados registros e inicializa una mquina de estados para la transferencia que se ejecutara posteriormente en la rutina CDCTxService. Debido a esto, llamadas consecutivas a dichas funciones no funcionan pues la ltima llamada siempre sobrescribe la anterior. La forma correcta de enviar varias cadenas consecutivamente es usando una mquina de estado o implementando rutinas que almacenen los datos en un buffer intermedio.

Incorrecto: Llamadas consecutivas


If (mUSBUSARTIsTxTrfReady()) { putrsUSBUSART("Hola mundo"); putrsUSBUSART("Hola de nuevo"); }

Correcto: Usando mquina de estado byte state = 0; if(state == 0) { if(mUSBUSARTIsTxTrfReady()) { putrsUSBUSART("Hola mundo"); state++; } } else if(state == 1) { if(mUSBUSARTIsTxTrfReady()) { putrsUSBUSART("Hola de nuevo"); state++; }

48

Captulo 4

EL FIRMWARE USB DEL PIC

En cuanto al compilador C18 de Microchip, aunque se ajusta bastante bien al estndar ANSI '87, vale recalcar que tiene algunas particularidades que es necesario tener en cuenta a la hora de escribir cdigo, como es el manejo de las variables en memoria. En concreto, las variables pueden estar almacenadas tanto en memoria RAM como en memoria ROM. El compilador C18 soporta un par de calificadores, no contemplados en el estndar de C, ROM y RAM que permiten especificar donde se guardar la variable. Por ejemplo: ROM int version; RAM char [10] command; El problema es que las funciones de manejo de string no permiten trabajar con variables ubicadas en distintas memorias. Por lo tanto, la funcin strcmp() no permite comparar una cadena almacenada en la ROM con otra cadena almacenada en la RAM. Todas las variables definidas sin el calificador ROM/RAM quedan por defecto almacenadas en la RAM, mientras que las constantes string como "Hola mundo" quedan almacenadas en la ROM. Tmese como ejemplo el siguiente cdigo:

#include <string.h> char cadena[10] = "hola"; bool comparo() { if (strcmp(cadena, "hola")) {return TRUE;} else {return FALSE;} }

49

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En principio, la funcin comparo() debera retornar TRUE. Sin embargo, debido a los problemas mencionados del almacenamiento en la RAM/ROM, retorna FALSE puesto que strcmp() no sabe comparar datos de la RAM (cadena) con datos de la ROM ("hola"). Por lo tanto es necesario reescribir el cdigo de la siguiente manera para su correcto funcionamiento:

#include <string.h> char cadena[10] = "hola"; bool comparo() { char hola[5] = "hola";

if (strcmp(cadena, hola)) { return TRUE; } else { return FALSE;} }

Los configuration bits sirven para configurar el modo de funcionamiento del PIC (por ejemplo, la frecuencia del oscilador) y deben asignarse durante la programacin. Los bits de configuracin son inicializados por el MPLAB durante la programacin y se pueden asignar de 2 formas:

A travs de la lista de configuration bits del MPLAB.

A travs de macros en el propio cdigo, utilizando la declaracin #pragma config.

50

Captulo 4

EL FIRMWARE USB DEL PIC

En el presente proyecto se ha decidido utilizar un archivo del que disponen ciertos firmwares de la red, denominado configbits.h. De esta manera a travs de dicho archivo en el propio cdigo, no se depende de la configuracin del entorno de trabajo del MPLAB.

Figura 4.10 Configurar bits con MPLAB

Utilizar este archivo requiere que se tome en cuenta la versin del compilador que se va a utilizar y el firmware que se dispone. En el proyecto, el firmware que ha servido de base, se encontraba configurado para un PIC18F2520 con cristal de 20MHz, correspondiente a un proyecto realizado en junio de 2005.

Este hecho hace que se tenga que recurrir a los archivos de ayuda que ofrece el compilador C18 ya que existen algunas diferencias notorias entre las diferentes versiones de C18. Este microcontrolador dispone al igual que los dems de registro de Fail-Safe Clock Monitor. En las versiones antiguas de C18 se debe configurar de la manera que se expone en el siguiente cuadro de cdigo. De cualquier forma se puede definir estos bits de configuracin a travs de MPLAB, como se puede apreciar en la figura 4.10.

51

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Versin Antigua C18 #pragma config FCMEM = ON Versin nueva C18 #pragma config FCMEN = ON //Fail-Safe Clock Monitor: //Fail-Safe Clock Monitor:

Otro detalle importante a tener en cuenta a la hora de utilizar el archivo configbits.h es el reloj oscilador que monte la tarjeta del proyecto del que se parte en un principio. Como ya se ha comentado con anterioridad, el proyecto que ha servido de base para el presente proyecto, monta un reloj de 20MHz. Esto supone que en el archivo configbits.h se han definido los bits de configuracin del reloj para conseguir la frecuencia necesaria de 48MHz para el bus USB a partir de un reloj oscilador de 20MHz. Es de vital importancia tener en cuenta este hecho ya que de lo contrario no se consigue el necesario sincronismo entre el dispositivo y el host. En el presente proyecto se ha programado el reloj de la forma que expone el capitulo 6 Arquitectura y Hardware robot Hermes en su figura 6.4.

A continuacin se muestra el cdigo que se ha modificado en el archivo configbits.h.

#pragma config PLLDIV = 12 #pragma config CPUDIV = OSC1_PLL2 #pragma config USBDIV = 1 #pragma config FOSC = HSPLL_HS // Oscillator Selection bits: //CPU System Clock Postscaler:

Para hacer las comprobaciones necesarias respecto a estas cuestion se ha de consultar la carpeta doc del compilador C18 tal y como se muestra en la figura 4.11.

52

Captulo 4

EL FIRMWARE USB DEL PIC

Hay que

consultar

el

archivo

hlpPICC18ConfigSet

especificando

el

tipo

de

microcontrolador que se va a utilizar. De esta manera se pueden resolver eventuales problemas a la hora de utilizar el firmware USB, ya que cuestiones de este tipo presentan errores de compilacin y muchas veces son difciles de descubrir.

Figura 4.11 Archivo ayuda configurar bits con MPLAB

53

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

5 PROTOCOLO DE COMUNICACIN I2C


En el presente capitulo se abordan los aspectos ms relevantes del protocolo de comunicacin I2C, utilizado para comunicar el microcontrolador PIC18f4550 de la tarjeta de ultrasonidos con el microcontrolador 16F687 que reside en cada sensor ultrasonidos.

5.1

Introduccin

El bus I2C es un bus de comunicaciones serie. Su nombre viene de Inter-Integrated Circuit (Circuitos Inter-Integrados). La versin 1.0 data del ao 1992 y la versin 2.1 del ao 2000, y su diseador es Philips. La velocidad de transmisin de datos es de 100Kbits por segundo en el modo estndar, aunque tambin permite velocidades de 3.4 Mbit/s. Es un bus muy usado en la industria, principalmente para comunicar microcontroladores y sus perifricos en sistemas empotrados (Embedded Systems). La principal caracterstica de IC es que utiliza dos lneas para transmitir la informacin, una para los datos y otra para la seal de reloj. Tambin es necesaria una tercera lnea, pero esta slo es la seal de referencia o masa. Suele ser habitual una cuarta lnea con tensin TTL para alimentar los diferentes dispositivos.

Figura 5.1 Ejemplo un maestro y tres nodos esclavos

54

Captulo 5

PROTOCOLO COMUNICACIN I2C

Las lneas SCL (Reloj) y SDA (Datos) son drenador abierto, lo que quiere decir que el microcontrolador puede dar un valor lgico cero, pero no puede suministrar el valor alto o 5v, por lo que se necesitan sendas resistencias de pull-up conectadas a la seal de 5v. No es necesario implementar dichas resistencias en cada dispositivo esclavo, solo es necesario dichas resistencias en el maestro. El valor de dichas resistencias no es crtico pudiendo oscilar entre 1K~10K. La lnea SCL es la lnea del reloj. Se utiliza para sincronizar todas las transferencias de datos sobre el bus I2C, mientras que la lnea SDA es la encargada de llevar los datos. El dispositivo maestro inicia la transferencia de datos y adems genera la seal de reloj, pero no es necesario que el maestro sea siempre el mismo dispositivo, esta caracterstica puede asignarse entre los dispositivos que tengan esa capacidad. Esto hace que al bus IC se le denomine bus multimaestro. Los esclavos son los dispositivos que responden a las peticiones del maestro, no pudiendo iniciar una transferencia en ningn caso, sino ha sido requerida por el maestro.

5.2

PROTOCOLO I2C

El PIC 18f4550 posee un mdulo I2C que controla dicho protocolo y su control se explica en detalle en el data sheet 10 del fabricante.

El algoritmo de control de los microcontroladores est creado con el compilador C18. Dicho compilador ofrece una librera que se debe insertar en el programa con la directiva #include <i2c.h>.

En principio dichas libreras manejan el protocolo, pero segn las pruebas de programacin realizadas con dichas funciones no funcionan correctamente con este tipo de sensores. Para solucionar dicho problema se ha recurrido a construir una librera para manejar el bus por perifrico consultando el data sheet del fabricante.

10

http://www.tecnun.es/asignaturas/robots/datasheets/Medidor%20ultrasonico%20SRF02.pdf

55

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se han obtenido los resultados esperados, controlando completamente los ocho sensores de ultrasonidos I2C. En el CD adjunto al proyecto en la carpeta 4.- Manuales\I2C\SRF02 sensor ultrasonidos\Ensamblador\18FXXXX se anexan las libreras en lenguaje ensamblador que han servido de gua para crear dicha librera. Se adjunta a su vez el data sheet del sensor de ultrasonidos SRF02, utilizado en el proyecto.

Esta librera se ha traducido al lenguaje C18 y ha sido introducida en el firmware USB, en el archivo TOOLS.h pudindose exportar a futuros proyectos sin ningn problema.

Cuando el maestro quiere comunicarse con el esclavo, ste debe empezar la comunicacin mediante una secuencia de Start o inicio. Esto hace que los dispositivos esclavos estn alerta a la nueva transaccin que va a empezar y deban estar atentos en caso de que esta secuencia vaya dirigida a ellos. Dicha secuencia es una de las dos secuencias especiales definida para el I2C, siendo la otra la secuencia de Stop o parada. Dichas secuencias marcan el inicio y el fin de una transferencia de datos con el esclavo.

Son consideradas secuencias especiales por que son las nicas secuencias donde se permite el cambio de estado en la lnea SDA mientras la lnea de SCL se encuentra en valor alto. Cuando el dato est siendo transferido, la lnea SDA debe permanecer estable y no cambiar mientras la lnea de reloj est en valor alto. A continuacin se muestran las secuencias especiales de Start y stop.

Figura 5.2 Secuencias de Start y Stop

56

Captulo 5

PROTOCOLO COMUNICACIN I2C

Una vez generada la secuencia de Start, el maestro debe enviar la direccin del dispositivo con el que quiere comunicarse. Cada dispositivo esclavo en el bus dispone de una direccin nica en el bus que le identifica. El esclavo que posee dicha direccin sigue la transferencia mientras que los dems la ignoran en su totalidad y esperan a la siguiente transferencia. Una vez concluida la fase de direccionamiento del esclavo, el maestro enva el nmero de registro del esclavo que quiere escribir o leer. Este registro depende del dispositivo esclavo I2C se utilice, por lo que en cualquier caso se debe consultar el data sheet del fabricante del dispositivo I2C.

Los datos son transferidos en secuencias de 8 bits. Los bits se van depositando en la lnea de datos empezando por el ms significativo, mientras que en la lnea de reloj se da lugar un pulso, tal y como se muestra en la figura 5.3. Por cada 8 bits transferidos, el dispositivo que recibe la informacin devuelve un bit de reconocimiento o Acknowledge ACK, por lo que realmente se dan nueve pulsos de reloj por cada 8 bits de datos.

Si el dispositivo receptor manda un bit ACK, entonces el byte ha sido recibido con xito y est en disposicin de recibir ms datos. Si no enva este bit de reconocimiento indica que no puede aceptar ms datos y el maestro concluye as la transferencia mandando una secuencia de stop.

Figura 5.3 Transferencia en el bus I2C

57

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

5.3

LIBRERIA I2C

En el presente apartado se explican los aspectos que se han tomado en consideracin para la realizacin de la librera I2C. Se explica en detalle los registros especiales del PIC que se han modificado adjuntando a su vez las funciones de dicha librera.

5.3.1

Configuracin del bus I2C

El protocolo I2C, como se ha adelantado en la introduccin del presente capitulo puede funcionar a diferentes velocidades, pero el fabricante de los sensores utilizados en el proyecto aconseja que se configure el bus a 100KHz. Para ello se ha de configurar el bit SMP Slew Rate Control bit del registro SSPSTAT Master Synchronous Serial Port status del PIC, para conseguir que el microcontrolador genere los pulsos de la lnea de reloj a la frecuencia de 100KHz que aconseja el fabricante. A continuacin en la figura 5.4 se muestra una captura de pantalla adquirida con el osciloscopio Tektronix y el software Wavestar, que expone la frecuencia de 100KHz conseguida para el mdulo I2C.

Dicha captura de pantalla es de la coleccin de imgenes de osciloscopio, correspondiente a los ensayos realizados. En este caso se realiz una prueba para comprobar el buen funcionamiento de la lnea de reloj en una transmisin.

Figura 5.4 Frecuencia 100KHz de la lnea SCL del bus I2C

58

Captulo 5

PROTOCOLO COMUNICACIN I2C

El programador debe configurar el registro SSPADD Master Synchronous Serial Port Address register para conseguir dicha frecuencia. Es un valor de recarga para el generador de frecuencia en baudios y se ha de calcular segn el oscilador que disponga el microcontrolador y la ecuacin (1).

En la ecuacin 1 el trmino Fscl son los 100KHz que se deben conseguir y Fosc son los 48MHz del reloj implementado en las tarjetas. En el presente proyecto se ha de configurar dicho registro con el valor 117.

Fscl = (4(SPADD
Fosc

+1)))

Ecuacin (1)

La configuracin del bus I2C concluye con la modificacin del registro SSPCON1 Master Synchronous Serial Port Control register 1. Se debe poner a nivel alto el bit SSPEN Master Synchronous serial Port Enable bit, para habilitar el puerto serie y los pines del SDA y SCL. Dichos pines deben configurarse como entrada y salida respectivamente. Se ha de modificar a su vez el bit Master Synchronous serial Port Mode Select Bits para configurarlo como I2C Master Mode. A continuacin se muestra la funcin de librera creada para configurar el bus I2C.

void I2CIni(void) { SSPSTAT = 0b10000000; SSPADD = 117; SSPCON1 = 0b00101000; } // Bit SMP Velocidad estndar 100KHz // Valor en SSPADD para 100KHz // Mdulo MSSP en ON, modo Master

5.3.2

Secuencia Start y stop

En ambas secuencias se ha de borrar el flag SSPIF Master Synchronous serial Port Interrupt del registro PIR1 Peripheral Interrupt Request register 1 del microcontrolador. Dicho flag se pone a uno lgico cuando la transmisin/recepcin ha sido completada, y debe ponerse a cero por software tal y como lo exige el data sheet del microcontrolador.

59

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En el caso de la secuencia de Start, se ha de poner a valor lgico alto el bit SEN Start Condition Enable, del registro SSPCON2 SSPIF Master Synchronous serial Port Control Register 2 en modo I2C. Esto inicializa los pines SDA y SCL tal y como lo exige el protocolo. A continuacin se muestra la funcin diseada para la secuencia de Start.

void I2CSendStart(void ) { PIR1bits.SSPIF = 0; SSPCON2bits.SEN = 1; while(PIR1bits.SSPIF == 0) { } } // Restaura el flag del mdulo MSSP // Activa secuencia de inicio // Transmisin finalizada?

En el caso de la secuencia de stop, se ha de poner a valor lgico alto el bit PEN Stop Condition Enable, del registro SSPCON2 SSPIF Master Synchronous serial Port Control Register 2 en modo I2C del microcontrolador. Esto inicializa los pines SDA y SCL tal y como lo exige el protocolo. A continuacin se muestra la funcin diseada para la secuencia de Stop.

void I2CSendStop(void ) {PIR1bits.SSPIF = 0; SSPCON2bits.PEN = 1; while(PIR1bits.SSPIF == 0) { } } // Restaura el flag del mdulo MSSP // Activa secuencia de stop // Transmisin finalizada?

Ambas funciones requieren que la transferencia se concluya, por lo que requieren latencia hasta que el flag SSPIF Master Synchronous serial Port Interrupt del registro PIR1 Peripheral Interrupt Request register 1 del microcontrolador se ponga a uno. Esto quiere representar que la transferencia se ha concluido.

60

Captulo 5

PROTOCOLO COMUNICACIN I2C

Estos bucles hacen que el hilo de ejecucin del firmware se detenga en esas esperas, pudiendo no cumplir la frecuencia de refresco de USBTasks. En la programacin de el firmware USB I2C, se ha necesitado modificar el mismo, mediante la inclusin de una interrupcin por desbordamiento de un temporizador en la que se ejecute la funcin USBTasks (Vase funcin refrescoUSB del archivo HermesUSBultrasonic_I2C\user\Hermes.c). Como ya se ha comentado con anterioridad la frecuencia de refresco necesaria para la funcin USBTasks, que mantiene activo el dispositivo en el bus USB, es de 500Hz. Por lo tanto hay que crear la interrupcin que se ejecute y refresque dicha funcin con una frecuencia mayor.

5.3.3

Funciones escritura y lectura

La funcin de lectura del bus I2C es ligeramente ms complicada que las anteriores. Se debe configurar el receptor o maestro, habilitndolo para el modo lectura. Esto se consigue poniendo a uno lgico el bit RCEN Receive Enable Bit del registro especial SSPCON2 Master Synchronous serial Port Control Register I2C. Se restaura el flag del modulo MSSP y se espera a que sean recibidos los 8 bits que enva el esclavo.

unsigned char I2CReadByte(unsigned char fACK) { SSPCON2bits.RCEN = 1; PIR1bits.SSPIF = 0; while(PIR1bits.SSPIF == 0) { } PIR1bits.SSPIF = 0; if(fACK == 0) { SSPCON2bits.ACKDT = 0; // Pone bit ACK a "0" // Restaura el flag del mdulo MSSP // Activa el receptor I2C // Restaura el flag del mdulo MSSP // Recibidos los 8 bits ??

SSPCON2bits.ACKEN = 1; // Activa la secuencia de generacin del bit ACK while(PIR1bits.SSPIF == 0) {} return SSPBUF; }} // Lee el byte recibido // Secuencia ACK finalizada ??

61

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Una vez que han sido recibidos los 8 bits, se pone a cero lgico el flag de transferencia completa y se pasa a la fase de Acknowledge. Si se ha llegado a dicha fase la transferencia se ha realizado con xito y se manda el bit de ACK.

La funcin de escritura requiere la modificacin del registro SSPBUF Master Synchronous serial Port Receive Buffer/Transmit Register. Se ha de escribir en dicho registro el dato de 8 bits que se quiere enviar. Esta funcin al igual que las dems requiere que el receptor mande la seal de Acknowledge que requiere el protocolo. void I2CSendByte(unsigned char data) { PIR1bits.SSPIF = 0; SSPBUF = data; // Restaura el flag del mdulo MSSP // Byte a transmitir pasa al buffer de salida Recibido el bit /ACK ??

while(PIR1bits.SSPIF == 0) { } }

A continuacin se muestran las funciones que se han creado para el manejo de los sensores SRF02. Dichas rutinas se basan en las funciones de la librera creada para su manejo.

Primero se ha de indicar al sensor que comience la medida. Una vez se ha realizado la medida, se debe leer del registro del sensor donde ha almacenado la medida. Segn el fabricante cada sensor necesita en torno a 100 milisegundos para obtener medidas fiables. La rutina empieza con la secuencia de Start que inicia una transferencia en el bus I2C. Una vez ejecutada la secuencia se Start se debe definir la direccin del sensor que se quiere activar. En el data sheet del fabricante vienen definidas las diferentes direcciones de los sensores de ultrasonidos SRF02 que se pueden conectar al bus I2C. Se pueden conectar 16 sensores SRF02 estando condicionado este nmero por el tipo de sensor elegido.

Una vez direccionado al sensor, se le ha de ordenar que empiece una nueva adquisicin. El manual del fabricante explica que se pueden hacer tres tipos de medidas, siendo estas

62

Captulo 5

PROTOCOLO COMUNICACIN I2C

en centmetros, pulgadas y microsegundos. Para ello, el sensor distingue tres tipos de comando diferentes 11 . En la librera creada en el proyecto se ha implementado la medida en centmetros, correspondiente al comando 0x51.

La funcin MakeMeasure, es una funcin para activar un sensor determinado y no tiene argumentos de salida. Esta funcin inicia una medida en centmetros en cualquiera de los ocho sensores de ultrasonidos que se direccione. Esta rutina tiene un entero como argumento de entrada, que es utilizado para direccionar el sensor en cada caso. De esta manera el usuario de la librera debe solo escribir MakeMeasure(1), si quiere iniciar la medida del sensor 1.

A la hora de utilizar dicha funcin, se ha de considerar que el tiempo que necesita el sensor para hacer una medida fiable se ha de implementar fuera de la funcin. Esto se debe implementar con un delay.

void MakeMeasure(int a) { I2CIni(); I2CSendStart();

// inicia la adquisicin del sensor SRF02 // Parmetros del bus I2C (librera propia) // Secuencia de start (librera propia)

// - Eleccin del sensor I2C que queremos activar -------------switch(a) {case 1: I2CSendByte(0xE0); break; case 2: I2CSendByte(0xE2); break; case 3: I2CSendByte(0xE4); break; case 4: I2CSendByte(0xE6); break; case 5: I2CSendByte(0xE8); break; case 6: I2CSendByte(0xEA); break; case 7: I2CSendByte(0xEC); break; case 8: I2CSendByte(0xEE); break;} // -------------------------------------------------------------I2CSendByte(0x00); I2CSendByte(0x51); I2CSendStop(); } // Se le indica que se le va a introducir 1 comando. // Lo encendemos con medida en cm. 0x51 // Fin de la transmisin. Secuencia stop. // Direccion E0 sensor 1 // Direccion E2 sensor 2 // Direccion E4 sensor 3 // Direccion E6 sensor 4 // Direccion E8 sensor 5 // Direccion EA sensor 6 // Direccion EC sensor 7 // Direccion ED sensor 8

11

http://www.tecnun.es/asignaturas/robots/datasheets/Medidor%20ultrasonico%20SRF02.pdf

63

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Una vez se le ha solicitado al sensor iniciar una medida nueva, se ha de esperar el tiempo especificado anteriormente. Una vez concluido dicho tiempo se puede leer el registro donde el sensor almacena la medida.

Para ello la librera tiene la funcin Get_usMeasure. Dicha funcin tiene un entero como argumento de entrada para discernir entre los diferentes sensores, y su valor de salida es el valor del registro del sensor, de 8 bits de tamao.

unsigned char Get_usMeasure(int a) { int direccion=0; I2CSendStart(); // Iniciamos el bus I2C

// - Eleccin del sensor I2C que queremos activar Direcciones pares -------------switch(a) {case 1: I2CSendByte(0xE0); break; case 2: I2CSendByte(0xE2); break; case 3: I2CSendByte(0xE4); break; case 4: I2CSendByte(0xE6); break; case 5: I2CSendByte(0xE8); break; case 6: I2CSendByte(0xEA); break; case 7: I2CSendByte(0xEC); break; case 8: I2CSendByte(0xEE); break;} // -------------------------------------------------------------I2CSendByte(direccion); I2CSendByte(0x02); I2CSendStop(); I2CSendStart(); direccion++; I2CSendByte(direccion); I2CReadByte(0); return I2CReadByte(1); } // Direccionamiento del sensor // Inicia lectura del registro 0x02 del sensor // Protocolo del sensor (Fabricante) // Protocolo del sensor (Fabricante) // Lectura del bus. Direccion impar // Direccion E0 sensor 1 // Direccion E2 sensor 2 // Direccion E4 sensor 3 // Direccion E6 sensor 4 // Direccion E8 sensor 5 // Direccion EA sensor 6 // Direccion EC sensor 7 // Direccion ED sensor 8

64

Captulo 5

PROTOCOLO COMUNICACIN I2C

Una vez se ha direccionado el sensor, se le ha de indicar el registro que se quiere leer. Concretamente en este tipo de sensor se ha de leer el registro 0x02. Una vez que se le ha indicado el registro, se ha de crear una secuencia de stop y restart. Esta forma de trabajar la exige el protocolo del fabricante.

Una vez se ha llegado a este punto se ha de leer del sensor. Para leer del sensor se ha de cambiar la direccin del sensor, por su direccin impar. Para ello se ha de sumar uno a la direccin par de cada sensor, por ejemplo 0xE0, en su valor de direccin impar 0XE1. Para finalizar se retorna el valor del registro ledo del sensor.

65

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

6 ARQUITECTURA Y HARDWARE ROBOT HERMES


En el presente capitulo se presenta la arquitectura desarrollada en el robot Hermes as como un anlisis del hardware necesario para llevarlo a cabo. Se pueden consultar tanto los esquemticos como los layout de cada tarjeta en el CD adjunto al proyecto en la carpeta Esquemticos.

6.1

ARQUITECTURA

La primera decisin importante, que condiciona todo el proyecto, es la eleccin de la arquitectura a utilizar. El sistema, bsicamente est formado por un elemento maestro que gobierna cuatro dispositivos esclavo. Las labores de maestro del sistema las hace un PC, mientras que los esclavos son cuatro tarjetas independientes, cada una de ellas controlada por un microcontrolador. Todo el sistema est interconectado por medio del bus USB y a travs del protocolo USB creado en el presente proyecto para tal efecto.

Figura 6.1 Arquitectura robot Hermes 66

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

El sistema globalmente se puede simplificar en un dispositivo maestro que controla una serie de elementos esclavo que tienen una funcin especfica. Las funciones implementadas pueden clasificarse de la siguiente manera:

Adquisicin distancias con sensores infrarrojos corto alcance. Adquisicin distancias con sensores infrarrojos largo alcance. Adquisicin de medidas con sensores ultrasonidos I2C. Gobierno de los 3 servomotores.

La razn fundamental de utilizar esta arquitectura con varios microprocesadores, es la de tener un sistema modular. De esta manera se logra tener agrupados los diferentes sensores por tipos y las salidas a los motores en diferentes tarjetas, creando as funciones USB diferenciadas. Esta eleccin dota al sistema de una serie de ventajas que no hay que pasar por alto.

La principal ventaja con la que se justifica esta eleccin es la de otorgar al sistema una mayor velocidad de procesamiento. Cada tarjeta cumple la funcin para la que fue creado y adems vigila el bus USB para atender las peticiones del maestro. De esta manera se consigue realizar el muestreo de los sensores a frecuencias ms altas. En el captulo 7 Ensayos se muestran las frecuencias de muestreo conseguidas.

La segunda razn, no por ello menos importante, es la de facilidad de arreglo de averas. Gracias a este sistema por segmentos, se pueden arreglar averas en las tarjetas, sin tener que modificar todo el sistema.

En cuanto a la programacin de los esclavos, stos requieren algoritmos de control en el PIC de complejidad menor. Dividir el sistema en sub-problemas o funciones es una buena estrategia para resolver el problema global. En este sistema como en muchos otros encaja la frase clebre de Julio Csar Divide et vinces", que significa "divide y vencers".

Una cuarta razn reside en la posibilidad de trabajo en condiciones mermadas. En caso de que alguna de las tarjetas se vea desconfigurada y el sistema operativo

67

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

no la detecte, ya sea bien por una avera u otro factor externo, el algoritmo de control del PC, siendo capaz de determinar que tarjetas se encuentran conectadas, puede adoptar un modo de control especfico. En el captulo 8. Conclusiones y lneas futuras se muestra una reflexin ms detallada de las posibles direcciones a tomar en la programacin del algoritmo del maestro en torno a este concepto.

6.1.1

Arquitectura Linux Embedded System

El maestro tiene una arquitectura Linux Embedded, que es un sistema que consta bsicamente de un PC corriendo bajo el mando del sistema operativo Linux. Concretamente su distribucin es Ubuntu Feisty Fawn 7.04. Dicho sistema, como es de sobra conocido, es una distribucin Open Source o cdigo abierto.

Las razones fundamentales en las que se apoya la decisin de utilizar dicho sistema operativo son las siguientes:

Se pueden conseguir en la red distribuciones gratuitas de dicho sistema operativo, teniendo multitud de software libre y sin coste alguno. Dicha razn es fundamental en este proyecto, ya que la licencia de los sistemas operativos de Microsoft y Apple rondan los 500 .

Necesita ordenadores menos potentes para conseguir buenos rendimientos, lo que abarata el sistema sensiblemente.

Gracias a su sistema de archivos y administrador root, no requiere de antivirus.

El PC utilizado en el proyecto es un placa base Via EPIA-EN 12000 Mini-Itx provista del procesador VIA EDEN chipset C7 y Bus V4. Combinan un rendimiento extraordinario, baja temperatura y un funcionamiento silencioso, creando un sistema de reducidas dimensiones preparado para el uso como sistema embebido.

68

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Figura 6.2 Placa VIA EPIA-EN1200

Basadas en la probada arquitectura CoolStream y la avanzada tecnologa de 90nm, el procesador VIA C7 ofrece un mximo rendimiento por vatio y emplea el nuevo bus V4 a 400MHz, siendo totalmente compatible con sistemas operativos Microsoft Windows y Linux.

Tiene un procesador que funciona a una frecuencia de 1.2GHz, con un modulo de memoria RAM DDR de 1GB de capacidad, con un bus a 400MHz. Se dispone de un lector compact flash, con una memoria flash de 4GB de disco duro.

En el apartado conexiones, respecto al presente proyecto, se puede destacar un puerto VGA para la conexin de la pantalla que dispone el robot. Un puerto serial con el que se han hecho los ensayos del algoritmo de control del maestro. Cuatro puertos USB 2.0 en los cuales se conectan las diferentes tarjetas esclavas.

6.1.2

El microcontrolador PIC18F4550

Como ya se ha comentado el sistema a nivel de hardware consta de cuatro tarjetas cada una de ellas gobernadas por un microcontrolador y toda la circuitera necesaria para su funcionamiento. En el CD adjunto al proyecto, en la carpeta 9. Esquemticos, se muestra la diferente circuitera empleada en cada tarjeta.

69

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se han utilizado microcontroladores PIC(Peripheral Interface Controller) de la serie 18F4550 del fabricante Microchip. El PIC 18F4550 I/P utilizado en el proyecto es un microcontrolador de propsito general, verstil y econmico. Pertenece a la popular familia de controladores PICmicro de la empresa norteamericana Microchip cuya sede se ubica en Chandler, Arizona (USA).

En la figura 6.3

se muestra una foto real del microcontrolador, en su versin de

empaquetado DIP40 con su Pinout.

Figura 6.3 PIC 18F4550 Dip 40

El PIC18F4550 es un microcontrolador con arquitectura Harvard de gama alta con mdulos de comunicacin y protocolos avanzados (USB, Ethernet, Zigbee, USART, I2C, y SPI). Presenta 35 pines de entrada/salida digital (TTL) capaces de suministrar hasta 25mA por pin.

Posee tecnologa nanoWatt que reduce el consumo durante la operacin. Para ello maneja diferentes modos de trabajo y modos de espera que optimizan el consumo. El PIC 18F4550 ofrece un total de 7 modos de operacin para obtener una gestin ms eficiente del consumo de corriente

Es un microcontrolador de 8 bits del tipo RISC (Reduced Instruction Set Computer) que tiene instrucciones de tamao fijo y presentado en un reducido nmero de formatos. Este

70

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

tipo de controladores permiten la segmentacin y el paralelismo en la ejecucin de instrucciones y reducen los accesos a memoria.

Tiene una memoria de programa Flash mejorada de 32KB (0000h 7FFFh), lo que permite 16384 instrucciones simples. Posee una memoria de datos de 2KB (8 bancos de 256 bytes) y una memoria EEPROM de 256 Bytes. La memoria RAM de datos se compone de registros de propsito general (GPRs) y de registros de funcin especial (SFRs).

La memoria de datos en el PIC est implementada como SRAM, que es el acrnimo de Static Random Access Memory (Memoria Esttica de Acceso Aleatorio), un tipo de memoria RAM. Es una memoria voltil cuya informacin se pierde cuando se corta el suministro de corriente. Cada registro en la memoria de datos tiene una direccin de 12 bits, que permite definir 4 KB de memoria.

Una de las caractersticas de este microcontrolador es que es uno de los PICs que viene con soporte nativo para USB, lo que quiere decir que incluyen un controlador USB interno que ya brinda pines de salida para conectar directamente un conector USB y el cable hacia el PC. Soporta los 4 modos de transferencia Control, Interrupt, Iscrona y Bulk descritos en el captulo 3 de descripcin del bus USB.

Soporta cristales y osciladores de cuarzo de varias frecuencias de entrada y tiene postscaler de manera que el procesador puede trabajar a la frecuencia de 48Mhz, necesaria para soportar el USB a High-Speed, independientemente del oscilador que se conecte. En la figura 6.4 se muestra la configuracin del oscilador diseada para tal efecto.

Para configurar de esta manera el reloj del microcontrolador se han tenido que programar por software los bits de configuracin PLLDIV (PLL Prescaler), CPUDIV (PLL Postscaler), USBDIV, FSEN, FOSC e IDLEN.

71

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 6.4 Diagrama del reloj

6.2

HARDWARE

En el presente apartado se explica el hardware necesario para implementar los esclavos del sistema as como los circuitos electrnicos de alimentacin. El sistema consta de una tarjeta de alimentacin que transforma los niveles de tensin de la batera en los niveles necesarios por los microcontroladores, drivers y motores.

72

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Uno de los cuatro esclavos se encarga de gobernar los drivers de los motores y requiere de una placa intermedia en la que se implementa la diferente circuitera necesaria a base de amplificadores operacionales para su gobierno. El sistema concluye con las otras tres tarjetas esclavas, tarjetas de adquisicin de datos encargadas de la sensorizacin del entorno que rodea al robot.

6.2.1

Circuitera del microcontrolador

A continuacin se explica la circuitera comn a las tarjetas esclavos que poseen un microcontrolador. Se ha diseado cada tarjeta con un microcontrolador PIC18F4550 con la circuitera habitual y necesaria para su funcionamiento. Entre esta circuitera necesaria para el microcontrolador se encuentra el oscilador de cuarzo (48Mhz), alimentacin (5V), condensadores de desacoplo (100nF) y circuito de reset.

En la figura 6.5 se muestra el circuito necesario para el oscilador y una foto del modelo (IQX0-350 48MHz) utilizado en el proyecto.

Figura 6.5 Circuito Oscilador IQX0-350C 48MHz

Una vez se ha montado la placa el reloj oscilador hay que chequearlo para comprobar su funcionamiento. A continuacin, en la figura 6.6 se muestra una captura de pantalla del osciloscopio TDS220 de la casa Tektronix y el software Wavestar.

73

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 6.6 Circuito reloj oscilador

En la figura anterior se puede apreciar que la salida del oscilador que es llevada a la patilla OSC1 del PIC. Se determina que el periodo de oscilacin es de 20.5 nanosegundos, lo que corresponde aproximadamente a una frecuencia de reloj de 48MHz por lo que de esta manera se puede afirmar que el componente funciona correctamente.

En cuanto a los 2 condensadores de desacoplo se puede comentar que sus valores ms habituales son de 0.1uF y del tipo cermico. La funcin ms importantes de estos condensadores de desacoplo es la de servir de filtro al microcontrolador frente a las interferencias ya que al ser del tipo digital, stas pueden alterar su funcionamiento normal al variar el valor en algn registro.

Se conoce como reset a la puesta en condiciones iniciales de un sistema. Cuando se ejecuta un reset en el microcontrolador se producen dos acciones importantes.

El contador de programa se vuelve a colocar en el principio del programa. Los registros modificados vuelven a su estado normal.

74

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

El circuito de Reset se debe disear para que en la fase de encendido de la tarjeta se resetee el microcontrolador. En el estado inicial el condensador de 1uF se encuentra descargado, aplicando al PIC una seal lgica de nivel bajo.

Figura 6.7 Circuito reset

Cuando se alimenta la tarjeta al encontrarse el condensador descargado, se aplica un cero lgico a la patilla Master Clear resetendose el microcontrolador. Una vez se carga el condensador a travs de la resistencia de 10K desaparece la seal cero para

imponerse los 5v, con lo que desaparece la condicin de reset. En la tarjeta USB Demo Board creado en el proyecto se ha implementado un pulsador de reset en paralelo con el condensador, que descarga el mismo aplicando la condicin de reset.

Los dispositivos USB pueden ser alimentados a travs del bus USB o de una fuente de tensin externa. En este caso ha sido imperativo tomar la decisin, de que las tarjetas tengan alimentacin externa debido a que el bus USB, segn las especificaciones solo puede asegurar 100mA. En las pruebas de consumos de la tarjeta de Infrarrojos se han obtenido consumos de corriente de 400mA en rgimen normal y 380mA en modo suspensin.

Se ha implementado en cada tarjeta un conector para la programacin ICD2 (Ver anexo software 1.1.3 In Circuit Debugger). Para implementar esta funcin se utilizan 2 pines del microcontrolador. En el presente proyecto los pines necesario no han sido un factor limitante, en gran medida por la arquitectura distribuida de cuatro PICs. En el hipottico

75

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

caso de escasez de pines se puede optar por la solucin de implementar jumpers para reutilizar dichos pines de programacin.

Se han implementado una serie de leds para la visualizacin de tarjeta alimentada y del estado del dispositivo en el bus USB. Estos leds han resultado de vital importancia en los procesos iniciales de programacin y debugger del firmware por lo que se recomienda encarecidamente la implementacin de los mismos en cualquier proyecto USB, aunque no son imperativamente necesarios.

Estos leds de estado son utilizados por el firmware, sealizando el estado del dispositivo en el bus, cuestin que fue aprovechada en las siempre complicadas fases de configuracin y puesta en marcha inicial. Vase capitulo.6 Software de control Robot Hermes para ms informacin al respecto.

Figura 6.8 leds de estado USB y alimentacin

En el apartado de comunicaciones se han diseado las tarjetas con conexin USB, I2C y USART. El modulo de comunicacin serie USART no se ha utilizado en el presente proyecto, aun as se ha implementado la circuitera necesaria para posibles futuras ampliaciones. Dicho circuito consta de un conector Molex 4 pines y un condensador de filtrado de alimentacin, por lo que su coste es despreciable, frente a las posibilidades de ampliacin.

76

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Figura 6.9 Circuitera bus Serie

Se ha implementado en todas las tarjetas un conector I2C excepto en la tarjeta de ultrasonidos que dispone de nueve conectores, ocho de uso en el proyecto, uno para posibles ampliaciones. Dicho conector tiene la finalidad de llevar la seal de alimentacin para los sensores SRF02, adems de llevar al sensor la lnea de datos y de reloj de dicho protocolo. Las dos primeras lneas son drenador abierto que disponen de dos estados, cero lgico o alta impedancia, por lo que necesitan resistencias de pull-up. Estas resistencias solo tienen que implementarse en el maestro y no deben repetirse ms aunque se coloquen ms conectores.

Figura 6.10 Circuitera bus I2C .

77

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

A continuacin se muestra en la figura 6.11, la circuitera USB implementada en todas las tarjetas. Las conexiones serie estndar no aseguran la conexin o desconexin con el ordenador encendido, mientras el bus USB permite la conexin en caliente, traducido del ingls hot-plug, que es la capacidad que tienen los perifricos de poder enchufarse o desenchufarse al ordenador, sin apagar el mismo y funcionar correctamente.

Figura 6.11 Circuitera USB

Para lograr esta caracterstica, se debe disear a nivel de hardware un pin USBC en el PIC, concretamente el pin PortD3, que es utilizado por el firmware para detectar el dispositivo en el bus. Cuando el dispositivo est conectado al bus, la seal USBC que llega al microcontrolador tiene un nivel alto, debido a la seal de 5V que porta el bus. Cuando el dispositivo se encuentra desconectado del puerto, esta entrada digital al PIC se encuentra en su nivel lgico bajo. Vase capitulo 7 Software de control Robot Hermes para ms informacin al respecto.

El estndar USB determina que se han de implementar resistencias de pull-up a las lneas diferenciales D+ o D-, segn sea la velocidad del dispositivo. Tal y como muestra la figura 6.12, se pueden implementar dichas resistencias externamente o utilizarse las internas del PIC. A su vez se puede implementar una fuente de tensin constante de 3.3v o utilizar el regulador interno.

En la carpeta system/usb/usbdrv del firmware USB programado en el microcontrolador se encuentra un archivo que se designa usbdrv.h. En este archivo se encuentra una macro

78

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

definida como mInitializeUSBDriver(), el cual es inicializado en la puesta en marcha del PIC. En esta funcin, entre otras cosas, se configura un registro llamado UCFG.

Figura 6.12 Modulo USB PIC18F4550

Este registro se configura a su vez en el archivo usbcfg.h de la carpeta autofiles, de la siguiente manera:

UCFG_VAL

_PUEN|_TRINT|_FS|MODE_PP

En el propio archivo usbdrv.h se definen las siguientes macros:

#define _FS #define _PUEN #define _TRINT

0x04 0x10 0x00

// Use Full-Speed USB Mode // Use internal pull-up resistor // Use internal transceiver

79

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Con esta configuracin definida por software, en el presente proyecto se definen las tarjetas esclavas como perifricos full speed. Se utilizan resistencias de pull-up internas y regulador de tensin interno, por esta razn no es necesario implementar en los microcontroladores ninguna circuitera adicional al conector USB. Las Universal Serial Bus Specifications 12 recomiendan el uso de conectores USB tipo B en los dispositivos esclavo, mientras que establece como norma los conectores tipo A para el host o Maestro PC. Esto debe cumplirse si se pretende comerciar y hacer negocio con los dispositivos que se desarrollen. Evidentemente el robot Hermes no tiene un fin comercial, por lo que se decidi poner los conectores tipo A en las tarjetas. En la figura 6.13 se muestra el conector hembra tipo A utilizado en las tarjetas.

Figura 6.13 Conector tipo A

6.2.2

Tarjeta de alimentacin

Tanto el esquemtico como el layout resultante de la tarjeta de alimentacin pueden consultarse en el CD adjunto al proyecto, en la carpeta 9 Esquemticos. Dicha tarjeta recoge los 24v de las bateras y los adeca para la alimentacin de las tarjetas, los motores y sus drivers, el ordenador y la pantalla tctil. Para ello, tal y como se puede apreciar en los esquemticos utiliza tres reguladores de tensin.

El primero de ellos convierte la seal de 24v en una seal de 5v. Dicho regulador es un 7805, cuyo data sheet puede consultarse en la carpeta 4 manuales/Data sheets del CD adjunto al proyecto. Se le han introducido condensadores de filtro de valor 100nF, que reducen su sensibilidad frente a las interferencias. A su vez se han implementado dos
12

http://www.usb.org/developers/docs/

80

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

condensadores electrolticos, a la entrada y salida del regulador para estabilizar dichas tensiones.

Dicha tarjeta dispone de otros dos reguladores de tensin, con los necesarios condensadores de filtro y estabilizacin, para conseguir tensiones de +/-15V. La tarjeta de alimentacin concluye con los habituales conectores Molex, para su fcil conexin. A continuacin en la figura 6.14, se muestra una captura de pantalla realizada con el software PovRay, a travs de las libreras de Eagle 3D.

Figura 6.14 Tarjeta de alimentacin

6.2.3

Tarjeta drivers motores

Tanto el esquemtico como el layout resultante de las tarjetas de motores pueden consultarse en el CD adjunto al proyecto, en la carpeta 9 Esquemticos. Este esclavo lo conforman dos tarjetas, una compuesta por el microcontrolador con toda la circuitera comn anteriormente descrita y una tarjeta de acondicionamiento de la seal hacia los drivers de los motores.

81

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En ambas tarjetas se han implementado conectores tipo Molex, de modo que mediante cable quedan conectadas la tarjeta esclava que contiene el PIC y la tarjeta de acondicionamiento de seal. A continuacin en la figura 6.15, se muestra un diagrama que resume la arquitectura de la tarjeta motores-amplificadores-drivers.

Figura 6.15 Tarjeta referencia motores

La tarjeta de amplificadores operacionales tiene como un objetivo la de adecuar tanto la seal de referencia PWM del PIC para el driver del motor como las seales de retroalimentacin provenientes del driver. Esto se resuelve con un amplificador operacional en configuracin restador. La referencia se compara con una tensin referencia implementada en la tarjeta a travs de un potencimetro. Vase Signal reference en los esquemticos de la tarjeta Hermes OA.

Dicho amplificador convierte la seal pulsante habitual PWM de valor de tensin media determinado, en su valor continuo sin rizado. sta salida se aplica como referencia del driver a travs de un conector. En la figura 6.16 se muestra la configuracin utilizada para la referencia de control del driver.

82

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Figura 6.16 Referencia de control para el driver de un motor

El driver utilizado ofrece dos seales en tensin proporcional que pueden ser utilizadas para la captacin del rgimen de trabajo de los motores. Concretamente se puede obtener la velocidad y corriente del motor. Las seales del driver, se hacen pasar por un amplificador operacional en configuracin sumador no inversor, que adecuan estas seales de retroalimentacin. El potencimetro R3 vara la ganancia del amplificador, mientras que el potencimetro R1 ajusta la sensibilidad de la seal realimentada.

1 = 1 +

1 1+2 + 1+2 2
3 2 1

Ecuacin 2

Figura 6.17 Configuracin A.O. retroalimentaciones

83

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se puede apreciar en la figura 6.19 que la tarjeta de amplificadores tiene muchos potencimetros y recargar la tarjeta del PIC no compensa, frente al gasto incurrido en placa fotosensible. Esta es la razn por la que se haya diseado en dos tarjetas.

Figura 6.18 Tarjeta Hermes drivers Motores

Figura 6.19 Tarjeta Hermes Amplificadores operacionales

84

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

6.2.4

Tarjeta de infrarrojos corto/largo alcance

El esquemtico realizado para la tarjeta de infrarrojos corto/largo alcance se puede consultar en el CD adjunto al proyecto, en la carpeta 9 Esquemticos. Estas dos tarjetas son exactamente iguales, siendo el tipo de sensor utilizado su nica diferencia.

Como ya se ha comentado con anterioridad este tipo de tarjeta gobernar ocho sensores de infrarrojos. El circuito necesario es el mismo para ambas tarjetas, y utiliza 8 canales analgico-digitales del PIC. Se utilizan los ocho primeros canales del microcontrolador PortA(0~3 y 5) y PortE(0~2).

El microcontrolador PIC18F4550 dip40 utilizado tiene 13 entradas al modulo ADC. Se trata de una modulo que te permite introducir seales analgicas y convertirlas en su correspondiente representacin binaria de 10bits.

Figura 6.20 Tarjeta infrarrojos

85

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

La salida del sensor, como se comenta en ms detalle en el sub apartado 6.2.6 sensores, es una salida en tensin en funcin de la distancia medida. Esta es la razn por la cual estas salidas de cada sensor han de introducirse en el convertidor Analgico-digital del microcontrolador.

Esta circuitera no es ms que un conector de tipo MOLEX 3 pines comnmente conocidos como conectores poste para facilitar la colocacin del cable tambin creado para el sensor. Este conector alimenta el sensor con 5v y con un condensador electroltico de filtro de 1uF.

Figura 6.21 Conector Molex 3G

6.2.5

Tarjeta ultrasonidos I2C

Tanto el esquemtico como el layout resultante de la tarjeta de ultrasonidos pueden consultarse en el CD adjunto al proyecto, en la carpeta 9 Esquemticos. Esta tarjeta se encarga de controlar ocho sensores de ultrasonidos que soportan el protocolo I2C.

Dicho protocolo requiere nicamente dos lneas del PIC por lo que sobran muchas patillas del microcontrolador. Dicha tarjeta posee un conector Molex8G con los canales analgicos para hipotticas ampliaciones. A su vez se ha implementado un canal analgico para detectar el nivel de batera.

86

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Figura 6.22 Tarjeta ultrasonidos

6.2.6

Sensores infrarrojos de corto alcance GP2D12

La tarjeta de infrarrojos corto alcance tiene como objetivos principales el atender al USB y adquirir la lectura de 8 sensores de medida de distancia GP2D12 de la casa Sharp. En el CD adjunto, en la carpeta 4.- Manuales\Sensores Infrarrojos se adjuntan los data sheets de los dos tipos de sensores de infrarrojos utilizados en el proyecto.

Figura 6.23 Sensor GP2D12

87

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

La familia de sensores Sharp GP2Dxx es una de las ms utilizadas tanto en robtica mvil casera como en el mbito de investigacin debido principalmente a su facilidad de integracin y su bajo coste.

Son dispositivos de reflexin por infrarrojos con medidor de distancias proporcional al ngulo de recepcin del haz de luz que incide en un sensor lineal integrado. A continuacin en la figura 6.24, se muestra una figura del sensor GP2D12.

Figura 6.24 Principio operacin Sensor GP2D12

El dispositivo emite luz infrarroja por medio de un led emisor de infrarrojos. Esta luz pasa a travs de una lente que concentra los rayos de luz formando un nico rayo. La luz infrarroja concentrada se proyecta en lnea recta y cuando encuentra un obstculo reflectante rebota y retorna con cierto ngulo de inclinacin dependiendo de la distancia. La luz que retorna es concentrada por otra lente, incidiendo en un nico punto del sensor de luz infrarroja en la parte receptora del dispositivo.

El funcionamiento de este dispositivo se basa en el mtodo de triangulacin utilizando un pequeo Sensor Detector de Posicin (PSD) lineal para determinar la distancia o la presencia de los objetos dentro de su campo de visin. Bsicamente su modo de funcionamiento consiste en la emisin de un pulso de luz infrarroja, que se transmite a travs de su campo de visn que se refleja contra un objeto o que por el contrario no lo hace. Si no encuentra ningn obstculo, el haz de luz no se refleja y en la lectura

88

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

realizada se indica que no hay ningn obstculo. En el caso de encontrar un obstculo el haz de luz infrarroja se refleja y crea un triangulo formado por el emisor, el punto de reflexin (obstculo) y el detector.

La informacin de la distancia se extrae midiendo el ngulo con que incide el haz de luz. Si el ngulo es grande, entonces el objeto est cerca, por que el triangulo es ancho. Si el ngulo es pequeo, entonces el objeto est lejos, por que el triangulo formado es estrecho. Por lo tanto, si el ngulo es pequeo, quiere decir que el objeto est lejos, porque el triangulo es largo y delgado. Este funcionamiento se puede apreciar en la figura 6.24. Descripcin de uso del GP2D12:

El rango de trabajo del sensor de infrarrojos de corta distancia GP2D12 es de 10 a 80cm. Entre estos lmites el sensor da una tensin entre 2,4~0,4V respectivamente. Este

sensor no es lineal, lo que implica se tenga que definir una tabla de calibracin para su uso en el algoritmo de control.

Se pueden adoptar diferentes estrategias para solucionar esta falta de linealidad. Se puede utilizar la tabla de calibracin en el firmware del PIC y dar los valores convertidos a cm, o utilizar la tabla de calibracin en el maestro. Respecto a esta cuestin, en el presente proyecto se ha decido crear una grfica de calibracin del sensor para que sea utilizada por el maestro. (Vase Anejo 2.4 Ensayos). La razn fundamental que apoya esta decisin es la capacidad de procesamiento del PIC, que es sensiblemente inferior a la del maestro, por lo que cuanto ms aliviado est el microcontrolador mejor. Esta estrategia de trabajo apoya la decisin inicial del proyecto, de sistema de control distribuido.

6.2.7

Sensores infrarrojos de largo alcance GP2Y0A02YK

Los sensores infrarrojos de larga distancia que se utilizarn en Hermes sern los GP2Y0A02YK de Sharp. (Vase carpeta CD adjunto carpeta 4.- Manuales\Sensores Infrarrojos).

89

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 6.25 Sensor GP2Y0A02YK

El funcionamiento de los sensores infrarrojos de larga distancia es anlogo a los de corta distancia. La diferencia es que los sensores infrarrojos de larga distancia tienen un rango de 20 a 150cm.

A continuacin se exponen unas capturas de pantalla del software de diseo ProEngineer donde se evidencian las posiciones de los sensores de infrarrojos de corto y largo alcance en el robot Hermes. Esta informacin ha sido brindada por el alumno y tambin proyectando D. Igor Garca de Cortzar Poignon, proveniente de su proyecto de diseo y fabricacin del robot Hermes. Los elementos cuadrados rojos representan los sensores GP2Y0A02YK, mientras que los elementos cuadrados verdes representan los sensores GP2D12.

Figura 6.26 Ubicacin sensores infrarrojos de corta y larga distancia

90

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

El algoritmo de control en el host PC o maestro debe tener en consideracin las diferencias entre el sensor GP2D12 (Corto alcance) y el sensor GP2Y0A02YK (Largo alcance). A continuacin se muestran las diferentes grficas que definen el comportamiento de los sensores en cuestin. (Vase Anejo 2.4 Ensayos).

Figura 6.27 Calibracin Sensor GP2D12/GP2Y0A02YK

El data sheet del fabricante aconseja tomar las siguientes consideraciones sobre el uso del sensor GP2D12/ GP2Y0A02YK.

Las lentes del dispositivo deben de estar siempre limpias, no utilizar para su limpieza agua o aceite.

Cuando la superficie del detector recibe la luz directa del sol o de una lmpara de tungsteno, puede darse el caso de que no se pueda medir la distancia. Tener esto en cuenta para que el detector no reciba la luz directa de una fuente de luz potente.

Para estabilizar la tensin de alimentacin del dispositivo, se recomienda conectar un condensador de 10mF entre VCC y GND cerca del GP2D12.

91

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

6.2.8

Sensores ultrasonidos SRF02

El SRF02 es un medidor ultrasnico de distancias (sonar), que emplea un nico transductor y se presenta en una placa de reducidas dimensiones. Acepta comunicaciones I2C y serie. Cada sensor tiene su propia direccin interna de identificacin, aunque esta se puede cambiar de forma que se pueden tener hasta 16 mdulos SRF02 en el mismo bus, ya sea serie o I2C. De esta manera se satisfacen las especificaciones del proyecto ya que se han de implementar ocho sensores de ultrasonidos para abarcar todo el campo de visin necesario por el robot.

El rango de operacin es de 15 cm hasta 6 m. Las medidas pueden ser en centmetros, pulgadas o microsegundos. La alimentacin es de 5v y el consumo medio de 4mA. Se puede encontrar el data-sheet del fabricante, en el CD adjunto, en la carpeta 4 Manuales\I2C con los comandos que se deben adoptar para su configuracin.

Figura 6.28 Sensor SRF02

En el presente proyecto se utilizan dichos sensores en modo I2C, para que el controlador los maneje con su modulo MSSP Master Synchronous Serial Port Module que se explica con ms detalle en el captulo 5 Protocolo comunicacin I2C.

92

Captulo 6

ARQUITECTURA Y HARDWARE ROBOT HERMES

Figura 6.29 Conexin Sensor SRF02 Para seleccionar el modo I2C se debe dejar sin conectar el Pin Modo del SRF02. El Pin SDA corresponde a la seal de datos y el Pin SCL a la seal de reloj. Ambas seales se deben polarizar a +5Vcc a travs de dos resistencias de polarizacin positiva o pull-up que normalmente se encuentran en el circuito maestro del bus I2C, que controla los dispositivos I2C esclavos. Esto quiere decir que solo son necesarias dos resistencias en todo el bus, no dos por cada circuito.

Figura 6.30 Ubicacin sensores ultrasonidos

93

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

7 SOFTWARE DE CONTROL ROBOT HERMES


En el presente captulo se desgranan los aspectos ms relevantes del software desarrollado en el proyecto. Se ha creado una aplicacin en Visual Basic, que se comunica con las diferentes tarjetas a travs de un protocolo USB.

7.1

Aplicacin Visual Basic

En el presente apartado se describe el manual de uso de la aplicacin cliente en Visual Basic. Se explica a su vez, el cdigo realizado para crear la aplicacin. Este programa tiene como aplicacin principal, el chequeo y desarrollo de la comunicacin USB en las tarjetas del robot Hermes. Como objetivo secundario, no menos importante ha sido la comprobacin de la correcta comunicacin bidireccional entre el PC y las tarjetas en las fases iniciales de depuracin.

7.1.1

Manual de usuario Hermes USB Check Application v1.0

El presenta apartado tiene como objetivo servir de gua de uso al usuario de la aplicacin. La aplicacin est diseada para funcionar con las tarjetas siguientes configuradas de la siguiente manera:

Tarjeta USB Demo Board: COM5 Tarjeta USB Infrarrojos Corto Alcance: COM6 Tarjeta USB Infrarrojos Largo Alcance: COM7 Tarjeta USB Ultrasonidos I2C: COM8

Se ha tratado de crear un programa sencillo e intuitivo de usar, en el que se ha tratado de ocultar la complejidad en el cdigo.

94

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

Figura 7.1 Cabecera aplicacin cliente La cabecera presenta el software creado, que ha sido bautizado como Hermes USB Check Application. Como fondo de la ventana se exhibe una foto de una estatua del dios griego Hermes. Para avanzar en el contenido de la aplicacin se dispone de dos botones de comandos en la parte inferior izquierda de la ventana, concretamente el botn Aceptar y Salir. Si se interacta con el botn de salir, se pasa a una ventana de aceptacin de salir, que se superpone a la ventana principal de cabecera. La ventana de cabecera pasa a un segundo plano quedando inactiva. En la figura 7.2 se muestra la ventana que se superpone.

95

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 7.2 Salir

Si se clica el botn de cancelar se elimina la ventana de salir y se vuelve a la ventana principal, que pasa a un primer plano quedando como ventana activa. Si se pulsa el botn de aceptar, se sale de la aplicacin.

De vuelta a la ventana principal de la aplicacin, si se interacta con el botn de aceptar, se pasa a una ventana intermedia con una barra de progreso. El tiempo que transcurre en esta ventana se aprovecha para detectar, que tarjetas estn conectadas al puerto USB. De esta manera la aplicacin presenta la ventana principal de una forma dinmica, dependiendo de las tarjetas que se hayan conectado.

96

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

Figura 7.3 Ventana cargando

Una vez se ha cargado la aplicacin se entra en la ventana principal del programa desarrollado. En la figura 7.4 se muestra dicha ventana principal de aplicacin. Presenta un formato Tabstrip tpico de las aplicaciones Visual Basic. Lo compone un elemento de cuatro etiquetas, una para cada tarjeta conectada a la aplicacin. Se muestra personalizada cada etiqueta, con la versin de tarjeta est conectada. Si no hay ninguna tarjeta conectada se muestra el mensaje COM Not Available en la solapa.

Presenta un Status Bar en la parte inferior de la aplicacin. Lo componen seis campos, en los que se muestra el estado de la aplicacin. En el primero empezando por la izquierda se muestra el estado de la conexin. En la figura 7.4 se muestra que no hay conexin, ya que la aplicacin ha detectado que no hay tarjetas conectadas.

El siguiente campo se muestra el nombre de la tarjeta que ha sido conectada. Los cuatro campos siguientes muestran el autor de la aplicacin, la fecha y hora que recoge del sistema operativo.

97

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura 7.4 Ventana principal sin conexin

En la parte derecha de la ventana se muestran una serie de elementos informativos, que sirven para comprobar los puertos disponibles y el nmero de tarjetas conectadas. Se ha implementado un botn de comando, que se ha rotulado con el titulo salir, que accede a la misma ventana de confirmacin de salir descrita en la figura 7.2.

Se ha implementado esta ventana con un men en la parte superior con teclas de acceso rpido. Concretamente este men lo componen los submens desplegables Archivo y Acerca de. El men Archivo lo compone un submen desplegable con nombre Salir y la tecla aceleradora CTRL+S. El men Acerca de dispone de un submen desplegable denominado Descripcin con la tecla aceleradora CTRL+D. En la figura 7.5 se muestran los mens creados.

98

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

Figura 7.5 Ventana principal men

En esta aplicacin se ha pretendido demostrar la caracterstica Hotswap de los dispositivos USB descrita en el captulo 3 El bus USB. Para ello se ha tratado demostrar que las tarjetas se pueden conectar y desconectar de la aplicacin sin mayor repercusin en el puerto serie virtual. Se puede iniciar el software con las tarjetas conectadas, y la aplicacin se encarga de detectar que tarjetas estn conectadas. Tras la deteccin de las mismas, la ventana principal se carga de una forma dinmica. Se muestra el nmero de tarjetas conectadas y la lista de las mismas. Se personaliza la barra de estado y el Tabstrip se actualiza con la tarjeta con menor nmero de puerto virtual, por una razn prctica, que no es otra que la de simplificar el cdigo. Una vez se ha arrancado la aplicacin, se pueden insertar las tarjetas y pulsar el botn reconexin con lo que se actualizarn todos los elementos informativos. En la ventana mostrada en la figura 7.6 se muestra la aplicacin con tres tarjetas conectadas. Para la

99

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

realizacin del proyecto solo se contaba con tres cables USB, pero el software est diseado para funcionar correctamente con las cuatro tarjetas.

Figura 7.6 Ventana principal conexin 3 tarjetas

La tarjeta Hermes USBDemo Board se ha creado en el proyecto, para servir de herramienta de testeo en las primeras fases del desarrollo del protocolo. Cuando esta tarjeta se encuentra conectada al sistema, la aplicacin se sita en su solapa con el nombre de la tarjeta. Se presenta actualizada la barra de estado, el nmero de tarjetas y la lista de puertos COM disponibles.

Se puede interactuar con dicha tarjeta mediante los controles que se han implementado dentro de su Tabstrip. Se puede clicar el botn Versin para que PIC identifique la tarjeta. Tal y como se muestra en la figura 7.7 la tarjeta responde con la cadena de caracteres Hermes USBDemo.

100

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

La tarjeta Demo dispone de un switch dip8 que se implement para el desarrollo inicial de la comunicacin. De esta manera se puede determinar el valor digital de las ocho entradas. Pulsando la tecla Data se puede adquirir los valores de stas entradas. Tal y como se muestra en la figura 7.7 la tarjeta responde mostrando en las ventanas de cada entrada con colores rojo y verde dependiendo de su valor. Si se pulsa el botn Encender Led se puede encender el led Rc3 del PIC. Esta prueba se puede apreciar en el video Aplicacin VB con la tarjeta USB demo que se presenta en el CD adjunto al proyecto. Cuando el led se encuentra encendido, el rotulo del botn cambia a Apagar Led.

Figura 7.7 Ventana principal conexin Hermes USB Demo Board

Con la tarjeta Hermes USB infrarrojos conectada, se puede acceder a la segunda y tercera solapa del Tabstrip. La aplicacin presenta la opcin de pedir los valores de los ocho sensores, o en su defecto los que se desee. Con el botn ciclo continuo se puede entrar en un modo de funcionamiento continuo, que puede desactivarse volviendo a

101

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

pulsar ste botn. En dicho modo de funcionamiento, la aplicacin pide los valores de los sensores de forma continua, mostrando los valores en las ventanas correspondientes. En la figura 7.8 se puede apreciar a la aplicacin trabajando con la tarjeta de infrarrojos corto. La aplicacin se encuentra en modo continuo, en la que se piden los valores de los sensores en un bucle infinito. En sta figura se puede apreciar como el usuario puede desactivar la peticin de ciertos sensores desactivando el check box correspondiente. De esta manera si se desea mostrar el sensor, se escribe el valor recibido en su casilla y en el caso de que no se desee mostrar el sensor se escribe la leyenda ----.

Figura 7.8 Ventana principal conexin Hermes USB Infrarrojos

Con la tarjeta Hermes USB ultrasonidos conectada al puerto USB, se puede acceder a la cuarta y ltima solapa de la aplicacin. Con ella se puede testear las medidas de los sensores de ultrasonidos, de una forma similar que las tarjetas infrarrojos.

Esto tiene su razn de ser y es que se ha tratado de crear un protocolo de comunicacin similar para todas las tarjetas. De esta manera la aplicacin cliente solo debe cambiar el

102

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

COM y mantener los mensajes. Esta estrategia de trabajo simplificar la aplicacin de control del maestro.

Figura 7.9 Ventana principal conexin Hermes USB Ultrasonidos I2C

Tal y como se puede apreciar en la figura 7.9, el software es dinmico segn las tarjetas que se encuentran conectadas. En este caso hay dos tarjetas conectadas al puerto USB. Se puede apreciar en la ventana derecha la lista de COM virtuales conectados. En este caso estn conectadas la tarjeta USBDemo Board que corresponde al COM5 y la tarjeta de ultrasonidos I2C correspondiente al COM8.

En una pequea ventana se muestra un nmero que corresponde a la cantidad de tarjetas conectadas y habilitadas. Las solapas del Tabstrip se modifican para que en cada contenedor se muestre el nombre de la tarjeta en negrita. Esto indica que se puede acceder a la solapa e interactuar con los controles que dispone.

103

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En este caso se est trabajando con la tarjeta de ultrasonidos. La barra inferior de status muestra que existe una tarjeta comunicando, concretamente Ultrasonidos I2C. En el ejemplo de la figura 7.9 se pide en modo continuo el valor de las mediciones de los ocho sensores de ultrasonidos. En la prueba de la que se ha obtenido dicha figura, la tarjeta trabajaba con cuatro sensores, concretamente los pares 2, 4, 6 y 8 quedando los impares 1, 3, 5 y 7 desconectados. El software, detecta que no hay sensor conectado mostrando la leyenda NO SENSOR. Esta caracterstica se consigue gracias a que el sensor en esta situacin da valores caractersticos, concretamente un valor de 255.

7.1.2

Cdigo Hermes USB Check Application v1.0

En el presente sub apartado, se pretende aclarar los aspectos ms relevantes del cdigo que se ha llevado a cabo para realizar la aplicacin, sin nimo de pretender ser un manual de Visual Basic, ya que en la red existen manuales mucho ms apropiados.

Lo primero que se ha de crear es la ventana que se va a mostrar con los diferentes controles que dispone la aplicacin. Una vez se han introducido todos los controles que se quieren implementar, se ha de insertar el control MSComm, que es el encargado de manejar la comunicacin serie estndar.

Se ha de configurar el control MSComm tal y como muestra la figura 7.10. Se debe configurar el apartado settings de dicho control. Se configura los baudios a 9600, la paridad par, 8 bits de datos y 1 bit de stop.

Este control presenta unos comandos especficos para el control de la comunicacin serie. Estos comandos se programan en la ventana de cdigo y son los siguientes.

104

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

Figura 7.10 Ventana principal comandos

Para el uso del puerto serie primero se ha de configurar la comunicacin con el puerto determinado. Por ejemplo si se desea comunicarse con la tarjeta infrarrojos corto se ha de configurar el puerto COM 6 tal y como se muestra a continuacin. MSComm1(0).CommPort = 6

Una vez configurado el puerto, se ha de abrir con el siguiente comando.

MSComm1(0).PortOpen = True

Si se quiere mandar un mensaje al dispositivo se ha de escribir el siguiente comando. En el ejemplo se muestra el mensaje de encender led en la tarjeta Hermes USBDemo Board. MSComm1(0).Output= "L_ON"

El protocolo desarrollado en los microcontroladores responde a los siguientes mensajes. Cualquier otro mensaje que la aplicacin escriba en el puerto, es obviado por la tarjeta.

105

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El maestro puede mandar el mensaje VERS. Todas las tarjetas tienen implementada dicha peticin a la que responden con el nombre o identificacin de la tarjeta.

La tarjeta Hermes USB Demo responde con USBDemo Board. La tarjeta infrarrojos corto responde con Infrared Board1. La tarjeta infrarrojos largo responde con Infrared Board2. La tarjeta ultrasonidos responde con Ultrasonidos I2C.

El maestro puede mandar el mensaje L_ON y LOFF a la tarjeta demo para encender y apagar respectivamente el led. Esta tarjeta requiere el mensaje DATA para obtener el valor de los interruptores digitales.

Para obtener el valor de cualquiera de los ocho sensores, de las dos tarjetas (infrarrojos y la de ultrasonidos), se debe mandar el mensaje DATA seguido del nmero del sensor del uno al ocho. Una vez que se ha escrito, por ejemplo DATA8, se ha de leer lo que ha escrito la tarjeta esclava con la que se haya comunicado. Para ello se debe introducir el siguiente comando. Hay que guardar dicho valor en un buffer, en la aplicacin DATAINF, para luego mostrarlo en las ventanas creadas para tal efecto. MSComm1(0).Output= "DATA1" // Se pide sensor 1 DATAINF = MSComm1(0).Input // Se lee el valor que se recibe del dispositivo

Como funcin principal en la aplicacin se encuentra ChequeoPuertos, que chequea los puertos COM (5 a 10) que se encuentran conectados. Se llama sucesivamente en un bucle For a COMCheckPort para definir con que puertos puede comunicar la aplicacin. Se guarda en un vector los COM que ofrecen un valor true.

Function ChequeoPuertos() For x = 5 To 10 COM(x) = COMCheckPort(x) Next End Function

106

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

La siguiente funcin chequea por prueba y error los puertos con los que se puede comunicar. Tiene como argumento de salida valores true o false.

Private Function COMCheckPort(Port As Long) As Boolean

// Retorna false si no se puede abrir el puerto o no existe // Retorna true si el puerto est disponible

// Manejo de errores On Error GoTo OpenCom_Error

// Activa el numero de Puerto para el testeo MSComm1(0).CommPort = Port // Si el Puerto ya est abierto no est disponible If MSComm1(0).PortOpen = True Then COMCheckPort = False Exit Function // Si no est abierto puede estar disponible Else // Se testea el Puerto abriendo y cerrando. Si hay error On Error MSComm1(0).PortOpen = True MSComm1(0).PortOpen = False COMCheckPort = True Exit Function End If

OpenCom_Error: COMCheckPort = False

End Function

107

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

7.2

Firmware Hermes USB CDC

En el presente apartado se resumen los aspectos con mayor relevancia de la programacin del firmware en las tarjetas esclavas. En el CD adjunto al proyecto, en la carpeta Anejos electrnicos\Programas\Firmware Hermes USB CDC se pueden consultar los cdigos para cada una de las tarjetas. En el archivo main.c, en la funcin InitializeSystem se ha configurado el modo de energa que adopta el PIC cuando se entra en modo suspensin. Para ello se configura el registro de estado OSCCON Oscillator Control Register. Concretamente se activa el bit IDLEN Idle Enable Bit, para que el microcontrolador entre en el modo PRI_IDLE 13. En el estado de suspensin, en este modo de trabajo la CPU se desactiva, quedando los perifricos activos para poder iniciar el microcontrolador de nuevo.

En el archivo io_cfg.h se ha configurado el patillaje especfico de las tarjetas del robot Hermes. En todas las tarjetas se ha implementado un pin digital que detecta la conexin del dispositivo al bus. (Ver pin D3 del microcontrolador en los esquemticos, en el CD adjunto). Para ello se debe implementar el siguiente cdigo tal y como se puede apreciar el los anejos electrnicos.

#define usb_bus_sense

PORTDbits.RD3

En el caso de la tarjeta Hermes USBDemo, en dicho archivo se configuran los switches como entradas digitales. En las tarjetas infrarrojos se configuran los puertos analgicos como entradas. En la tarjeta ultrasonidos se configura los pines SDA y SCL del protocolo I2C como entrada y salida respectivamente.

Se ha modificado el firmware para que ejecute la funcin USBTasks en una subrutina de atencin al desbordamiento del timer0. De esta manera el bucle se encuentra siempre en la funcin ProcessIO que se presenta en los archivos Hermes.c. (Vase carpeta del CD Anejos electrnicos\Programas\Firmware Hermes USB CDC\Firmware\user). Para ello primero se ha de configurar la interrupcin con la rutina InitializeInterrupts. Se puede consultar dicho cdigo en la carpeta user de cualquier firmware en el archivo Interrupt.c.
13

PIC18F4550 Data Sheet - 3.0 Power Managed Modes

108

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

Dicha inicializacin se ejecuta en la funcin UserInit que inicializa el sistema de usuario. Esta funcin se encuentra en el archivo main.c despus de ejecutar la inicializacin del USB InitializeSystem. Dichas funciones se ejecutan al inicio del programa y solo son ejecutadas una vez.

La funcin InitializeInterrupts habilita varios niveles de interrupcin, para futuros desarrollos, e inicializa la interrupcin de prioridad baja del timer0 tal y como se muestra en el siguiente cdigo.

#include <timers.h> void InitializeInterrupts(void) { RCONbits.IPEN = 1; INTCONbits.GIEH = 1; // Se habilitan varios niveles de interrupcin // Se habilitan interrupciones globales de prioridad alta

(Timer0 refresco USB 1.9mSeg (frec 530HZ) INTCONbits.GIEL = 1; INTCON2bits.TMR0IP = 1; // Se habilita interrupciones globales de prioridad baja // Prioridad alta para interrupcin timer0

OpenTimer0(TIMER_INT_ON & T0_16BIT & T0_SOURCE_INT & T0_PS_1_1); WriteTimer0(0xFE30);}

Cuando el timer0 se desborda entra en la siguiente interrupcin. En sta, primero se borra el flag de la interrupcin, se ejecuta la funcin de refresco, y se configura la precarga necesaria del timer0.

#pragma interruptlow tmr_isr void tmr_isr(void) { INTCONbits.TMR0IF=0; // Se borra el flag de la interrupcin refrescoUSB(); WriteTimer0(0xFE30); // Se ejecuta el refresco del USB // Precarga necesaria para el timer0

109

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Dentro de la rutina refrescoUSB, se ejecuta la funcin USBTasks, para mantener el dispositivo activo en el bus. Adems se ejecuta la funcin BlinkUSBStatus, que tiene como nico objeto el sealizar con los leds de status el estado del dispositivo en el bus. (Ver archivo Hermes.c).

Si el dispositivo no se encuentra configurado o est en estado de suspensin, sale de la funcin. Si se encuentra configurado se ejecuta la funcin Borrar_buffer. Esta funcin borra el buffer de entrada del USB del PIC. Se ha implementado dicha rutina para disponer del buffer de entrada vacio, ya que en el paso siguiente, se recoge el mensaje del maestro, en caso de haberlo. Se ejecutan las funciones CommandGet y CommandRun.

void refrescoUSB(void) { USBTasks(); // Refresco de la funcin que mantiene "vivo" al USB BlinkUSBStatus(); // Refresco leds status

if((usb_device_state < CONFIGURED_STATE)||(UCONbits.SUSPND==1)) return; Borrar_buffer(); if (mUSBUSARTIsTxTrfReady()) { CommandGet(); CommandRun(); }//end if (mUSBUSARTIsTxTrfReady())

La funcin CommandGet recoge los posibles mensajes del maestro y los almacena en dos variables, usb_command y usb_param. Con esta funcin y de la misma manera se pueden distinguir entre comandos de cuatro y cinco caracteres.

Si el mensaje del maestro tiene cuatro caracteres, solo puede ser el caso del mensaje VERS. En este caso almacena el mensaje en usb_command. En el caso de que el mensaje tenga cinco caracteres, es el caso de DATA0, DATA1, almacena el mensaje DATA en usb_command y el valor entero 0, 1, 2, en la variable usb_param.

110

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

void CommandGet(void) { if (getsUSBUSART(rx_buffer,64)) {len=(int)mCDCGetRxLength(); // Copia de los 4 dgitos primeros if (len>=4) { strncpy(usb_command,rx_buffer,4); usb_command[4]=0; while ((i+5)<len) { parametro[i]=rx_buffer[i+5]; i++;} parametro[len-5]=0; usb_param=atoi(parametro); } } }//End CommandGet

La funcin CommandRun distingue los mensajes entrantes del maestro y si son aceptados ejecuta la accin deseada. Se utilizan las variables usb_command y usb_param, para conseguir dicho objetivo.

void CommandRun(void) { if(strcmp(usb_command,VERS)==0){SendRespData(UltraSonidos I2C);} else if(strcmp(usb_command, "DATA")==0){ switch(usb_param){ case 1: SendData(1);break; case 2: SendData(2);break; case 3: SendData(3);break; case 4: SendData(4);break; case 5: SendData(5);break; case 6: SendData(6);break; case 7: SendData(7);break; case 8: SendData(8);break;}} }//End CommandRun

111

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Con las funciones de CommandGet y CommandRun, se consigue que el sistema sea host centric, iniciando la comunicacin USB la aplicacin cliente. Las siguientes funciones y la macro, son utilizadas por el microcontrolador para escribir en el bus. Se debe escribir cadenas de caracteres en el bus, es por ello, que las medidas de los sensores requieren ser convertidos a su formato ASCII, antes de transmitirlos.

void SendData(int a) { itoa(temp[a-1],tx_buffer); USBtx(); }// End SendResp void SendRespData(char* data) { strcpy(tx_buffer,data); USBtx(); }// End SendResp

#define USBtx() { mUSBUSARTTxRam((byte*)tx_buffer,strlen(tx_buffer));}

En el caso de la programacin de las tarjetas de infrarrojos se utiliza el siguiente bucle de usuario. Se ejecuta un bucle For que va adquiriendo los valores digitales convertidos de los sensores de infrarrojos. Cabe destacar que las tarjetas de infrarrojos de corto y largo alcance no presentan ninguna diferencia a nivel de programacin de firmware.

void ProcessIO(void) { for(a=1;a<9;a++) Lectura_sensor(a); }//end ProcessIO

112

Captulo 7

SOFTWARE DE CONTROL ROBOT HERMES

En la funcin lectura_sensor se utilizan las funciones de la librera adc.h del compilador C18. Se pueden consultar el manual de las libreras en la carpeta 4.-

Manuales\Programacin PIC\Mplab C18, del CD adjunto al proyecto.

void Lectura_sensor(int a) { // --- Eleccin del canal analgico a leer ---

switch(a){ case 1: SetChanADC(Sensor1);break; case 2: SetChanADC(Sensor2);break; case 3: SetChanADC(Sensor3);break; case 4: SetChanADC(Sensor4);break; case 5: SetChanADC(Sensor5);break; case 6: SetChanADC(Sensor6);break; case 7: SetChanADC(Sensor7);break; case 8: SetChanADC(Sensor8);break; // ----------------------------------------------Delay10TCYx(5); ConvertADC(); while(BusyADC()); // Espera de 50TCY para tiempo adquisicin // Empieza la conversin ADC aproximaciones suc. // Ha finalizado? }

temp[a-1] = ReadADC(); // Lectura del sensor elegido }//end Lectura_dato

113

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

En el caso de la programacin de la tarjeta de ultrasonidos se utiliza el siguiente bucle de usuario. Se hacen uso de las funciones de librera propia MakeMeasure y Get_usMeasure, explicadas en detalle en el captulo 5 Protocolo de comunicacin I2C.

void ProcessIO(void) { //--- INICIO DE LAS MEDIDAS --// Para evitar interferencias se activan primero los sensores impares // --------------------------------for (i=1;i<9;i++) { MakeMeasure(i); i++; } // Para evitar interferencias se activan segundo los sensores pares for (i=2;i<10;i++) { MakeMeasure(i); i++; } Delay10KTCYx(40); // Tiempo necesario para la adquisicin de los sensores

// ------------------------------------------------------------------// Siguiente fase adquirir la medida de los sensores for (i=0;i<8;i++) {dist[i] = Get_usMeasure(i+1);}

}//end ProcessIO

114

Captulo8

CONCLUSIONES Y LINEAS FUTURAS

8 CONCLUSIONES Y LINEAS FUTURAS


A partir del trabajo investigativo realizado en este proyecto, ha sido posible inferir una serie de conclusiones que se desgranan a continuacin.

Como ya se ha expuesto en el captulo 3 El bus USB, los dispositivos pertenecen a diferentes clases. La clase utilizada en el presente proyecto es la clase CDC, un tipo de puerto USB serie emulado que utiliza las transmisiones Bulk. Estas transferencias son rpidas pero el host no le asegura un porcentaje del tiempo de transmisin por trama. Simplemente si el bus est libre transmiten con rapidez. Podra ser de gran inters desarrollar la tarjeta que controla los drivers de los motores, con un tipo transferencia diferente. Sera importante desarrollar este perifrico con transferencia asncrona o Interrupt. (Vase capitulo 3 sub apartado 3.2.2 Caractersticas de transmisin bus USB). De esta manera, se le podran dar privilegios a las tarjetas de motores, dndoles una mayor prioridad en la comunicacin.

Una vez se es capaz de desarrollar un dispositivo USB de una clase determinada, es sencillo crear dispositivos de otras clases. La nica diferencia sustancial es el archivo cabecera utilizado. En el caso del proyecto, el archivo cabecera utilizado es el cdc.c y las funciones que implementa, las necesarias para la comunicacin USB. Es por tanto, relativamente sencillo implementar diferentes clases de dispositivos. nicamente se requiere el estudio de las funciones del archivo de cabecera de la clase que se quiere desarrollar.

Como ya se ha comentado, la clase utilizada es la CDC, que emula una conexin serie tradicional. Esto reporta unas ventajas importantes. Una vez que se desarrolla el dispositivo, simplemente con el Hyperterminal de Windows se puede comprobar la comunicacin. El software cliente es sencillo de implementar, debido a que solo requiere el manejo de las libreras de puerto serie convencional.

Entre las desventajas que se intuyen, se encuentra la velocidad de transmisin. Segn se ha investigado, la velocidad de transmisin es sensiblemente ms baja que una clase de USB genrica. Es por ello que puede ser recomendable dirigir los desarrollos en esta

115

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

lnea. Si se desarrollan dispositivos genricos se ha de utilizar la librera dinmica MPUSBAPI.dll, tal y como se expone en el libro USB Complete de Jan Axelson.

Una de las principales conclusiones que se ha sido deducida del desarrollo del firmware USB en el PIC, es la existencia de una frecuencia de refresco necesaria para la funcin USBTasks. Esta funcin mantiene activo al dispositivo en el bus USB. La estructura del firmware ejecuta dicha funcin y a continuacin la funcin de usuario, en un bucle infinito. Es por ello, que se han de crear funciones de usuario, lo ms livianas y eficientes posibles.

El bus USB requiere que se transmitan los datos como una cadena de caracteres, en lo que se refiere a la tarjeta de infrarrojos requiere que los valores del convertidor analgicodigital, sean convertidos previamente a su valor ASCII. Esto hace que sea preciso usar la funcin itoa, rutina de la librera estndar del lenguaje C ANSI stdio.h. Esta funcin, al ser una funcin genrica, es excesivamente grande y lenta. Esta estrategia de trabajo implica que se ejecute la funcin itoa una vez por cada valor del sensor. Esto requiere entonces, que se hagan ocho conversiones a ASCII lo que supone un coste computacional muy alto.

Una posible direccin de trabajo futuro, podra ser la ejecucin de una funcin propia ms rpida, que a travs de tablas haga la conversin al valor ASCII. Generando de tal manera, una funcin especfica, no tan genrica y lenta que la suministrada por la librera stdio.h.

En el caso de que las funciones de usuario sean irremediablemente tediosas, se ha de recurrir a una interrupcin por desbordamiento de un temporizador del PIC. En esta subrutina se ha de ejecutar la funcin USBTasks. Es recomendable a su vez, implementar en la subrutina, las funciones de lectura y ejecucin de las peticiones del maestro. Esto se debe hacer, porque de esta manera, el sistema est sincronizado con el bus USB y las peticiones del maestro. En la tarjeta de ultrasonidos se ha implementado esta estrategia, debido a que el uso del protocolo I2C requiere funciones de bus libre, que sin el uso de la interrupcin, hacen que el dispositivo se desconfigure. Es aconsejable ajustar la precarga del temporizador de un modo prctico, para conseguir la frecuencia de refresco ms ptima.

116

Captulo 8

CONCLUSIONES Y LNEAS FUTURAS

En relacin con sta funcin de espera del ACK (ver libreras I2C), el firmware se queda en espera del sensor ultrasonidos. Si el sensor est desconectado, o en el peor de los casos se haya estropeado, no se actualizarn ms los sensores. Gracias a la interrupcin, el dispositivo es capaz de mantenerse activo en el bus, incluso es capaz de recibir peticiones y ejecutarlas, pero como la funcin de usuario no es capaz de avanzar se ofrecern los ltimos valores de refresco de los sensores antes de la avera.

Sera de inters implementar en el futuro la caracterstica de timeout en las funciones de uso del protocolo I2C. Esta estrategia activa un temporizador para cada funcin escritura/lectura del bus I2C, con la intencin de ver cunto tardan. Si se pasa de un tiempo, que se deber de estudiar en cada caso, el firmware ser capaz de pasar al siguiente sensor.

Con los resultados obtenidos, se ha podido comprobar que la aplicacin del PC maestro puede detectar que tarjetas se encuentran conectadas al sistema. Esto se ha logrado con la implementacin en el firmware, de la peticin de versin de tarjeta. Gracias a ello, la aplicacin cliente, puede detectar en todo momento que tarjeta se encuentra configurada en el bus USB y cual no.

Una lnea de desarrollo interesante sera el realizar un programa en el maestro, que permita detectar la tarjeta USB que no est conectada, para actuar en consecuencia. El robot podra ejecutarse en un modo de operacin en condiciones mermadas, que por ejemplo caminase ms despacio, si una de las tarjetas deja de funcionar. As, en el caso de que por ejemplo, se haya desconectado la tarjeta de ultrasonidos, el robot podra seguir movindose hasta el taller para ser reparado, de una manera cautelosa.

Para el desarrollo de la comunicacin USB de las webcams se ha de implementar una clase USB VDC Video Device Class. Salvando las distancias, el desarrollo del dispositivo no debe diferir en exceso del desarrollo de una clase CDC.

117

Captulo 9

BIBLIOGRAFA

9 BIBLIOGRAFIA
En el presente capitulo se muestran las pginas web y bibliografa de consulta recomendada, que han sido utilizados en el desarrollo del presente proyecto. Bibliogafa: USB Complete Jan Axelson Lakeview Research Documentacin internet: PIC 18f4550: Manual del microcontrolador http://ww1.microchip.com/downloads/en/DeviceDoc/39632b.pdf Driver CDC: Artculos relacionados con el driver CDC. http://www.thesycon.de/eng/usb_cdcacm.shtml Pgina de descarga del driver CDC. http://www.obddiag.net/drivers.html USB: Pgina web de USB-IF. http://www.usb.org Pgina web USB http://www.ru.lv/~peter/macibas/datoru_arhitektura/usb.pdf Artculo clase USB CDC.

118

Captulo 9

BIBLIOGRAFA

http://ww1.microchip.com/downloads/en/AppNotes/00956b.pdf Proyecto teora USB. http://www.i-micro.com/pdf/articulos/usb.pdf Proyecto explicacin firmware. http://www.cs.cinvestav.mx/Estudiantes/TesisGraduados/2006/resumenJuanPabloF.pdf Compilador c18: Pgina web tutorial c18. http://slalen.iespana.es/pics/datos/C18.pdf Manual libreras compilador c18. http://ww1.microchip.com/downloads/en/devicedoc/MPLAB_C18_Libraries_51297f.pdf Manual libreras delay c18. http://w3.id.tue.nl/fileadmin/id/objects/EAtelier/doc/Tutorials/DELAY_FUNCTIONS_18F4550.pdf Proyectos relacionados: Proyecto USB Data adquisition.

http://www.sixca.com/eng/articles/usbdaq/index.html Hardware USB. http://www.piccoder.co.uk/content/view/42/26/1/1/ Pgina web osciloscopio USB http://www.pablohoffman.com Protocolo I2C: Pgina web libreras ensamblador I2C.

119

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

http://www.robot-electronics.co.uk/acatalog/examples.html Articulo relacionado con el protocolo I2C. http://www.comunidadelectronicos.com/articulos/i2c.htm Sensores ultrasonidos: http://www.superrobotica.com/S320122.htm Sensores infrarrojos: http://catarina.udlap.mx/u_dl_a/tales/documentos/lem/sandre_c_g/capitulo5.pdf Informacin genrica: Pgina web de consulta genrica. http://www.wikipedia.org Pgina web fabricante de microcontroladores PIC. http://www.microchip.com Pgina web del software creacin layout tarjetas. http://www.cadsoft.de Manual Eagle layout editor. http://web.mit.edu/eaglecad_v4.16/manual-eng.pdf Artculos relacionados con Eagle 3D. http://www.matwei.de/doku.php?id=en:eagle3d:documentation Manuales Eagle 3D. http://www.matwei.de/doku.php?id=en:eagle3d:links

120

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 1 SOFTWARE
En el presente anejo se presenta una descripcin detallada del software utilizado para el desarrollo del proyecto. Se hace un nfasis en las dificultades y soluciones adoptadas en cada caso.

Se explica el entorno de programacin MPLAB resumiendo las consideraciones de configuracin y puesta en marcha del compilador C18 para la realizacin de un proyecto. Se resumen los aspectos ms relevantes de la programacin de los microcontroladores con el programador ICD2 In circuit debugger del fabricante Microchip.

Se describen los aspectos ms significativos y las consideraciones a tomar en la realizacin de las tarjetas con el software de edicin de layout EAGLE. Junto con este programa se explica tambin la manera de crear tarjetas en tres dimensiones para vistas con el software POVRAY.

Se da una visin global de las acciones a tomar para la realizacin de la aplicacin en el PC de Visual Basic. Para finalizar se explica el software brindado por la casa Tektronix para adquirir las capturas de pantalla del osciloscopio en el PC.

Anejo 1.1 MICROCHIP MPLAB IDE v8.0


Este software es un editor IDE gratuito, destinado a productos de la marca Microchip. En el CD del proyecto, en la carpeta Software/MPLAB se adjunta la versin v8.0 del programa para instalar. De cualquier modo, se puede descargar la ltima versin desde la pgina del fabricante 14, en la seccin MPLAB IDE.

Es un editor modular que permite la seleccin de diferentes microprocesadores entre los que se encuentra el PIC18F4550 utilizado en el presente proyecto. Es un programa que corre bajo Windows y como tal, presenta las clsicas barras de programa, de men, de herramientas de estado que el sistema operativo de Microsoft.
14

www.microchip.com

121

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura A1.1 Software MPLAB IDE

Anejo 1.1.1 Configuracin de un proyecto


Lo primero que hay que hacer a la hora de programar el firmware es crear un nuevo proyecto. Se elige el microcontrolador que se quiere programar y se elige el compilador que se va a usar.

Figura A1.2 Creacin de un proyecto MPLAB IDE

122

Anejo 1

SOFTWARE

En el proyecto se ha de configurar el compilador C18. Por defecto, MPLAB compila con MPASM en ensamblador, y se le debe indicar que se compilar en C18. Para ello se deben definir las rutas del compilador. Se debe ir al men Project, clicar el submen Set Language Tools Location, y buscar el compilador Microchip C18 Toolsuite.

Una vez localizado, se han de configurar las rutas de localizacin de los cuatro ejecutables siguientes: MPASM Assembler con C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe MPLAB C18 C Compiler con C:\mcc18\bin\mcc18.exe MPLIB Librarian con C:\Program Files\Microchip\MPASM Suite\mplib.exe MPLINK Object Linker con C:\mcc18\bin\mplink.exe

Figura A1.3 Configuracin compilador C18

Una vez definidos los ejecutables, se ha de designar los directorios de bsqueda. Esto se realiza en la misma ventana en la opcin Default Search Path & Directories. Se han de configurar los directorios de bsqueda de los archivos include, las libreras y el linker del compilador. A continuacin se detalla la configuracin que se ha de ejecutar.

123

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Include Search Path con C:\mcc18\h Library Search Path con C:\mcc18\lib Linker-Script Search Path con C:\mcc18\lkr

Una vez realizada la configuracin se puede comprobar la misma en el men Project en el submen Build Options tal y como se muestra en la figura A1.4.

Figura A1.4 Comprobacin de la configuracin compilador C18

El archivo 18f4550.lkr es de una importancia notoria en el desarrollo del proyecto en MPLAB. Al ser un cdigo modular, formado por multitud de archivos, necesita que sean unidos en compilacin, por lo que necesita de ste archivo. Para insertarlo en el proyecto se ha de buscar el archivo .lkr en la carpeta lkr del compilador C18.

124

Anejo 1

SOFTWARE

Figura A1.5 Linker compilador C18

Para insertar archivos al proyecto se ha de clicar el botn derecho del ratn en sources files o headers files.

Figura A1.6 Introducir archivos MPLAB

125

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 1.1.2 In Circuit Debugger ICD2


En el presente proyecto se ha contado con la inestimable ayuda del MPLAB ICD2 de microchip. Permite la programacin del PIC, pero adicionalmente permite depurar el programa directamente dentro del microprocesador. De esta forma no se trabaja sobre una simulacin de cmo podra trabajar el sistema, sino que efectivamente se trabaja en tiempo real sobre el sistema real.

En un principio se opt por la creacin de uno de los programadores clnicos ICD2 que hay en la red 15. En el CD adjunto a este proyecto, se ha incluido una carpeta llamada ICD2 CLONE en la que se recoge el esquemtico y el layout para crear la tarjeta en la insoladora.

Figura A1.7 Programador ICD2 Clone

Dicho programador tiene 2 microcontroladores PIC uno destinado para el control USB y el otro encargado de la programacin. Se han de programar un PIC16F877A y un PIC18F4550.

15

www.icd2clone.com

126

Anejo 1

SOFTWARE

En la carpeta del CD 7.- ICD2 CLONE\ICD2 Clone 4550\PICs se adjunta los programas ejecutables que es necesario grabar en ellos. Concretamente se han de programar los archivos 18F4550_boot.hex y 16F877A_boot.hex, para lo que se ha de utilizar otro programador. Para programar cada ejecutable en los microcontroladores se ha de abrir la aplicacin MPLAB en el men file/Import. Una vez elegido el ejecutable se carga el programa en el PIC.

En principio el programador clnico funciona correctamente y se ha programado parte del proyecto con l. Dicho programador dispone de un regulador de tensin MC34063A, que sufre calentamiento excesivo cuando se trabaja muchas horas con l. En esta situacin el programador deja de estar operativo volviendo a funcionar cuando se deja enfriar. El programador ha sido fabricado por iniciativa propia del alumno, sin ninguna finalidad en el proyecto, por lo que se ha optado por revisarlo ms a fondo una vez se finalice el proyecto.

Se opt por terminar de programar el firmware con el ICD2 original de Microchip que se dispona en el taller de Automtica, que es ms estable y fiable. El ICD2 se conecta a una PC mediante un puerto USB o serie, y es controlado mediante el MPLAB IDE, el entorno de desarrollo integrado de Microchip.

Sin nimo de reemplazar el manual del usuario del ICD2, ste sub apartado pretende indicar los desafos habituales al trabajar con esta herramienta. Para cualquier otra consulta o duda, se ha de remitir al MLAB ICD2 In-Circuit Debugger User Guide, disponible en la pgina web de Microchip en la seccin Development Tools. A su vez se adjunta en el CD, en el apartado manuales, dicha gua de usuario.

Esta herramienta, dispone de una conexin serie tradicional y una USB. Lo ms habitual es utilizar el cable de conexin USB. Se ha de alimentar el disco con el cable de alimentacin de 9v. El disco ICD2 presenta un conector RJ45 tipo telefnico, para servir de conexin con la tarjeta que se desea programar.

Para utilizar el programador por primera vez en el equipo hay que asignarle el driver que necesita. Se debe ir al men Programer/Download ICD2 Operating System y se debe

127

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

introducir el driver especfico de la carpeta C:\Program Files\Microchip\MPLAB IDE\ICD2 que es creada en la instalacin del software.

El ICD2 puede funcionar como programador o como debugger, pero no ambos simultneamente. Como programador, toma el cdigo ensamblado y lo graba en el dispositivo. Un microcontrolador con cdigo grabado en modo programador no puede ser depurado en circuito. En la figura A1.8 se puede apreciar el men con el que se ha de interactuar para utilizar el programador en ste modo.

Como debugger, tambin puede grabar el cdigo, pero inserta en el mismo unas pequeas modificaciones que le permiten tomar el control y ejecutar el paso a paso. Si se necesita depurar el cdigo en circuito, se debe seleccionar al ICD2 como debugger. El software MPLAB permite la insercin de tres breakpoints para la depuracin en modo debugger.

Un microcontrolador con cdigo grabado en modo debugger no puede funcionar sin el ICD2 y el MPLAB IDE. Para probar el circuito sin el ICD2, se debe seleccionar a ste como programador.

Figura A1.8 Programador ICD2

128

Anejo 1

SOFTWARE

Si se configura al MPLAB IDE para conectarse automticamente al ICD2, no es necesario realizar la conexin o habilitacin manual. En este caso, al seleccionarlo, segn el dispositivo elegido para trabajar (Configure ->Select device), el MPLAB IDE deber o no actualizar el firmware del ICD2, lo cual se le indicar mediante un requester.

Figura A1.9 Configuracin ICD2

Es habitual el caso de que al conectarse al ICD2 se reciba un mensaje ICDWarn0020 unable to connect MPLAB ICD2. Se debe ir al men Programmer ->Settings..., clicar en la solapa Status y luego en Run Self Test. En esta ventana se puede testear la posible falla en el test de "Target Vdd". Si est conectado todo correctamente y no presenta conexin, hay que optar por desconectar y apagar el ICD2 y salir de MPLAB, para volverlo a intentar de nuevo.

En la solapa del men Power, tal y como se muestra en la figura A1.10 se muestra un check button (Power target circuit from MPLAB ICD 2), que permite elegir de donde se va a alimentar la tarjeta dispositivo. En nuestro caso se elige que va a ser alimentado por fuente externa, y no del ICD2.

129

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Figura A1.10 Men Programer/Settings

Anejo 1.2 EAGLE LAYOUT EDITOR v4.16r2


En el presente anejo se explican de forma global las consideraciones ms importantes a la hora de utilizar el software de edicin de layouts de tarjetas Eagle v4.16r2. En el CD adjunto al proyecto, en la carpeta 5 Software se presenta el programa que hay que instalar para su uso. En la carpeta 4 Manuales\Eagle se adjunta un manual en el que se pueden consultar cuestiones ms especficas.

Para crear un nueva tarjeta se ha de clicar el men file/new/schematics. Este software tiene dos pantallas fundamentales, la pantalla de esquemticos y la pantalla de la placa board.

130

Anejo 1

SOFTWARE

Figura A1.10 Men New/Schematics Eagle

En la pantalla de esquemticos se han de ir insertando los diferentes componentes con el botn Add, tal y como se muestra en la figura A1.11.

Figura A1.11 Men ADD Eagle

131

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Es buena prctica utilizar rtulos en las conexiones para evitar los excesos de cableado, evitando que se crucen las conexiones. Para ello se ha de interactuar en la conexin que se quiere unir con los mens en los que se ha hecho un zoom en la figura A1.12.

Primero se ha de introducir una etiqueta con el botn ABC. Una vez que ha creado sta, se ha de renombrar con un cdigo con su funcin que ayude a la comprensin. En la figura se conecta la salida del reloj oscilador primario por lo que se nombra OSC1.

Figura A1.12 Crear labels Eagle

Es aconsejable separar los esquemticos en bloques con lneas de puntos de color diferente a las conexiones. En ellos se puede rotular un titulo que determine su funcin genrica. As en el proyecto, se ha tratado de agrupar la electrnica de funcionamiento del PIC (Oscilador, condensadores desacoplo, reset). La electrnica de comunicacin, USB, I2C y USART se ha agrupado en otro bloque. Se ha definido un bloque especfico para las entradas y salidas. Esta manera metdica de trabajo simplifica y clarifica los esquemticos.

132

Anejo 1

SOFTWARE

Figura A1.13 Agrupar modo esquemtico Eagle

Pulsando el men file/switch to board se accede a la placa board del esquemtico. Se ha de tener ciertas consideraciones para crear tarjetas aceptables.

Los componentes se han de colocar dentro del rea del layout, cumpliendo las especificaciones del proyecto, en cuanto a tamao del mismo. A la hora de colocar los componentes, se han de considerar los siguientes puntos.

Prever el espacio que ocupan los cables en torno a los conectores que se diseen. Es por tanto buena prctica, el colocar los conectores en un extremo de las placas.

Situar los componentes que sean susceptibles de calentamiento agrupados en la zona de mayor circulacin de aire. Dichos componentes pueden ser reguladores de tensin, rectificadores, transistores de potencia, etc.

Lograr las pistas ms cortas posibles. Intentar agrupar los componentes de una manera que facilite la soldadura en caso de que sta sea manual.

133

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Hay que tratar de crear tarjetas con el menor nmero de capas posible, ya que encarecen el coste. En el proyecto se ha utilizado tarjetas de una capa con doble cara, siendo la cara superior la roja y la cara inferior la azul. Tambin se ha de tratar de crear la tarjeta con una cara. En caso de ser difcil de conseguir se puede recurrir a saltos a la cara contigua por medio de vas.

En el presente proyecto, aunque se dispona de baquelita de doble cara se opt por utilizar placas de cara simple y se disearon simples pasos de cara con pista corta, con simples puentes con alambre o patillas de componentes.

Se ha de tratar de no crear pistas con codos de 90 grados, creando las curvas como se puede apreciar en la figura A1.14. Suele ser aconsejable no hacer las pistas excesivamente estrechas ni excesivamente prximas, para evitar posibles errores en la fase de atacado con cido.

Figura A1.14 Layout Hermes USBDemoBoard Eagle

134

Anejo 1

SOFTWARE

Anejo 1.3 EAGLE 3D


En el presente anejo se muestra de una manera global las cuestiones que se han de ejecutar para crear las vistas en 3D de una PCB. No se pretende ser un manual de uso de estas libreras ya que el manual que se adjunta en el proyecto cumple esta funcin de una manera ms eficiente. En el CD adjunto en la carpeta 4.- Manuales\Eagle 3D se ofrece el manual que explica en detalle la instalacin y uso de stas libreras. En la carpeta 5 Software\Eagle3D se adjunta el archivo que instala las libreras. No es un software en s, sino que son unas libreras creadas por Matthias Weiber de forma no lucrativa para crear vistas tridimensionales de las PCB a partir de las vistas en dos dimensiones que se logran con Eagle. En el mercado existe diverso software que traen de serie la opcin de las vistas en 3D, tales como Proteus, pero se tratan normalmente de aplicaciones de pago. Esta forma de crear stas vistas requiere solo programas gratuitos.

Una vez se ha creado el archivo en Eagle se ha de coger el archivo board con extensin .brd que se ha creado. Se ha de pulsar el botn ulp para insertar las libreras en lenguaje de programacin de usuario (ulp). Se ha de insertar la carpeta 3d41.ulp de la carpeta ulp de la instalacin Eagle 3d.

Figura A1.15 3d41.ulp 135

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Una vez se ha creado el archivo .pov se ha de abrir dicho archivo con PovRay y renderizar el archivo. En el mejor de los casos estarn todos los componentes pero en el caso de que no se logre un resultado aceptable y falten componentes, lo que es muy usual, se ha de modificar el archivo 3dpack.dat tal. Se explica ms en detalle en el capitulo Encapsulados y componentes, del manual Eagle3D bsico adjunto en la carpeta 4Manuales\Eagle 3 del CD del proyecto.

Figura A1.16 Cmara PovRay

Para cambiar la vista de la cmara hay que cambiar su posicin (x,y,z) y el punto a que mira, siendo en centro del universo, el centro de la tarjeta.

Estas libreras crean la tarjeta sobre un fondo ondulado que simula un mar. Este fondo se ha modificado para dar una vista ms realista. Se ha modificado el archivo .pov creado, para que este fondo simule la mesa del taller, siendo sta de color madera de pino. Para

136

Anejo 1

SOFTWARE

conseguir este objetivo hay que localizar el cdigo #if(environment=on) #end e insertar el siguiente cdigo.

#if(environment=on) sky_sphere {pigment {Navy} pigment {bozo turbulence 0.65 octaves 7 omega 0.7 lambda 2 color_map { [0.0 0.1 color rgb <0.85, 0.85, 0.85> color rgb <0.75, 0.75, 0.75>] [0.1 0.5 color rgb <0.75, 0.75, 0.75> color rgbt <1, 1, 1, 1>] [0.5 1.0 color rgbt <1, 1, 1, 1> color rgbt <1, 1, 1, 1>]} scale <0.1, 0.5, 0.1>} rotate -90*x}
plane{y,-10.0max(pcb_x_size,pcb_y_size)*abs(max(sin((pcb_rotate_x/180)*pi),sin((pcb_rotate_z/180)*pi)))

texture{ EMBWood1 normal{ marble turbulence 0.65 octaves 7 omega 0.7 lambda 2 } finish{ phong .1} } translate<300,0,0>}

En el presente proyecto se ha realizado un soporte para la tarjeta USBDemo Board. Dicha soporte lo ha realizado el Sr. Antonio del taller de Tecnun, y se ha tratado de dibujar en 3D en las tarjetas. Para ello se ha de insertar el siguiente cdigo y si procede, modificar los elementos en negrita para variar su tamao.

box {<-44,-12,-44.7> // Esquina delantera inferior izquierda <+44,-6,+44.7> // Esquina trasera superior derecha pigment { rgb <0.55, 0.5, 0.45> } finish{ambient .2 diffuse .6 phong .75 phong_size 25} }

137

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se han dibujado las tuercas y arandelas de la forma siguiente. Para adaptar este cdigo a las dimensiones de cualquier tarjeta que se cree, se ha de modificar el cdigo que se presenta en negrita, que representa las posiciones (x,y) del binomio arandela tuerca.

#local pos_X1 = -37.65; #local pos_X2 = 35; #local pos_X3 = 35; #local pos_X4 = -37.65; #local pos_Z1 = -37.5; #local pos_Z2 = -37; #local pos_Z3 = 37; #local pos_Z4 = 37.5; // Arandelas // trasera izda difference{ cylinder { <0,0,0> <0,0.5,0> 3.5 pigment{Gray20} texture {Silver1} } cylinder { <0,0,0> <0,1,0> 1.3 pigment{Gray20} texture {Silver1} } translate<pos_X1,0,pos_Z1>} // Trasera derecha difference{ cylinder { <0,0,0> <0,0.5,0> 3.5 pigment{Gray20} texture {Silver1} } cylinder { <0,0,0> <0,1,0> 1.3 pigment{Gray20} texture {Silver1} } translate<pos_X2,0,pos_Z2>} // delantera derecha difference{ cylinder { <0,0,0> <0,0.5,0> 3.5 pigment{Gray20} texture {Silver1} } cylinder { <0,0,0> <0,1,0> 1.3 pigment{Gray20} texture {Silver1} } translate<pos_X3,0,pos_Z3>} // delantera izda difference{ cylinder { <0,0,0> <0,0.5,0> 3.5 pigment{Gray20} texture {Silver1} } cylinder { <0,0,0> <0,1,0> 1.3 pigment{Gray20} texture {Silver1} } translate<pos_X4,0,pos_Z3>}

138

Anejo 1

SOFTWARE

// Tuerca y tornillo // Trasera izda merge{ difference { prism {linear_sweep linear_spline 0,4.99,7, <3.2,4.7>,<-3.2,4.7>,<-5.3,0>,<3.2,-4.7>,<3.2,-4.7>,<5.3,0>,<3.2,4.7> pigment{Gray35}} cylinder{<0,-1,0>,<0,5,0>,3 texture {Polished_Chrome}} scale 0.5} cylinder{ <0,-10,0>,<0,3,0> 1.5 texture {Chrome_Metal} } translate<pos_X1,0,pos_Z1>} // Trasera derecha merge{ difference { prism {linear_sweep linear_spline 0,4.99,7, <3.2,4.7>,<-3.2,4.7>,<-5.3,0>,<3.2,-4.7>,<3.2,-4.7>,<5.3,0>,<3.2,4.7> pigment{Gray35}} cylinder{<0,-1,0>,<0,5,0>,3 texture {Polished_Chrome}} scale 0.5} cylinder{ <0,-10,0>,<0,3,0> 1.5 texture {Chrome_Metal} } translate<pos_X2,0,pos_Z2>} // delantera derecha merge{ difference { prism {linear_sweep linear_spline 0,4.99,7, <3.2,4.7>,<-3.2,4.7>,<-5.3,0>,<3.2,-4.7>,<3.2,-4.7>,<5.3,0>,<3.2,4.7> pigment{Gray35}} cylinder{<0,-1,0>,<0,5,0>,3 texture {Polished_Chrome}} scale 0.5} cylinder{ <0,-10,0>,<0,3,0> 1.5 texture {Chrome_Metal} } translate<pos_X3,0,pos_Z3>} // delantera izda merge{ difference { prism {linear_sweep linear_spline 0,4.99,7, <3.2,4.7>,<-3.2,4.7>,<-5.3,0>,<3.2,-4.7>,<3.2,-4.7>,<5.3,0>,<3.2,4.7> pigment{Gray35}} cylinder{<0,-1,0>,<0,5,0>,3 texture {Polished_Chrome}} scale 0.5} cylinder{ <0,-10,0>,<0,3,0> 1.5 texture {Chrome_Metal} } translate<pos_X4,0,pos_Z4>}

139

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Las tarjetas, por lo general no se crean con los logos de los componentes. stos deben ser insertados modificando el archivo de PovRay. Para ms informacin consultar el manual 3Dlogo de la carpeta 4 Manuales\Eagle 3D del CD adjunto. A continuacin se muestra el ejemplo del cdigo necesario para insertar el logo del microcontrolador en la imagen 3D de la tarjeta de ultrasonidos. Eagle3D utiliza un archivo de fuentes TrueType que se llama eagle3d, para crear dichos logos. El logo de microchip corresponde a la letra m. Se pueden consultar dichos logos en el archivo 3Dlogo del manual. En cada caso concreto hay que agrandar el logo, rotarlo y trasladarlo en el espacio para obtener los resultados esperados.

text{ttf

global_fontfile_eagle3d

"m"

0.2,0

scale<5.75,5.75,5.75>

rotate<90,90,0>

translate<-7.5,6.260,2> pigment{Khaki*0.75}}

A continuacin en la figura A1.17, se muestra una captura de pantalla en la que se muestra los excelentes resultados que se pueden obtener con la utilizacin de las libreras Eagle3D.

Figura A1.17 Resultado PCB 3D

140

Anejo 1

SOFTWARE

Anejo 1.4

PERSISTENCE OF VISION RAYTRACER POVRAY

Persistence of Vision Ray Tracer es un trazador de rayos que crea imgenes tridimensionales fotorrealistas. Lee un archivo de texto que contiene informacin que describe objetos e iluminacin en una escena y genera una imagen de esa escena desde el punto de vista de una cmara, tambin descrita en el archivo de escena. Se puede descargar el manual en formato HTML en la pgina del software 16. Los detalles de la programacin en PovRay se detallan en el mencionado manual. A continuacin se muestra una imagen del software PovRay.

Figura A1.18 Software PovRay

16

http://www.povray.org/documentation/

141

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 1.5 VISUAL BASIC v6.0


Visual Basic es un lenguaje de programacin desarrollado por Alan Cooper para Microsoft. El lenguaje de programacin es un dialecto de BASIC, con importantes aadidos. Visual Basic constituye un IDE (entorno de desarrollo integrado o en ingls Integrated Development Environment) que ha sido empaquetado como un programa de aplicacin, es decir, consiste en un editor de cdigo (programa donde se escribe el cdigo fuente), un depurador (programa que corrige errores en el cdigo fuente para que pueda ser bien compilado), un compilador (programa que traduce el cdigo fuente a lenguaje de mquina), y un constructor de interfaz grfica o GUI (es una forma de programar en la que no es necesario escribir el cdigo para la parte grfica del programa, sino que se puede hacer de forma visual). Para crear la aplicacin cliente del presente proyecto se ha creado un proyecto estndar.

Figura A1.19 Software Visual Basic 142

Anejo 1

SOFTWARE

En la figura A1.20 se muestra la pantalla de programacin GUI de Visual Basic. El men izquierdo remarcado con color color rojo es el contenedor de los controles que se pueden insertar en la ventana grafica. El men de la derecha corresponde a las propiedades de los controles. En la parte inferior se listan el conjunto de ventanas que se han creado en el proyecto.

Figura A1.20 Software Visual Basic

Anejo 1.6 WAVESTAR TEKTRONIX


Es un software desarrollado por Tektronix que permite visualizar en la pantalla del ordenador imgenes paradas con la funcin Trigger del osciloscopio. El software es de sencillo uso tenindose solo que configurar el nmero de puerto COM utilizado por el osciloscopio.

143

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El osciloscopio digital utilizado en el taller es el Tektronix TDS 220(Digital Real Time Osciloscope 2 channels). Este osciloscopio presenta una salida RS232 que permite mostrar capturas del osciloscopio en el ordenador.

Debido a que el proyecto en su integridad se ha realizado en un ordenador porttil, y que ste no dispone del casi obsoleto puerto RS232, se ha tenido que utilizar el Conversor RS232-USB Targus modelo PA088E. Este dispositivo es un conversor RS232 a USB. Este dispositivo, salvando las diferencias es similar a los creados en el presente proyecto. Utiliza el mismo driver usbser.sys que utilizan las tarjetas del proyecto. Adems aparece en el administrador de dispositivos del sistema operativo como COM virtual al igual que en el presente proyecto. Se ha de configurar el conversor con un puerto que acepte el software Wavestar.

Figura A1.21 Software Wavestar

Para configurar el software hay que elegir el osciloscopio utilizado y el puerto serie que utiliza. Para definir estos parmetros hay que ir al men Instrument/Select del que se desprende la siguiente ventana.

144

Anejo 1

SOFTWARE

Figura A1.22 Configuracin Wavestar

Tras elegir el puerto utilizado y el osciloscopio preciso, se debe pulsar el botn de Test que testea la comunicacin entre ambos. El osciloscopio y el PC entran en comunicacin cuando se ha pasado el test y a partir de ese momento se pueden ir tomando muestras de la pantalla del osciloscopio. Para adquirir una captura se ha interactuar con el men Instrument/Acquire.

En la realizacin del proyecto no se dispona del cable rs232 en el taller y se hubo que realizar uno siguiendo el esquema siguiente.

Figura A1.23 Cable Rs23s comunicacin osciloscopio-PC

145

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 2. FASES DE CREACIN DE UN DISPOSITIVO USB


En el presente anejo, se presentan las tcnicas desarrolladas para la creacin de un dispositivo USB. Se detallan los aspectos que han sido considerados a la hora de disear las tarjetas. Se resumen a su vez los pasos de fabricacin de las tarjetas. Se presentan los ensayos realizados a las tarjetas, para comprobar su funcionamiento.

Anejo 2.1 DISEO


En esta fase se ha de disear el circuito electrnico que cumpla los requisitos planteados. Es aconsejable montar el circuito en una placa Protoboard, y posteriormente disearlo en el ordenador. Una vez que se ha testeado el correcto funcionamiento de la tarjeta, se puede pasar a la edicin del layout del circuito.

Figura A2.1 Placa Protoboard

146

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Anejo 2.2 FABRICACIN


En el presente apartado se detallan las operaciones, por orden cronolgico, que se han de llevar a cabo para realizar las tarjetas.

Anejo 2.2.1 Insolado


Una vez realizado el diseo de la tarjeta con un software de creacin de layouts, la siguiente fase en la realizacin de las tarjetas es la impresin del fotolito. Para ello se ha de utilizar la impresora lser o de chorro de tinta y papel de transparencia o papel cebolla. Una vez impreso el fotolito, es aconsejable comprobar con una regla milimtrica el tamao esperado de la placa. Es aconsejable repasar la impresin con un rotulador indeleble en las zonas crticas del circuito.

Figura A2.2 Insoladora y placa virgen positiva

Se han de apagar todas las luces de la habitacin antes de quitar el plstico protector de la placa virgen positiva PCB. Se debe colocar la cara descubierta de la PCB sobre la transparencia y boca abajo en direccin a las lmparas UV de la insoladora. El siguiente paso es cerrar la insoladora y programar para que la radiacin dure 3 minutos.

147

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 2.2.2 Revelado


Una vez que la placa est insolada se mete en la cubeta del revelador. Este proceso suele ser rpido, aunque depender directamente del estado en el que se encuentre el lquido revelador. El lquido revelador se puede conservar de una vez para otra hasta que va perdiendo su eficacia y se va oscureciendo.

La clave de un buen revelado est en sacar la placa en el momento exacto, que rondar el medio minuto. El siguiente paso es limpiar la placa bajo el chorro de agua del grifo. Se puede utilizar un pao suave para retirar las zonas oscuras que hayan podido quedar.

Anejo 2.2.3 Atacado


Tras el revelado y la limpieza de la placa, se ha de depositar en la cubeta del atacado y como en el caso anterior se ha de remover la cubeta. Una vez se ha finalizado el proceso se debe proceder a retirar la tarjeta con unas pinzas.

Con independencia del atacador que se use, conviene que se realice esta tarea en un lugar muy ventilado, y por supuesto que siempre se evite respirar cerca de los vapores que se generan, adems de evitar el contacto del atacador con piel y ropa.

Anejo 2.2.4 Mecanizado de placa y soldadura de los componentes


Una vez que la placa se ha secado del todo y antes de pasar a la siguiente fase de la construccin, es necesario recortar los bordes sobrantes para disminuir las medidas. En el taller se ha utilizado la guillotina disponible para tal efecto.

Es importante disponer, aunque no imperativo, de una guillotina para cortar las placas Si no se dispone de guillotina es aconsejable utilizar placa fotosensible positiva Bungard de 0,8mm, ms delgada y fcil de cortar.

148

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Figura A2.3 Guillotina Para el mecanizado de la PCB, se ha de utilizar un taladro con brocas de 0,8mm y 1mm. En el mercado existen multitud de taladros de tamao reducido. En el taller se ha utilizado el taladro de marquetera Dremel, muy popular y conocido tambin en el mundo electrnico. Se han de realizar los agujeros por donde se insertarn los componentes. Una vez completado todos los agujeros se ha de pasar a la fase de soldadura. Con un soldador comn, y con estao se deben soldar los componentes. Se han de soldar primero los componentes de poca altura, ya sea bien, resistencias, diodos, puentes para que no incomoden en la soldadura de los dems componentes. Es recomendable soldar zcalos para los circuitos integrados ya que su soldadura directa puede daarlos. En caso de necesidad de recambio son difciles de desoldar si no se han implementado los zcalos.

Anejo 2.2.5 Materiales y consideraciones


En el presente sub apartado se detalla el material de partida que es recomendable utilizar.

149

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Uno de los materiales que se debe utilizar es la placa de circuito con pelcula sensibilizada positiva. La designacin Sensibilizada Positiva quiere decir que la placa est recubierta con una pelcula de resina, sensible a la luz, y se utiliza con positivos del circuito impreso. Cuando la placa de circuito impreso virgen est recubierta de resina fotosensible es necesario protegerla de la luz. Para lograr esta proteccin algunos fabricantes aplican un recubrimiento plstico adhesivo. Consiste en una plancha base aislante, bakelita o fibra de vidrio, de diversos espesores, siendo los de 2mm, las ms comunes y utilizadas en el proyecto. El Revelador para la placa positiva es normalmente una solucin de sosa, se presenta en unos envases pequeos en forma de escamas. Se necesita atacador qumico para eliminar el sobrante de cobre en las placas. El agua se necesita para diluir el revelador, para lavar la placa y para diluir el cloruro frrico o los atacadores rpidos. El alcohol Industrial se necesita para limpiar la placa despus del lavado posterior al ataque qumico para eliminar los restos de resina. Cubetas, pinzas, brocha y papel absorbente concluyen la lista de materiales para la creacin de las placas de circuito impreso.

Consideraciones de seguridad NUNCA se debe tocar los qumicos con las manos sin proteccin, en especial el agua oxigenada y el Hcl. Para ello se debe usar los guantes de ltex y pinzas. NUNCA se debe respirar encima de las bandejas o en su defecto usar una mascarilla. Las bandejas han de estar colocadas sobre una superficie plana, horizontal y estable. Lavar con abundante agua todos los materiales una vez se ha finalizado el proceso.

150

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Anejo 2.3 ENSAYOS


En el presente anejo se muestran las diferentes pruebas realizadas para comprobar el correcto funcionamiento de las tarjetas y los sensores. Se ha obtenido la informacin de su funcionamiento particular, que debe servir de referente a la hora de crear un dispositivo USB basado en los microcontroladores PIC utilizados en el proyecto.

Se han hecho pruebas de consumo de potencia en las tarjetas de adquisicin de datos, en rgimen de funcionamiento normal con todos los sensores, as como los consumos en modo suspensin.

Se han realizado pruebas

para obtener la frecuencia de refresco necesaria para la

funcin USBTasks (Vase Capitulo 7 Software de control robot Hermes), que garantiza la configuracin y uso del dispositivo USB.

Se han realizado pruebas de medicin de los sensores de infrarrojos, con el objetivo de crear una tabla de calibracin de los mismos. Estas tablas deben ser utilizadas por el programa de control del PC.

Como se ha comentado en el captulo 6 Arquitectura y Hardware robot Hermes, en su apartado 6.2.6 Sensores infrarrojos de corto alcance GP2D12 y 6.2.7 Sensores infrarrojos de largo alcance GP2Y0A02YK, dichos sensores no son lineales, por lo que necesitan la creacin de una tabla de calibracin, que debe ser creada a partir de esta prueba.

Se ha analizado el coste computacional de los bucles de usuario del firmware USB, para adquirir la frecuencia de muestreo de los diferentes sensores utilizados. El algoritmo de control del PC debe tener en cuenta la frecuencia de refresco de los sensores, ya que no conserva ningn sentido pedir los valores de los sensores con una frecuencia superior a la de refresco.

151

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 2.3.1 Pruebas de consumo


Se han elaborado pruebas de consumo de potencia en las tarjetas de adquisicin de datos. Estas pruebas se han realizado alimentando las tarjetas con una fuente de alimentacin, alimentando a 5v.

Las pruebas en las tarjetas de gobierno y acondicionamiento de los drivers no han sido desarrolladas, puesto que stas no han sido programadas en el presente proyecto. En el CD adjunto al proyecto, en la carpeta 8. Videos/Consumo potencia tarjetas, se pueden visualizar diferentes filmaciones que corroboran los resultados obtenidos.

Los dispositivos USB desarrollados, presentan diferentes consumos de potencia segn sea su estado en el bus. Se distinguen diferentes consumos cuando las tarjetas se encuentran desconectadas del bus, conectadas al puerto y conectadas al bus con el ordenador en suspensin.

En cuanto a la tarjeta Hermes USB DemoBoard, se puede decir que, estando correctamente configurada por el sistema operativo y lista para realizar comunicaciones USB, presenta consumos de corriente 100mA. Esto supone un consumo de potencia de 0.5Watios. En este estado presenta un estado de parpadeo de los leds status RC1 y RC2.

En un estado de desconexin del puerto USB, el dispositivo reduce su consumo de corriente a 90mA, suponiendo un consumo de potencia de 0.45Watios. En este estado el led RC3 de los leds status parpadea indicando la desconexin de la tarjeta al bus USB.

Cuando se fuerza el PC a modo suspensin, en el men salir de Windows, el consumo de corriente se reduce a 60mA. Esto supone un consumo de potencia de 300mW. En este estado, el firmware programado en el PIC ejecuta la funcin sleep, haciendo que la CPU del microcontrolador deje de ser sealizada por el reloj oscilador, quedando en un estado de latencia. Antes de ejecutar dicha funcin se enciende el led status RC3 permanentemente para diferenciar este estado. De esta manera, se consigue que de una manera visual, se pueda detectar el estado USB de la tarjeta.

152

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Los perifricos del microcontrolador si son alimentados en este estado de latencia. Cuando el PC abandona el estado de suspensin, el microcontrolador se despierta gracias al modulo USB, que se encuentra continuamente alimentado por la seal de reloj.

En este modo de trabajo suspensin, se reduce el consumo de potencia en un 15%, lo que es muy importante al tratarse de un robot que funciona con bateras.

Los consumos de las tarjetas de infrarrojos y ultrasonidos tienes valores similares cuando trabajan sin los sensores conectados. Se puede decir entonces que el consumo de corriente bsico de tener el microcontrolador funcionando en rgimen normal, con los leds de status y atendiendo al bus USB es de 100mA.

Las pruebas de consumos de las tarjetas infrarrojos, trabajando con sus ocho sensores, presentan valores similares, independientemente del sensor utilizado, ya sea el GP2D12 o el GP2Y0A02YK.

La tarjeta de infrarrojos trabajando con los 8 sensores, en el estado de desconexin del puerto USB, presenta un consumo de corriente de 380mA, lo que supone un consumo de potencia de 1.9Watios. El consumo de corriente alcanza el valor de 400mA en estado de conexin lo que supone 2Watios de potencia. Si se fuerza el PC a su modo de suspensin, la tarjeta entra en latencia reduciendo su consumo de corriente hasta los 360mA y 1.8Watios de potencia.

La tarjeta Ultrasonidos presenta un consumo de corriente de 120mA y 0.6Watios en modo desconexin. En modo conexin su consumo se eleva hasta los 140mA y 0.7Watios. En modo suspensin presenta un consumo de 100mA y 0.5Watios.

153

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 2.3.2 Frecuencia de refresco USBTasks


En la presente prueba se ha comprobado la frecuencia de refresco necesaria de USBTasks para mantener activa la comunicacin USB. La prueba consiste en construir un firmware vacio solo con la funcin USBTasks y posteriormente implementar un delay en el que se le modifique el nmero de ciclos instruccin que espera. Se modifica el argumento de la funcin de espera hasta que se el dispositivo se desconfigura y deja de estar listo para usar. La operacin realizada es la siguiente. USBTasks; Delay1KTCTx(23);

Con una sencilla accin de prueba-error se ha definido que aproximadamente esta funcin USBTasks, debe refrescarse antes de 23000 ciclos de instruccin. El ciclo de instruccin es el tiempo que demora en ejecutarse una instruccin, es decir el tiempo que demora en pasar de una lnea a otra lnea de programa, dentro de la memoria Flash.

Un ciclo de instruccin es igual a 4 ciclos de reloj y el ciclo de reloj lo define el oscilador externo al PIC. En el proyecto se han implementado en los microcontroladores osciladores de cristal de cuarzo de frecuencia de 48Mhz. De esta manera el ciclo de reloj es 1/48 = 0.02083 microsegundos. Por lo tanto el ciclo de instruccin ser 4x0.02083 = 0.083 microsegundos. La rutina USBTasks se debe refrescar cada 1.909 milisegundos, lo que quiere decir que su frecuencia de muestreo debe ser superior a 523Hz.

154

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Anejo 2.3.3 Pruebas coste computacional


Se han realizado las pruebas de costes computacionales haciendo uso de una salida digital del PIC programada para la prueba y el osciloscopio TDS220. Se ha realizado dicha prueba para medir los costes computacionales de los bucles ms representativos de los diferentes cdigos de los microcontroladores.

A continuacin se muestran las pruebas de costes computacionales de la tarjeta Hermes USBDemo. Esta prueba se ha realizado con una salida digital que invierte su valor actual al entrar en el bucle y lo vuelve a invertir al salir del mismo, tal y como se muestra en el siguiente cdigo. Midiendo esta salida en el osciloscopio se es capaz de calcular aproximadamente el tiempo que se consume en realizar dicho bucle.

While(1) {USBTasks; Led_Rc2_Toggle(); ProcessIO; Led_Rc2_Toggle();}

Figura A2.4 Periodo firmware USB Demo Board

155

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El periodo de la seal es de aproximadamente 45 microsegundos tal y como se muestra en la figura A2.4. Cabe destacar, que el estado alto demora 7.5 microsegundos, lo que supone un 15% del periodo total. Este es el coste computacional de la funcin USBTasks, que a resultado de valores similares en todas las tarjetas. Esta funcin ha sido creada eficazmente, por los ingenieros de Microchip, ya que tiene un coste computacional bajo. El estado bajo representa la funcin ProcessIO, que es el bucle destinado para el usuario. En este bucle se hace un refresco de los switches implementados en esta tarjeta. A su vez se adquiere y se ejecutan las peticiones del PC. Cabe destacar que esta funcin de usuario es muy liviana, ya que solo ha de revisar ocho valores digitales. Esto hace que el firmware no requiera de una interrupcin por timer para hacer el refresco de USBTasks. En la figura A2.5 se muestra el coste computacional de la funcin ProcessIO de la tarjeta USB Demo Board.

Figura A2.5 Costes computacionales ProcessIO USB Demo Board

156

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

A continuacin se muestran los resultados de las pruebas de costes computacionales realizadas en la tarjeta Hermes USB Infrarrojos. La siguiente captura de pantalla A2.6 muestra el resultado obtenido de la siguiente operacin:

While(1) {USBTasks; Led_Rc2_Toggle(); ProcessIO; Led_Rc2_Toggle();}

Figura A2.6 Costes computacionales Hermes USB Infrarrojos

El bucle entero se ejecuta cada 295 microsegundos aproximadamente, a una frecuencia de 3.3KHz. Esta es la frecuencia de refresco de la funcin USBTasks. La frecuencia de refresco de esta funcin es menor que en el caso anterior, pero todava es suficiente para mantener activo el bus USB. (Vase anejo 2 Apartado A2.4.2 Frecuencia de refresco USBTasks). Se puede apreciar que respecto al firmware de la tarjeta USBDemo Board, el bucle de usuario es ms lento. Esto tiene un carcter lgico, porque dentro de ProcessIO se 157

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

ejecutan las operaciones de conversin A/D, con sus tiempos de adquisicin y conversin, que le hacen retardarse. Como ya se ha comentado el bucle total de la tarjeta USBDemo Board consume 45 microsegundos frente a los 295 microsegundos de este firmware. Se ha hecho un anlisis del bucle de adquisicin de los ocho sensores de infrarrojos con la funcin itoa y sin ella. (Vase capitulo 7 Software de control robot Hermes).

While(1) {Led_Rc2_Toggle(); for (a=1;a<9;a++){Lectura_sensor(a);} Led_Rc2_Toggle();} void Lectura_sensor (int a) { // switch(a){ case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8: SetChanADC(Sensor1);break; SetChanADC(Sensor2);break; SetChanADC(Sensor3);break; SetChanADC(Sensor4);break; SetChanADC(Sensor5);break; SetChanADC(Sensor6);break; SetChanADC(Sensor7);break; SetChanADC(Sensor8);break; } --- Eleccin del canal analgico a leer ---

// ----------------------------------------------Delay1TCY(50); ConvertADC(); // Espera para tiempo adquisicin // Start conversion.

while(BusyADC()); // Wait for ADC conversion temp[a-1] = ReadADC(); // Lectura del sensor elegido // itoa(temp[a-1],tx_buffer); // Esta funcin se comenta y se descomenta }//end Lectura_dato

158

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

A continuacin en las figuras A2.7 y A2.8 se muestra la comparacin de capturas del osciloscopio sin la funcin itoa y con ella respectivamente.

Figura A2.7 Costes computacional bucle adquisicin sin itoa Hermes USB Infrarrojos

Figura A2.8 Costes computacional bucle adquisicin con itoa Hermes USB Infrarrojos

159

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se puede apreciar que la influencia de la funcin itoa, para pasar el valor digital de la seal a ASCII, es muy grande. Esto es debido a que esta funcin, es genrica del estndar C ANSI y se demora mucho tiempo en ejecutarse. A continuacin se hace un anlisis del tiempo que tarda cada sensor en adquirir su valor convertido.

Figura A2.9 Costes computacional cada sensor sin itoa Hermes USB Infrarrojos

Figura A2.10 Costes computacional cada sensor con itoa Hermes USB Infrarrojos

160

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Cada sensor tarda 66 microsegundos en adquirir y convertir el valor analgico por aproximaciones sucesivas, mientras que con la conversin a ASCII tarda 230 microsegundos. Esto aporta la informacin de que la funcin itoa consume cerca de 164 microsegundos por sensor. Por todas estas razones se ha adoptado otra estrategia de programacin respecto a esta funcin. (Ver capitulo 7 Software de control Robot Hermes). Se ha analizado la frecuencia de refresco de los sensores infrarrojos trabajando con el USB. A continuacin se muestra la captura de pantalla obtenida al aplicar el siguiente bucle.

While(1) {USBTasks; Led_Rc2_Toggle(); ProcessIO; Led_Rc2_Toggle();}

Figura A2.11 Frecuencia de refresco sensores infrarrojos Hermes USB Infrarrojos

161

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Se puede apreciar que cada 589 microsegundos se muestrean los ocho sensores, es por ello que el conjunto de los ocho sensores se refresca con una frecuencia de 1697Hz.

Anejo 2.3.4 Pruebas de consumo de memoria


La memoria de programa y de datos no ha supuesto ninguna restriccin en el presente proyecto. Este dato se puede obtener en el men View/Memory Usage del software de programacin MPLAB.

Figura A2.12 Memory Usage MPLAB

En la figura A2.13 se expone el consumo de memoria del cdigo completo de las tres tarjetas programadas en el presente proyecto. Cabe precisar que en los tres casos, el gasto de memoria que se expone es la memoria de programa expresada en nmero de instrucciones (2 bytes), y la memoria de datos expresada en bytes.

El PIC dispone de 32Kbytes de memoria de programa flash y 2Kbytes de memoria de datos. Se puede apreciar en la figura A2.13 que la tarjeta de ultrasonidos presenta el

162

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

cdigo ms extenso, debido a la creacin de la librera de manejo del protocolo I2C. En cualquier caso, el cdigo no representa ms del 20% de la capacidad del PIC.

Figura A2.13 Uso de memoria firmware USB

Anejo 2.3.5 Tablas de calibracin de los sensores de infrarrojos


La presente prueba se ha realizado con la tarjeta esclava infrarrojos con los sensores GP2D12 y GP2Y0A02YK. Se ha realizado un ensayo de medicin con la tarjeta y el sensor, con la aplicacin Visual Basic creada en el presente proyecto. Se han tomado 40 medidas para cada distancia y se ha calculado la media de los valores obtenidos. Se ha introducido esos valores en el software Matlab y se ha graficado.

Se puede apreciar en las figuras A2.14 y A2.15, como es de esperar, que siguen las grficas de calibracin del fabricante (Vase Capitulo 6 Arquitectura y Hardware robot Hermes figura 6.27). El eje de ordenadas representa los valores del sensor analizado, que han sido recibidos por la aplicacin de Visual Basic en el ordenador. El eje de abscisas representa la distancia del sensor al obstculo medida en centmetros.

163

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

El sensor GP2D12, tal y como se especifica en el manual del fabricante, tiene un rango de operacin de 10 a 80 centmetros, pero en la prctica se puede utilizar el rango de 8 a 95 centmetros, distancia a partir de la cual los valores se mantienen constantes.

El algoritmo de control en el robot deber de tener en cuenta esta grfica para hacer su tabla de calibracin debido a que la respuesta del sensor no es lineal. En el CD adjunto al proyecto, en la carpeta 2. - Anejos electrnicos\ Programas\ Graficas Calibracin Matlab se ofrece el script realizado en el software Matlab, para crear las dos grficas de calibracin de los sensores de infrarrojos GP2D12 y GP2Y0A02YK.

Figura A2.14 Grfica de calibracin sensor GP2D12

164

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Figura A2.15 Grfica de calibracin sensor GP2Y0A02YK

En el mencionado script, se disponen de cuatro vectores de datos, necesarios para crear la tabla de calibracin de los sensores GP2D12 y GP2Y0A02YK. Para cada sensor se dispone de dos vectores, uno que representa los valores de distancia en centmetros y otro vector que representa los valores transmitidos por USB.

Para el sensor GP2D12 se dispone de los vectores centmetros_GP2D12 y Valores_sensor_GP2D12, mientras que los vectores del sensor GP2Y0A02YK son centmetros_ GP2Y0A02YK y Valores_sensor_ GP2Y0A02YK.

165

Gerardo Dez del Campo

Arquitectura de control distribuida por protocolo USB

Anejo 2.3.6 Pruebas de velocidad de escritura USB clase CDC


En el presente anejo se muestran los resultados obtenidos en las pruebas de velocidad de escritura mxima en el bus USB, conseguidas por los dispositivos programados. Las especificaciones de clase CDC exponen que la mxima velocidad de escritura/lectura del bus es de 80kbytes/s. En la prueba realizada se ha comprobado la velocidad de escritura mxima alcanzable en nuestro caso. Se ha programado un firmware limpio en el que se ejecuta la rutina USBTasks y escribe continuamente en el bus, tal y como se muestra a continuacin. Se ha ejecutado dicha prueba con el Hyperterminal de Windows que lee del bus continuamente. De esta manera se obtiene la velocidad mxima de escritura alcanzable por las tarjetas esclavas. While (1) { USBTasks(); if((usb_device_state return; Led_Rc2_Toggle(); SendRespData(HermesUSB Infrared); Led_Rc2_Toggle();} < CONFIGURED_STATE)||(UCONbits.SUSPND==1))

Esta prueba se ejecuta si el dispositivo se encuentra configurado o no se encuentra en estado de suspensin. Continuamente y sin peticin del maestro el dispositivo escribe en el bus. Escribe una cadena de caracteres de 18bytes, que se mandan con una frecuencia de 4300Hz aproximadamente, tal y como se puede apreciar en la figura A2.16. Esto supone una escritura de 78260 bytes por segundo cercana a los 80kbytes que especifica el estndar.

166

Anejo 2

FASES CREACIN DE UN DISPOSITIVO USB

Figura A2.16 Grfica de escritura en el bus USB

167

Você também pode gostar