Implementacion De Comunicacion Usb Con Un Microcontrolador Pic 18f2550 6q2q5j

INSTITUTO POLITECNICO NACIONAL ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA ZACATENCO

ING. EN CONTROL Y AUTOMATIZACION

REPORTE DE IMPLEMENTACION DE COMUNICACIÓN USB CLASE CDC EN UN MICROCONTROLADOR PIC18F4550 EN CCS

PROFESOR: Adrián Mendoza

Realizo: Esteban Guerrero Rivero

Contenido INTRODUCCION................................................................................................ 4 Descripción general..................................................................................... 4 ESPECIFICACIONES USB.................................................................................. 5 Medio físico................................................................................................... 5 Terminales..................................................................................................... 5 Tipos de transferencia................................................................................. 6 Velocidades de transmisión........................................................................6 Descriptores.................................................................................................. 7 

Descriptor del dispositivo.................................................................8



Descriptor de la configuración........................................................10



Descriptores de la interfaz..............................................................12



Descriptor de cadena.......................................................................14

Endpoints del dispositivo..........................................................................15 Normas......................................................................................................... 15 

Resumen de la norma “CDC120-20101103”.................................17



Comunicación device class..............................................................18



AN1164 USB clase CDC para dispositivos embebidos.................19

IMPLEMENTACION DE COMUNICACIÓN USB EN UN MICROCONTROLADOR PIC18F4550.............................................................20 Requerimientos.......................................................................................... 20 Descripción general del módulo USB en el PIC18F4550.....................20 FUNCIONES DEL OSCILADOR PARA COMUNICACIÓN USB.....................24 Librerías de CCS......................................................................................... 25 Descriptores................................................................................................ 29 Programas de generación de descriptores y archivos .inf..................31 DRIVER............................................................................................................ 33 Descripción general................................................................................... 33 Servicio Plug & Play de Windows............................................................34 de dispositivos.................................................................34 Creación del instalador del controlador con INSTALLSHIELD.............35 IMPLEMENTACION.......................................................................................... 42 Programa de ejemplo............................................................................................ 42 Circuito......................................................................................................... 45

Simulación................................................................................................... 46 Prueba.......................................................................................................... 47

INTRODUCCION

El presente trabajo abarca la implementación de la comunicación USB en un microcontrolador tipo PIC18F4550 en el ambiente de programación PICC de CCS para el intercambio de información con una computadora personal empleando el modo SERIAL de la clase CDC (Comunication device class)

Descripción general El USB (Universal Serial Bus) es un estándar industrial desarrollado en la década de las 90’s que define los cables, conectores y protocolos usados en un bus para conectar, proveer alimentación eléctrica entre ordenadores, periféricos y dispositivos electrónicos

En el presente trabajo se abordara la parte teórica e las comunicaciones USB, la implementación de la comunicación USB empleando un microcontrolador, el uso e instalación del driver necesario para el funcionamiento de la interfaz así como la implementación de un circuito funcional para enviar y recibir información por el puerto USB.

ESPECIFICACIONES USB Medio físico Las señales de USB se transmiten en un cable de par trenzado con impedancia característica de 90Ohms, cuyos hilos se denominan D+ Y D-. Este puerto solo ite la conexión de dispositivos de bajo consumo, es decir, que tengan un consumo máximo de 500 m A. El calibre típico de este tipo de cables es el 26AWG, además en la norma USB 2.0 se especifica una longitud máxima de 5m y para la norma USB 3.0 una longitud máxima de 3m.

Terminales PIN 1 2 3 4

SEÑAL VCC DataData+ GND

COLOR Rojo Blanco Verde Negro

Pines en los distintos tipos de conectores

DESCRIPCION +5V DataData+ Tierra

Tipos de transferencia Existen 4 tipos de transferencia de información definidos en las especificaciones técnicas del USB



ISOCHRONOUS: Este método se emplea para grandes cantidades de datos (más de 1023bytes), con tiempo de entrega asegurado, sin embargo la integridad de la información no puede asegurarse del todo, es comúnmente empleado en aplicaciones de audio



BULK: Este tipo de método de transferencia es empleado para transmitir grandes cantidades de información, la integridad de la información es asegurada, no así el tiempo de entrega.



INTERRUPT: Este tipo de transferencia asegura el tiempo de entrega para pequeños bloques de datos, además es asegurada la integridad de la información



CONTROL: Permite la configuración del dispositivo

Velocidades de transmisión USB (1.0): Tasa de transferencia de hasta 1.5 Mbit/s, es el más empleado en dispositivos de interfaz humana (HID). Pero es en esta sección

USB (1.1): Tasa de transferencia de hasta 12 Mbit/s, esta fue la más rápida hasta la implementación del protocolo 2.0

USB (2.0): Tasa de transferencia de 480 Mbit/s, casi todos los dispositivos fabricados en la actualizad trabajan bajo este protocolo.

USB (3.0): Tasa de transferencia de 4.8Gbit/s, la velocidad del bus es más rápida debido a que se han incluido os adicionales

Descriptores Como se describió anteriormente, durante la enumeración el anfitrión usa transferencia de control para solicitar descriptores del dispositivo, como la enumeración progresa, los descriptores solicitados van dando cada vez más información del dispositivo, primero de todo el dispositivo, luego de cada configuración, la interface de cada configuración y finalmente los endpoint’s de las interfaces, en la siguiente tabla se muestran los tipos de descriptores.

bDescriptor Type 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh

Tipo de descriptor ¿Es necesario? dispositivo configuración cadena interfaz endpoint calificador del dispositivo otra config. De velocidad energía de la interfaz OTG debug asociación de la interfaz

SI SI Opcional SI No (si el disp. Solo usa el endpoint 0) Si Si No (si el disp. Solo usa el endpoint 0) On the go No (si el disp. Solo usa el endpoint 0) Opcional

Los descriptores de alto nivel informan al anfitrión de cualquier descriptor adicional de bajo nivel, a excepción de los dispositivos compuestos, cada dispositivo tiene un solo descriptor que contiene la información del dispositivo como un todo y especifica el número de configuraciones que soporta el dispositivo. Cada dispositivo también contiene uno o más descriptores de configuración que contienen información acerca del consumo de energía del dispositivo y el número de interfaces soportadas por la configuración. Cada descriptor de la interface especifica cero o más descriptores de endpoint’s que contienen la información necesaria para comunicarse con un endpoint. Cada descriptor de endpoint tiene información acerca de cómo el endpoint transfiere los datos, una interfaz sin descriptores de endpoint debe emplear el punto final de control para las comunicaciones.

Un descriptor de cadena puede almacenar texto como el nombre del vendedor o el nombre del dispositivo, otros descriptores pueden contener valores de índice que apuntes a esos descriptores de cadena y el anfitrión puede leer estos con una solicitud Get_Descriptor. En el valor del descriptor “bDescriptorType”, el bit7 siempre es cero. El bit 6 y 5 identifican el tipo de descriptor: 00h=estándar, 01h=class, 02h=fabricante, 03h=reservado, y los bits 4:0 identifican el descriptor. Cada descriptor consta de una serie ce campos. La mayoría de los nombres de campo usan prefijos que indican el formato o el contenido en ese campo: b=byte (8 bits), w=Word (16 bits), bm=bit map, bcd= binary-coded decimal, i=index, id=identificador.

 Descriptor del dispositivo El descriptor del dispositivo contiene información básica acerca del dispositivo, este descriptor es el primero leído por el anfitrión al conectar el dispositivo e incluye la información que el anfitrión necesita para solicitar información adicional del dispositivo. El anfitrión solicita el descriptor del dispositivo mandando la instrucción Get_Descriptor con el bit MSB del campo wValue en 1. El descriptor contiene 14 campos. La siguiente tabla muestra los campos en el orden en que estos se presentan.

offset (decimal) 0 1

Field

Size (bytes) 1 1

8 10 12 14

bLength bDescriptorTyp e bcdUSB bDeviceClass bDeviceSubcla ss bDeviceProtoco l bMaxPacketSiz e0 idVendor idProduct bcdDevice iManufacturer

15

iProduct

1

16

iSerialNumber

1

2 4 5 6 7

Descripción Tamaño del descriptor en bytes La constante DEVICE (01h)

2 1 1

Numero de la versión de USB (BCD) Código de Clase Código de Subclase

1

Código de protocolo

1

Tamaño máximo del paquete para el endpoint 0 Vendor ID Product ID Número de la versión del dispositivo (BCD) Índice de la cadena descriptora del fabricante Índice de la cadena descriptora del producto Índice de la cadena descriptora del número de serie

2 2 2 1

17

bNumCofigurati ons

        

 







1

Numero de configuraciones posibles

bLength : La longitud en bytes del descriptor bDescriptorType : La constante DEVICE (01h) bcdUSB : La versión de la especificación USB sobre la cual está basado el dispositivo y los descriptores del mismo, en formato BCD. La versión 1.0 es 0100h, la 1.1 es 0110h y la versión 2.0 es 0200h. idVendor: del USB-IF y otros quienes pagan tarifas istrativas tienen derecho a usar un código único, el anfitrión debe tener un archivo INF que contiene este valor, y así Windows es capaz de decidir que driver asignarle al dispositivo. idProduct: El dueño del VID puede asignarle un identificador al producto, esta información también debe hallarse en un archivo INF para determinar el driver a instalar. bcdDevice : El número de versión del dispositivo se encuentra en formato BCD, el vendedor asigna este valor, el anfitrión puede hacer uso también de este dato como información adicional para elegir el driver apropiado a instalar. iManufacturer : Es un índice que apunta a una cadena la cual describe el fabricante, este valor es cero si no hay un descriptor del fabricante. iProduct : Es un índice que apunta a una cadena descriptora del producto, este valor es cero si no existe tal cadena. iSerialNumber : Es un índice que apunta a una cadena descriptora la cual contiene un número de serie del dispositivo, este valor es cero si no existe tal cadena. Algunas clases de dispositivos como los dispositivos “mass storage” requieren números de serie, esos son de ayuda si el cuenta con dispositivos idénticos bNumConfigurations : El número de configuraciones que soporta el dispositivo bMaxPacketSize0 : El máximo tamaño de paquete para el endpoint 0. El anfitrión emplea esta informacion de la siguiente manera, para dispositivos de baja velocidad este valor debe ser 8, para dispositivos de “Full-speed” se pueden emplear valores de 8, 16, 32 o 64, los dispositivos de alta velocidad deben emplear el valor de 64 bDeviceClass : Para dispositivos cuya función se encuentra definida a un nivel de dispositivo, este campo especifica la clase del dispositivo. Los valores desde 1 hasta FEh se encuentran reservados para clases definidas. La siguiente tabla muestra los códigos definidos. El valor FFh significa que la clase es específica para el fabricante y se encuentra definida por el mismo. Muchos dispositivos especifican su clase o clases en los descriptores de la interface, y para estos dispositivos el campo bDeviceClass en el descriptor del dispositivo es 00h bDeviceSubclass : Este campo puede especificar una subclase dentro de una clase, si bDeciveClass es 0, el campo bDeviceSubclass debe ser igualmente 0. Si el campo bDeviceClass es u número entre 1 y FEh, bDeviceSubclass debe ser un código definido en una especificación de clase USB. bDeviceProtocol : Este campo puede especificar un protocolo definido por la clase o la subclase.

bDeviceC lass 00h 02h 09h DCh E0h Efh FFh

Descripción El descriptor de la interface nombra la clase Comunicaciones Hub Dispositivo de diagnostico Controlador inalámbrico Dispositivo genérico Especifico del fabricante

Opciones para bDeviceClass

 Descriptor de la configuración

Después de recibir la información del descriptor del dispositivo, el anfitrión puede solicitar la configuración del dispositivo, de la interface y del endpoint. Cada dispositivo tiene al menos una configuración que especifica las características y funcionalidades del dispositivo. Por lo general una sola configuración es suficiente, pero un dispositivo con múltiples modos de funcionamiento puede soportar diversos modos de configuración. Solo una configuración está activa. Cada configuración requiere su propio descriptor. El descriptor de la configuración contiene información acerca del uso de energía y de los números de interfaces soportadas por el dispositivo. El anfitrión selecciona una configuración con la instrucción Set_Configuration y lee la configuración actual con la instrucción Get_Configuration El descriptor contiene 8 campos, la siguiente tabla muestra los campos en el orden en que ocurren en el descriptor, los campos contienen información acerca del descriptor en sí, la configuración y los requerimientos energéticos del dispositivo para esa configuración en particular.

OFFSE T (DECI MAL) 0 1 2

CAMPO

SIZE (BYT ES)

DESCRIPCION

bLength bDescriptorTy pe wTotalLength

1 1

Tamaño del descriptor en bytes La constante CONFIGURATION (02h)

2

El número de bytes en el descriptor de la configuración

4

1

Numero de interfaces en la configuración

1

6

bNumInterfac es bConfiguratio nValue iConfiguration

7

bmAttributes

1

8

bMaxPower

1

Identificador para las instrucciones Set_Configuration y Get_Configuration Índice de la cadena del descriptor de configuración Características de alimentación Propia/Del Bus y "remote awake" Corriente requerida (expresada en Max mili amperes/2)

5

   

  



1

bLength : La longitud en bytes del descripto bDescriptorType: La constante CONFIGURATION (02h) wTotalLength : El número de bytes en el descriptor de la configuración y todos los descriptores subordinados bConfigurationValue : Identifica la configuración para los requerimientos de las instrucciones Get_Configuration y SetConfiguration, debe ser 1 o mayor. Una requisición de la instrucción SetConfiguration con un valor de retorno de cero casusa que el dispositivo entre e3n un estado no configurado. iConfiguration : Es un índice que apunta a una cadena la cual describe la configuración, este valor es cero si no existe tal cadena bNumInterfaces : El número de interfaces en la configuración, el mínimo es 1. bmAttributes. Bit6=1 si el dispositivo tiene alimentación propia o 0 si es alimentado a través del bus USB, el bit 5=1 si e dispositivo soporta la función “remote awake” (Función para encender el dispositivo mediante una orden del anfitrión). Un dispositivo USB debe entrar en modo de suspensión si no ha habido actividad del bus por más de 3 milisegundos. Los demás bits en el campo no se emplean, los bits 0:4 deben ser 0. El bit 7 debe ser 1. bMaxPower : Especifica cuanta corriente requiere el dispositivo, este valor equivale a la mitad del número de mili amperes requeridos. Si el dispositivo requiere 200 mili amperes el valor de este registro deberá ser 100. La corriente máxima que un dispositivo puede solicitar es 500miliamperes. Guardar el registro con la mitad de la capacidad requerida permite almacenar este dato en un solo byte. Si la corriente requerida no se encuentra disponible, el anfitrión se negara a configurar el dispositivo.

 Descriptores de la interfaz El descriptor de la interface provee información acerca de una función o característica que un dispositivo implementa. El descriptor contiene clases, subclases, información del protocolo y el número de endpoint que la interfaz emplea. Una configuración puede tener múltiples interfaces, las cuales pueden estar activas al mismo tiempo, las interfaces puedes estar asociadas con una sola función o pueden no estar relacionadas entre si. Una configuración puede además soportar una interfaz alternativa, mutuamente exclusiva. El anfitrión puede solicitar una interfaz alternativa con una solicitud Set_Interface y leer la interfaz actual con la instrucción Get_Interface. Un descriptor de interface contiene 9 campos, la siguiente tabla muestra los campos en el orden en que estos ocurren en el descriptor. Muchos dispositivos no emplean todos los valores de los campos.

OFFSET (DECIMAL) 0 1 2

CAMPO bLength bDescriptorTyp e bInterfaceNum

SIZE DESCRIPCION (BYTES) 1 Tamaño del descriptor en bytes 1 La constante Interface (04h) 1

El numero identificador de la interface

ber bAlternateSetti ngs bNumEndpoint s bInterfaceClas s bInterfaceSubc lass bInterfaceProt ocol iInterface

3 4 5 6 7 8

    

 



 

1

1

Valor empleado para seleccionar una configuración alterna Numero de endpoint soportados (Sin contar el endpoint 0) Código de clase

1

Código de subclase

1

Código de protocolo

1

Índice de la cadena descriptora de la interfaz

1

bLength: Numero de bytes en el descriptor bDescriptorType: La constante INTERFACE (04h) iInterface : Índice de una cadena que describe la interfaz, este valor es cero si no existe tal cadena bInterfaceNumber : Identifica la interfaz, en un dispositivo compuesto, una configuración tiene múltiples interfaces, las cuales pueden estar activas al mismo tiempo. Cada interface debe tener un descriptor con un valor único en este campo, por default este valor es cero. bAlternateSetting : Cuando una configuración soporta interfaces múltiples mutuamente excluyentes, cada una de las interfaces debe tener un descriptor con el mismo valor en bInterfaceNumber y un valor único en bAlternateSetting. La intruccion Get_Interface regresa los datos de la configuración actual, y la instrucción SetInterface selecciona la configuración a usar, por default este valor es cero. bNumEndpoints : El número de endpoints que la interface soporta adicionalmente al endpoint 0. bInterfaceClass : Similar a bDeviceClass en el descriptor del dispositivo, pero para dispositivos con una clase especificada por la interfaz. La siguiente tabla muestra los códigos definidos. Valores de 01h a FEh están reservadas para clases definidas. FFh indica una clase definida por el fabricante, el cero está reservado. bInterfaceSubClass : Similar a bDevideSubClass en el descriptor del dispositivo, pero para dispositivos con una clase definida por la interface. Para interfaces que pertenecen a una clase, este campo puede especificar una subclase dentro de la clase. Si bInterfaceClass es 0, bInterfaceSubClass debe ser 0. Si bInterfaceClass es un valor entre 01h y FEh, bInterfaceSubClass debe ser 0 o un código definido por la especificación USB. BInterfaceProtocol : Similar a bDeviceProtocol en el descriptor del dispositivo pero para dispositivos con una clase definida por la interface. Puede especificar un protocolo definido por la clase o subclase de interfaz seleccionada.

Código de clase (hexadecimal) 01h 02h

Descripción Audio Comunication Device Class (Interfaz de comunicaciones) Dispositivo de interfaz humana (HID) Físico Imagen Impresora Almacenamiento masivo Hub Comunication Device Class (Interfaz de datos) Smart CARD Contenido de seguridad Video Dispositivo de diagnostico Controlador wireless Especifico de aplicación Especifico de fabricante

03h 05h 06h 07h 08h 09h 0Ah 0Bh 0Dh 0Eh DCh E0h Feh FFh

Opciones para bInterfaceClass

 Descriptor de cadena Un descriptor de cadena contiene texto descriptivo. La especificación USB 2.0 define los descriptores que pueden contener índices a varias cadenas, incluyendo cadenas que describen el fabricante, el producto, número de serie, configuración e interfaces. El soporte para descriptores de cadenas es opcional, sin embargo algunas clases requieren de ellos.

OFFSET (DECIMAL) 0 1 2

CAMPO bLength bDescriptorTy pe Bstring ó wLANGID

SIZE (BYTES) 1 1 Varia

DESCRIPTOR Tamaño del descriptor en bytes La constante String (03h) Índice de los idiomas soportados

  



bLength : El número de bytes del descriptor bDescriptorType La constante STRING (03h) wLANGID[0..n] : Usado únicamente en la cadena descriptora 0. La cadena descriptora 0 contiene uno o más códigos de identificación de lenguaje de 16bits, los cuales indican el idioma en que las cadenas están disponibles. El código para el inglés es 0009h y el subcodigo para Ingles Norteamericano es 0004h., Estos se supone serán los únicos códigos soportados por el sistema operativo. La web del USB-IF contiene una lista de los identificadores de lenguaje. bString : Para valores de 1 y mayores el campo String contiene una cadena en Unicode, el formato Unicode emplea 16bits para representar cada carácter, con algunas excepciones los caracteres ANSI 00h al 7Fh corresponden uno a uno con los códigos Unicode 0000h 0007h

Cuando el anfitrión solicita el descriptor de la cadena, el LSB del campo wValue, es un valor de índice. Un valor índice de 0 tiene la función especial de solicitar el idioma de las identificaciones.

NOTA: El código de lenguaje para el español (México) es 080Ah, el código para el español es 000Ah y para el español en México es 0008h

Endpoints del dispositivo Todo el tráfico del bus viaja hacia o desde el endpoint del dispositivo. El endpoint es un buffer el cual almacena múltiples bytes. Típicamente un endpoint es un bloque de memoria o un registro en el chip del controlador. Los datos almacenados en el endpoint pueden ser datos recibidos o datos esperando a ser enviados. El anfitrión también tiene buffers que retienen datos recibidos o datos esperando a transmitirse, pero el anfitrión no cuenta con este buffer especial llamado endpoint, en su lugar el anfitrión sirve de inicio y término para las comunicaciones con el endpoint del dispositivo. La especificación USB define el endpoint del dispositivo como “una porción del dispositivo USB únicamente direccionable que es la fuente o destino de información en un flujo de comunicación entre el anfitrión y el dispositivo. Una dirección de endpoint consiste de un número de endpoint y de un sentido, el número es un valor entre 0 y 15, el sentido es definido desde la perspectiva del anfitrión, un endpoint “IN” provee datos para ser enviados al anfitrión y un endpoint “OUT” almacena los datos recibidos por el host.

Un endpoint configurado para transferencias de control debe transmitir datos en ambos sentidos, así que un endpoint de control consiste en un pr de direcciones de endopints IN y OUT los cuales comparten un número endpoint. Cada dispositivo debe tener el Endpoint 0 configurado como un endpoint de control, es realmente raro la necesidad de endpoints de control adicionales, sin embargo algunos chips los soportan.

Normas El USB-IF (USB implementers forum), es la asociación encargada de generar las normativas que rigen el empleo del estándar USB. En la página http://www.usb.org/developers/docs/usb20_docs/ podremos encontrar todo lo relacionado con las diferentes normativas que definen las características físicas y técnicas de los protocolos USB. Los dispositivos USB se dividen por clases de acuerdo a sus funcionalidades, estas a su vez se divides en subclases, las clases reconocidas por la organización son las siguientes:

                    

Audio class Audio/Video device class Battery charger Cable conector Common class Comunication device class Content security Device firmware upgrade group HID class Imaging class IrDA Mass storage Media transfer protocol Monitor Open USBDI Personal healthcare Physical interface devices Power Printer class Smart card class Test & measurement class



Video class

En el presente reporte se detallaran los requerimientos para la comunicación USB entre la computadora y un microcontrolador, esta comunicación será empleando una transmisión serie, la cual se encuentra disponible en la clase CDC. Este método es el más sencillo para la comunicación serie, permite el intercambio de información en ambos sentidos empleando instrucciones y características similares a las empleadas en las comunicaciones tipo UART. Universal Serial Bus Class Definitions for Communications Devices es el documento donde se detalla este modo de operación, es posible encontrarlo como CDC120-20101103-track.pdf

 Resumen de la norma “CDC120-20101103”

3.-FUNCTIONAL OVERVIEW



Esta sección describe las características funcionales de los CDC, los cuales incluyen la organización y operación del dispositivo

3.1- FUNCTION MODELS

Un dispositivo de comunicaciones tiene 3 responsabilidades básicas  

istración del dispositivo istración de la operación



Transmisión de datos

El dispositivo debe usar una interfaz “Communication Class” para llevar acabo la istración del dispositvo.

3.3 DEVICE OPERATION

Los dispositivos de comunicación presentan los datos al anfitrión (host) en una forma definida por otra clase, como Audio, Datos, HID.

3.4.2. DATA CLASS INTERFACE

La “Data class interface” define una interfaz de datos como una interface con un tipo de clase de datos, esto quiere decir que la transmisión de datos de un dispositivo de comunicación no está restringido por las interfaces empleando clases de datos predefinidas, en resumen la interfaz de datos es usada para transmitir, recibir datos, los cuales no se encuentran definidos en ninguna otra clase, un ejemplo de esto es:

  

Alguna forma de datos brutos (RAW DATA) de alguna línea de comunicación Datos de módems obsoletos Datos usando un formato propietario

En este punto es responsabilidad del software anfitrión así como del dispositivo comunicarse el uno al otro sobre alguna interfaz (CDC) para determinar el formato apropiado a usar.

 Comunicación device class La clase de dispositivos de comunicación engloba 2 tipos de dispositivos: teléfonos y dispositivos de red de baja velocidad, los teléfonos incluyen teléfonos analógicos y módems, terminales ISDN y teléfonos digitales, en cuando a dispositivos de red engloba módems ADSL, módems de cable,, y hubs y adaptadores de Ethernet 10BASE-T.

Esta clase también se considera una buena opción para otros dispositivos accesados vía funciones de puerto COM por parte del anfitrión. La principal documentación para los dispositivos de comunicación es la especificación para la clase “dispositivos de comunicación” (CDC). Dos subclases tienen sus propias documentaciones. La subclase “Wireless Mobile Communications” (WMC) incluye equipo terminal para dispositivos inalámbricos que pueden desarrollar varias funciones incluyendo comunicaciones de datos y de audio. La subclase “Ethernet Emulation model” (EEM) incluye dispositivos que envía y reciben framas de Ethernet

 En resumen

 AN1164 USB clase CDC para dispositivos embebidos En esta nota de aplicación de Microchip nos da una introducción de las funcionalidades del módulo USB, en nuestro caso específico para implementar una comunicación del tipo UART a través de USB. La clase CDC indica como es la interfaz de comunicación USB, se desarrolló para dispositivos como módems e interfaces de red, sin embargo unas de las funcionalidades de este modo de operación pueden emplearse para emular un puerto serie, lo cual puede proveer una terminal UART virtual.

IMPLEMENTACION DE COMUNICACIÓN USB EN UN MICROCONTROLADOR PIC18F4550

El empleo de un lenguaje de programación de alto nivel es de gran ayuda para la implementación de funciones USB en el microcontrolador, esto debido a que CCS cuenta con funciones para la inicialización y el control del módulo USB del PIC.

Requerimientos     

Un microcontrolador que soporte comunicación vía USB Un programa en el microcontrolador para transmitir la información. Una computadora con puerto USB. Driver en la computadora anfitrión. Programa para leer los datos del dispositivo externo

Descripción general del módulo USB en el PIC18F4550 El PIC18FX550 contiene un “USB Serial Interface Engine” (SIE) compatibles con alta y baja velocidad el cual permite una rápida comunicación entre el USB anfitrión y el microcontrolador. La SIE puede ser conectada directamente al USB, utilizando un transceptor interno, aunque también es posible emplear un transceptor externo. Algunas características especiales de hardware han sido implementadas para mejorar el rendimiento. Una memoria de doble puerto ha sido implementada (USB RAM) para compartir directo el núcleo del microcontrolador y la SIE. Un puerto paralelo de streaming se ha provisto para soportar la transferencia ininterrumpida de largos volúmenes de información, como datos asíncronos.

Diagrama de la organización interna del módulo USB

17.2 USB STATUS AND CONTROL

L a operación del USB es configurada a través de 3 registros, además un total de 22 registros están involucrados para el manejo de la información USB, los más importantes son:

   

USB CONTROL (UCON) USB CONFIGURATION (UCFG) USB TRANSFER STATUS (USTAT) USB DEVICE ADRESS (UADDR)

17.10.5 ENUMERATION

Cuando el dispositivo es inicialmente conectado al bus, el anfitrión comienza el proceso de enumeración, en un intento por reconocer el dispositivo, esencialmente el anfitrión interroga al dispositivo, obteniendo información como el consumo energético, tamaño y muestreo de datos, protocolo e información descriptiva, los descriptores contienen esta información. Un proceso típico de enumeración ocurría de la siguiente manera:

El Host es el encargado de detectar cualquier dispositivo que se conecta al bus. Cuando un dispositivo es detectado el Host necesita obtener información sobre el, a este proceso es al que se le llama enumeración. Esta información que necesita el Host se encuentra definida en el dispositivo en los llamados descriptores. Los descriptores son datos que se guardan en la memoria no volátil del PIC y contienen la siguiente información: El ID del vendedor (VID) y del producto (PID), consumo de corriente del dispositivo, tipo de transferencia que se va ha utilizar, endpoint utilizados, versión USB soportada, clase utilizada, etc.

El VID (Vendor ID) y el PIC (Product ID) son dos números de 16 bits representados en Hexadecimal, si se va a emplear la clase CDC (Communications Device Class) de CCS para la comunicación USB estos valores los podemos modificar en el archivo "usb_desc_cdc.h" y según el sistema operativo instalado en el Host deberemos modificarlos también en el archivo .inf .

Realmente el modificar estos valores solo es útil si se quiere distribuir el producto comercialmente, en ese caso existe una organización llamada USB Implementers Forum que se encarga de proporcionarnos previo pago correspondiente (creo que unos 1500 $) un VID valido para que nuestro dispositivo conviva sin problemas con el resto de dispositivos USB del mercado, además tendremos derecho a poner el logo USB en nuestro producto certificando de esta manera que ha pasado los controles pertinentes y cumple con el estándar USB.

Si esto no estuviera regulado tal y como está y cada dispositivo tuviera el VID y PID que quisiera, cuando coincidieran en un mismo sistema dos números iguales se presentaría un conflicto hardware y ambos dispositivos dejarían de funcionar.

17.10.6 DESCRIPTORS

Existen 8 tipos distintos de estándares para los descriptores

17.10.6.1 DEVICE DESCRIPTOR

Este descriptor provee de información de información general, como el fabricante, el número del producto, el número de serie, la clase del dispositivo así como el número de configuraciones, solo existe un descriptor de este tipo.

17.10.6.2 CONFIGURATION DESCRIPTOR

Este descriptor provee de información como los requisitos energéticos del dispositivo, y cuantas distintas interfaces son soportadas en esta configuración, puede haber más de una configuración para el dispositivo.

17.10.7 BUS SPEED

Cada dispositivo USB debe indicar la presencia de su bus y la velocidad al anfitrión, esto se logra a través de una resistencia de 1.5Kohms, el cual es conectado al bus al momento de conectar físicamente el dispositivo USB.

Dependiendo de la velocidad del dispositivo, el resistor pone en estado de PULL-UP la línea D+ ó Da 3.3V, para el modo de baja velocidad la resistencia se conecta en D-, mientras que en el modo de alta velocidad se conecta del lado de D+.

17.10.8 CLASS SPECIFICATIONS AND DRIVERS

Las especificaciones del USB incluyen especificaciones de clases los cuales son respaldados opcionalmente por los fabricantes de los sistemas operativos. Ejemplos de clases soportadas son Audio, Mass storage, Comunications and Human Interface (HID) En la mayoría de los casos, un driver es requerido en el anfitrión para poder comunicarse con el dispositivo USB, en aplicaciones especiales, un driver tendría que ser desarrollado en conjunto. Afortunadamente existen gran cantidad de drivers disponibles para las clases de dispositivos más comunes.

Funciones del oscilador para comunicación USB El microcontrolador PIC18F4550 cuenta con múltiples opciones para la generación de la oscilación necesaria para su correcto funcionamiento, es capaz de operar con cristales, osciladores RC, entradas externas de reloj y con el oscilador interno RC. Sin embargo para establecer la comunicación USB de alta velocidad se recomienda al empleo de cristales de cuarzo, los cuales presentan una mejor estabilidad de frecuencia para un amplio margen de temperaturas. El modulo oscilador interno del microcontrolador cuenta con un “Lazo de seguimiento de fase” PLL, el cual proporciona una salida de 96MHz al ingresarle una onda de 4MHz, esto aunado a un preescaler a la entrada del PLL nos permite emplear una gran variedad de cristales para el funcionamiento de nuestro circuito. En la siguiente imagen se presenta el circuito oscilador del PIC, se encuentran marcados los valores de ejemplo para la configuración del oscilador para cristales de 20MHz. La frecuencia de oscilación de 20Mhz entra al preescaler del PLL, este permite dividir la frecuencia entre 1,2,3,4,5,6,10 y 12, el #fuse asociado es el PLLDIV, posteriormente la señal toma 2 caminos. Un camino pasa por un divisor de frecuencia (f/2) para luego ir a un MUX asociado al fuse USBDIV, al emplear el fuse USBDIV indicamos al microcontrolador que la frecuencia proveniente del PLL es la que emplearemos

para el modulo USB, en caso contrario la frecuencia proveniente de la entrada se utilizara en dicho modulo. El otro camino que toma loa salida del PLL pasa por un postcaler, el cual permite dividir los 96MHz de salida del PLL entre 2,3,4 y 6 para su empleo en el resto de las funciones del microcontrolador.

Diagrama interno del preescaler

Librerías de CCS

El compilador CCS cuenta con librerías creadas para la configuración y el manejo del módulo USB del microcontrolador, para la correcta programación de la comunicación USB es necesario mandar a

llamar varias librerías dentro de CCS. En el siguiente diagrama se muestra la interrelación que existen éntrelas distintas librerías.

Diagrama que muestra las relaciones entre las distintas librerías para manejo del puerto USB en CCS

usb_cdc.h Librería para crear un puerto COM virtual en la PC sobre USB, empleando la especificación CDC, al emplear este archivo en el código, se agregaran las interrupciones y descriptores requeridos.

Esta librería crea un link virtual RS-232 entre la PC y el PIC, por lo que en esta librería encontraremos funciones similares a aquellas empleadas para el manejo de datos de entrada y salida del tipo UART.



usb_cdc_kbhit() – Regresa un valor verdadero si existe uno o más caracteres recibidos y esperando en el buffer de entrada.



usb_cdc_getc() – Obtiene un carácter del buffer de entrada, si no hay datos en el buffer esperara hasta que se presenten, si no se quiere esperar en un bucle infinito se debe emplear la instrucción usb_cdc_kbhit() primero para checar que existen datos antes de mandar a llamar con la instrucción usb_cdc_getc().



usb_cdc_putc(char c) – Pone un carácter en el buffer de salida, si está lleno espera a que se vacié antes de colocar el carácter en el buffer, este buffer es leído por la computadora muy rápido, así que el buffer solo se encontrara lleno unos milisegundos, si esto le preocupa y no quiere quedarse en un bucle infinito use usb_cdc_putready() para cerciorarse que exista lugar en el buffer se salida.



usb_cdc_puts(*ptr) – Envía el comando de cadena terminada al buffer de salida, a diferencia de usb_cdc_putc() o usb_cdc_putc_fast(), esta rutina acomodara la cadena en un solo paquete (mientras que las otras rutinas empujaran el paquete tan pronto como se libere el endpoint). Esta función regresa un valor verdadero si el paquete se envió y falso si el buffer aun se encuentra en uso. Podría dejar de copiar caracteres del apuntador (ptr) al buffer de endpoint una vez que este esté lleno, pero aun así podría regresar un valor verdadero.



usb_cdc_putready() – Regresa un valor verdadero si hay espacio disponible en el buffer de salida para un carácter mas.



usb_cdc_putempty() – Regresa un valor verdadero si el buffer de salida se encuentra vacío y ha transmitido toda la información a la PC.



usb_cdc_connected() – Regresa un valor verdadero si se recibió “set_line_coding”,en muchos programas de terminal serial (como hyperterminal), estos envían un mensaje “set_line_coding” cuando el programa inicia y este abre el puerto COM, esta es una manera sencilla de determinar si la PC esta lista para desplegar los datos en el programa de terminal serial, pero no se garantiza que funcione todo el tiempo o que funcione en otras terminales virtuales.



usb_cdc_putc_fast(char c) – Similar a usb_cdc_putc(), a excepción que si el buffer de salida esta lleno omitirá la cadena.



usb_cdc_line_coding – Una estructura usada para set_line_coding y get_line_coding, la mayor parte del tiempo puedes ignorar esta instrucción.



usb_cdc_break – Si la PC ha enviado el comando BREAK, esta podrá mantenerse el tiempo de interrupción (BREAK TIME en ms), si la PC envía un valor de 0xFFFF el dispositivo debe mantener la interrupción hasta que se le envié un valor de 0.



usb_cdc_carrier – donde se almacena el valor de (set_control_line_state).



usb_cdc_serial_state(state) – Transmite al anfitrión el SERIAL_STATE (estado serial), este contiene información como DCD, DSR, ring, break y más.

Las siguientes funciones también son provista, y son puertos de las funciones de entrada y salida en input.c      

get_float_usb() – Lee un numero tipo float del get_long_usb() – Lee un numero tipo long del get_int_usb() – Lee un numero tipo entero del get_string_usb(char *s, int max) – Lee una cadena del gethex_usb() – Lee un byte en hexadecimal del gethex1_usb() – Lee un character hexadecimal

USB_CDC_ISR() puede ser definido si se desea una rutina específica para se llamada cuando hay datos entrantes del puerto COM virtual. Esto es útil si se quiere actualizar de código antiguo RS232, en donde se empleaba #int_rda para manejarlos datos entrantes en el RS232 ISR. Normalmente usb_cdc_putc() y usb_cdc_putc_fast trataran de descargar los datos tan pronto sea posible, sin embargo esto en ocasiones puede llegar a ser bastante ineficiente y podría descargar paquetes con 1 byte. La opción US_CDC_DELAYED_FLUSH tratara de descargar al inicio de usb_cdc_putc() y usb_cdc_putc_fast() si el buffer local se encuentra lleno, esta función también tratara de descargar el paquete en cada llamado a usb_task(). Es recomendable que solo se empleé esta función si se cuenta con un loop principal que periódicamente llame a usb_task().

Este driver cargara el resto del código para USB, y establecerá los descriptores que adecuadamente describirán el dispositivo como CDC para una terminal COM virtual, esto se hace con una llamada a la librería usb_desc_cdc.h

TAMAÑOS DEL BUFFER

USB_CDC_DATA_IN_SIZE controla el tamaño del buffer de salida, el tamaño total del buffer de salida será ((USB_CDC_DATA_IN_SIZE*2)-1).Los dispositivos de alta velocidad (full-speed) limitaran este valor a 64. Para incrementar el tamaño del buffer local del PIC también se puede definir USB_CDC_DATA_LOCAL_SIZE, si este se define entonces el tamaño total del buffer de salida será USB_CDC_DATA_LOCAL_SIZE+USB_CDC_DATA_IN_SIZE. Si USB_CDC_DATA_LOCAL_IN_SIZE no se define, se emplea un valor por default de 64, si USB_CDC_LOCAL_SIZE no se define, esta opción no es empleada.

LIMITACION DE LAS INTERRUPCIONES

Esta sección solo es relevante si se está empleando interrupciones USB y no la opción USB_ISR_POLLING. El manejo del puerto USB es complejo, comúnmente requiere el envio de muchos paquetes para completar la transferencia de un bloque de datos, la mayor parte de este proceso se realiza en la USB ISR, es por eso que no puedes llamar usb_cdc_putc() dentro de otra ISR, USB ISR o cuando las ISR´’s estas inhabilitadas.

Para resolver este problema usa usb_cdc_putc_fast() y la opción USB_CDC_DELAYED_FLUSH, aunque esta no es la mejor opción porque si se emplea usb_cdc_putc_fast() para desbordar el buffer de salida los datos se perderán.

CONFIGURACION DEL PUERTO RS-232 VIRTUAL

Dentro de esta librería es posible cambiar las características de la comunicación serie, al llamar la rutina de inicialización esta asigna los valores preestablecidos, es posible cambiarlos en la librería para así tener más control de cómo queremos que sea la comunicación serie.

Captura de pantalla de la sección del archive usb_cdc.h donde podemos configurar valores de la comunicación serie como lo son la velocidad del puerto en bps, paridad y bits de datos

Descriptores

usb_desc_cdc.h La librería usb_cdc.h hace un llamado a usb_desc_cdc.h que es la librería encargada de asignar los descriptores del dispositivo. En esta sección es posible configurar los descriptores de dispositivo, de configuración, de cadena, de interfaz, con el fin de lograr desarrollar un producto acorde a las necesidades del desarrollador. Cuando un dispositivo USB es conectado se identifica a si mismo al anfitrión a través de la combinación del PID y el VID, el VID es un numero de 16bits del vendedor, el PID es un numero de 16 bits del número de producto, la PC emplea esta combinación para encontrar los drivers a emplear. Esta librería no cuenta con instrucciones, solo es para definir los descriptores, para este caso emplearemos como VID el 0X04D8 que es el número que define al dispositivo como un producto de Microchip, como PID emplearemos el 0x0007, este queda a consideración del desarrollador, sin embargo conviene investigar un poco si la combinación PID/VID a emplear no causara conflictos con dispositivos registrados.

Captura de pantalla de la sección del archivo usb_cdc_desc.h donde podemos modificar los valores PID y VID.

En la siguiente parte podemos definir la información que es desplegada por el wizard de WINDOWS “agregar hardware”

Captura de pantalla de la seccion del archive usb_cdc_desc.h donde podemos modificar los valores de las cadenas de texto.

Al modificar las cadenas de texto debemos de tener en cuenta establecer el tamaño de las mismas, asi como el offset de todas las cadenas respecto al inicio

1. El offset indica el inicio de cada cadena, es decir, tendrá tantos elementos como cadenas tenga el descriptor, para este caso 3, o indica el inicio de la primera cadena, que es la que define el idioma, como esta tiene una dimensión de 4bytes el siguiente offset es de 4 y como la segunda cadena tiene una dimensión de 8bytes el tercer offset es la suma de las 2 dimensiones (12). 2. Por default el descriptor viene con el descriptor para el idioma ingles 0x0409, sin embargo si quieren usarse símbolos especiales de algún otro idioma, debe indicarse en esta parte el idioma a emplear. 3. La longitud de la cadena incluye el comando de término “NULL” , por lo que al número de caracteres de la cadena debemos de sumarle 2 bytes.

Programas de generación de descriptores y archivos .inf Aunque se puede optar por modificar el archivo de los descriptores “usb_cdc.h” manualmente con la ayuda de algún editor de texto, también se tiene la opción de emplear programas especializados para tal fin. Uno de ellos es el denominado “INF Enumeración Datos uC PIC-USB” el cual podemos encontrarlo gratuitamente en la red, este programa está diseñado para generar los archivos de los descriptores y el archivo inf.

Captura de pantalla del programa

El programa nos permite definir: nombre de la categoría, VID, PID, la Ubicación, Descripción Fabricante, Versión y Fecha, por default esta seleccionada la opción de PICC CCS como lenguaje de programación, además nos permite seleccionar el tipo de transferencia que emplearemos para la comunicación USB, nos da la opción de emplear un archivo multipropósito o uno especializado para RS-232 sobre la clase CDC. Al guardar debemos de seleccionar previamente la opción de guardar ambos, la cual nos permitirá guardar el archivo del descriptor para emplearlo en la compilación en CCS y el archivo mchpcdc.inf para indicarle al sistema operativo que Controlador debe instalar con el dispositivo.

DRIVER Descripción general Un driver o también conocido como controlador de dispositivo es un programa informático el cual permite al sistema operativo interaccionar con un periférico, haciendo una abstracción de hardware y proporcionando una interfaz para su uso. Existen tantos tipos de controladores como tipo de periféricos, y es común encontrar más de un controlador disponible para el mismo dispositivo, cada uno ofreciendo distintas funcionalidades, entre los principales encontramos los oficiales (disponibles en la página del fabricante), los proporcionados por el sistema operativo y versiones hechas por terceros. Si el firmware de nuestro dispositivo no cumple con las especificaciones de alguna de las clases beneficiadas por el uso de drivers genéricos instalados en WINDOWS, la única opción es diseñar el driver para nuestro dispositivo, si no la PC nunca lo reconocerá. Diseñar un driver desde cero es complicado ya que se requieren conocimientos de arquitectura de PC, así como del sistema operativo, para evitar el desarrollo de un driver emplearemos un driver genérico de microchip. El driver que proporciona microchip consta de los siguientes archivos



mchpusb.sys – es el archivo binario



mchpusb.ini – este archivo contiene la información del driver y es requerido por el sistema operativo para la primera conexión, para que el S.O. determine que driver asignarle al dispositivo, además el S.O. obtiene información de aquí para configurar correctamente el dispositivo, este es un archivo de texto que se puede editar, en si debemos de hacer que los valores del VID y el PID coincidan con el de nuestro dispositivo, además es posible editar algunas cadenas de texto que se mostraran como información del dispositivo una vez instalado el driver



DLL mpusbapi – una DLL es una capa de software, que en este caso facilita por medio de funciones la comunicación entre la aplicación de escritorio y el driver del dispositivo.



usbser.sys – es el driver genérico de Windows para brindar servicios tipo modem via USB, las señales de los módems DSL y señales RS-232 son parecidas, asi que también sirve para crear un puerto COM virtual.

Servicio Plug & Play de Windows En computación un servicio de “Plug and Play” es una especificación que facilita la integración de nuevo hardware en la PC anfitrión, sin la necesidad de configurar el dispositivo o la intervención del para resolver conflictos. La instalación de un nuevo dispositivo en Windows implica tres pasos: 1. Conectar el dispositivo al equipo 2. Cargar los controladores del dispositivo correspondientes 3. Configurar las propiedades y los valores del dispositivo Una vez que se conecta un nuevo dispositivo el servicio “Plug and Play” de Windows solicita información a este, generalmente son los descriptores (PID, VID) los cuales le indicaran al sistema operativo de que dispositivo se trata en cuestión.

de dispositivos Si es exitoso este procedimiento el dispositivo en cuestión aparecerá en el de dispositivos, como “hardware desconocido”, en ese momento se dice que el nuevo dispositivo ha sido enumerado por el sistema operativo, el cual crea un registro con las características dadas por el dispositivo y es guardado en HKEY_LOCAL_MACHINE\CurrentControlSet\Enum. Windows cuenta con drivers genéricos, así como drivers de los dispositivos de entrada y salida más comunes en el mercado, por lo que si no se conectó algún dispositivo considerado por Windows el servicio de “Agregar nuevo hardware” empezara una búsqueda del mismo en Windows Update, en base a los descriptores obtenidos. Si no se encuentra con el controlador en la base de datos de Windows, el servicio “Agregar nuevo hardware” pasa a revisar una base de archivos .inf dentro del propio Windows, esta base de archivos se encuentra en “Windows\inf”. Si en dicha carpeta no se encuentra un archivo inf que corresponda con las características del dispositivo, Windows nos solicitara la introducción manual de la ruta del controlador. En este punto queda a criterio del desarrollador decidir de que manera proceder con la instalación de sus dispositivo, es decir, se pueden emplear números PID, VID genéricos para que la instalación se realice con los archivos propios de Windows, se puede instalar manualmente o se puede agregar el archivo inf a Windows de antemano para que la instalación del controlador sea sin intervención del .

Captura de pantalla del registro hecho al enumerar el dispositivo

Creación del instalador del controlador con INSTALLSHIELD Una opción es incluir algún medio con el dispositivo el cual cuente con un programa de instalación, el cual se encargue en automático de garantizar la correcta instalación del controlador del dispositivo. Dado que en el dispositivo a desarrollarse se emplearan descriptores propios, los servicios de Windows no serán capaces de instalarlo por cuenta propia, por lo que se hace necesario agregar el archivo .inf que define el controlador a utilizar en el dispositivo a instalar. Windows busca en varias carpetas en el equipo el archivo .inf necesario para la correcta instalación y configuración del hardware nuevo, una de esas carpetas se encuentra en [DISCO LOCAL]\Windows\INF. Si de antemano colocamos nuestro archivo .inf en esta carpeta, Windows será capaz de instalar el dispositivo por su cuenta al conectar el dispositivo a la computadora anfitrión por primera vez. Para automatizar este paso podemos hacer uso de software especializado en creación de instaladores, para este caso emplearemos la versión de prueba de INSTALLSHIELD 2014.

Captura de pantalla de INSTALLSHIELD 2014

Para comenzar daremos clic en File-New Project, lo cual nos desplegara la siguiente ventana

En esta ventana seleccionaremos la opción Express Project, el idioma lo cambiamos a español y nombramos el proyecto, después dar clic en OK

Seleccionamos la pestaña de Installation designer, por default nos va a abrir la ventana de General information, en esta debemos de Ingresar 3 datos. 1. En el campo Product name ingresamos el nombre del producto 2. En el campo INSTALLDIR damos clic y nos va a abrir múltiples carpetas del sistema donde podemos colocar nuestros archivos, seleccionaremos la carpeta [WindowsFolder] y damos clic nuevamente, ahora después escribimos el nombre de la carpeta destino, en este caso es la carpeta inf. 3. En el campo Tag Creator ID colocamos nuestro id con el formato: regid.AAAAMM.com.nombredepaginaweb

Posteriormente nos vamos a la ventana Files la cual está en el punto 2 “Specify Application data”

En esta sección incluiremos los archivos que se van a instalar en la computadora anfitrión, es decir el archivo inf que indicara a la computadora el driver que debe instalarse al conectar nuestro dispositivo, posteriormente damos clic en el icono de la barra e hasta abajo que dice “Installation overview” [1]

En esta pantalla tenemos la opción de brindar ciertos requisitos o permisos al momento de ejecutar el instalador, dado que nuestra instalación solo colocara un archivo en una carpeta definida podemos definir todas las opciones como “no” [2].

Posteriormente damos clic en el icono “build aplication” [1]

En esta pantalla dar clic en la opción “single executable” [2] , el cual creara un solo archivo “.exe” para la distribución de la instalación, por ultimo basta dar clic en “Build installations” [3] para que se cree el archivo ejecutable en la carpeta que seleccionamos para guardar el proyecto. El archivo ejecutable se encuentra en la ruta: \NOMBREDELPROYECTO\Express\SingleImage\DiskImages\DISK1

Una vez creado el ejecutable este se puede distribuir de la manera que lo decida el desarrollador, no necesita ningún software adicional, sin embargo debido a que realiza cambios en la carpeta de Windows en algún momento de la instalación solicitara privilegios de .

A continuación se muestran las capturas de pantalla del instalador.

Primera pantalla de bienvenida

Segunda pantalla donde se muestran los datos generales de la instalación

Tercera pantalla, donde se muestra el progreso de la instalación

Cuarta pantalla, donde se da por concluida la instalación

IMPLEMENTACION La implementación de la comunicación USB es posible realizarla mediante dispositivos diseñados para tal fin como lo es el controlador USB960X o mediante dispositivos embebidos que cuenten con módulo de comunicación USB. A continuación se desarrollara la implementación de la comunicación USB en modo te transferencia CDC mediante un PIC18F4550 para la realización de una terminal de simulación RS-232. Para la programación se ha elegido el entorno de programación PIC CCS, el cual es un compilador C muy completo, debido a que cuenta con librerías integradas tanto para la realización de la comunicación USB como para la simulación del puerto RS-232.

Programa de ejemplo Para comenzar a trabajar con la implementación del programa para comunicación serie, primero debemos de comenzar identificando los parámetros que deberá llevar el archivo descriptor, entre los que destacan:

    

Id de fabricante Id de modelo Corriente requerida al puerto USB Versión Tipo de transferencia

Estos datos pueden modificarse manualmente en el archivo: “usb_desc_cdc.h”, lo recomendable es cambiar el nombre a este archivo para conservar los archivos originales con los que viene el programa, adicionalmente se deberá crear un archivo inf con los mismos datos para la correcta instalación del dispositivo por parte del sistema operativo. Otro camino es emplear el programa de generación de descriptores y archivos .inf, del cual se habla en la página 31 de este manual. Una vez obtenidos el archivo descriptor y el archivo inf, procedemos a la realización del programa en CCS.

CODIGO FUENTE

#include <18F4550.h> #fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,UDIV1,VREGEN //El fuse HSPLL se emplea para activar la función del PLL en conjunto con un crisal //El fuse USBDIV le indica al microcontrolador que la frecuencia proveniente del PLL será la //utilizada para las funciones USB //PLL5 indica la división del preescaler, esta es para el empleo de un cristal de 20MHz //UDIV1 indica la división del postcaler, indica que el microcontrolador trabajara con la frecuencia de salida del postcaler/2 #use delay (clock=48000000) //La frecuencia empleada para el delay es de 48MHz debido al empleo del PLL y posterior division //sobre 2 #define LCD_ENABLE_PIN PIN_C2 #define LCD_RS_PIN PIN_A4 #define LCD_RW_PIN PIN_A5 #define LCD_DATA4 PIN_A0 #define LCD_DATA5 PIN_A1 #define LCD_DATA6 PIN_A2 #define LCD_DATA7 PIN_A3 #include #include #include <usb_desc_cdc.h> //En esta sección se incluyen las librerías, entre ellas el archive de descriptores de nuestro //dispositivo, el cual a su vez llama a las otras librerías USB #BYTE TRISA = 0xF92 #BYTE PORTA = 0xF80 #BYTE LATA = 0xF89 #BYTE TRISB = 0xF93 #BYTE PORTB = 0xF81 #BYTE LATB = 0xF8A #BYTE TRISC = 0xF94 #BYTE PORTC = 0xF82 #BYTE LATC = 0xF8B //VARIABLES GLOBALES char a,b;

//INICIO DE PROGRAMA void main() { //INICIALIZACION DE LOS PUERTOS setup_timer_3(T3_DISABLED | T3_DIV_BY_1); setup_adc(ADC_OFF ); setup_adc_ports(NO_ANALOGS|VREF_VREF); setup_c1 (C_OFF); setup_c2 (C_OFF); port_b_pullups(TRUE); //COMPROBACION DE FUNCIONAMIENTO DEL PIC lcd_init(); delay_ms(100); printf(lcd_putc, " Interfaz USB"); lcd_gotoxy(1,2); lcd_cursor_on(1); delay_ms(150); //INICIALIZACION DE LIBRERIAS usb_cdc_init(); //Inicializacion de la librería USB en modo CDC usb_init(); //Inicializacion de las funciones USB kbd_init(); //COMPROBACION DE CONEXION USB if(usb_attached()==1) { while (TRUE) { a=kbd_getc(); if (a!= '\0') { printf(usb_cdc_putc, "%c", a ); output_high(PIN_C6); delay_ms(10); output_low(PIN_C6); } if (usb_cdc_kbhit()==1) { b=usb_cdc_getc(); if (b=='\b') { printf(lcd_putc, "%c", b ); printf(lcd_putc, " "); } printf(lcd_putc, "%c", b ); } delay_ms(1);

} } }

Circuito A continuación se presenta el diagrama el diagrama de la terminal serie, el cristal empleado es de 20MHz.

Simulación La simulación en PROTEUS no fue posible, debido a que los drivers para la simulación USB solo están disponibles para sistemas de 32 bits.

Prueba Una vez armado el circuito y programado el PIC, se procede a la instalación del driver. El driver debe de instalarse antes de conectar el dispositivo, para que Windows sea capaz de instalar los drivers requeridos.

Una vez instalada nos aparecerá una terminal COM virtual en el de dispositivos.

Posteriormente procedemos a abrir una terminal un monitor de actividad serie en la computadora.

Una vez establecida la conexión podemos comenzar a enviar y recibir datos por nuestra terminal.