TRABALHO DE GRADUAÇÃO DESENVOLVIMENTO DE UMA INTERFACE USB PARA AQUISIÇÃO DE DADOS DE UM ARRANJO DE MICROFONES: APLICAÇÃO EM PRÓTESE AUDITIVA

TRABALHO DE GRADUAÇÃO DESENVOLVIMENTO DE UMA INTERFACE USB PARA AQUISIÇÃO DE DADOS DE UM ARRANJO DE MICROFONES: APLICAÇÃO EM PRÓTESE AUDITIVA Marcello Gurgel Sasaki Otávio Viegas Caixeta Brasília, dezembro de 2006 UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA

UNIVERSIDADE DE BRASILIA Faculdade de Tecnologia TRABALHO DE GRADUAÇÃO DESENVOLVIMENTO DE UMA INTERFACE USB PARA AQUISIÇÃO DE DADOS DE UM ARRANJO DE MICROFONES: APLICAÇÃO EM PRÓTESE AUDITIVA Marcello Gurgel Sasaki Otávio Viegas Caixeta Relatório submetido ao Departamento de Engenharia Elétrica da Faculdade de Tecnologia da Universidade de Brasília como requisito parcial para obtenção do grau de Engenheiro Eletricista. Banca Examinadora Prof. Ricardo Zelenovsky, Doutor, UnB/ENE (Orientador) Prof. Leonardo R. A. X. Menezes, Ph.D., UnB/ENE Prof. Alexandre Zaghetto, Mestre, UnB/ENE

FICHA CATALOGRÁFICA SASAKI, MARCELLO GURGEL CAIXETA, OTÁVIO VIEGAS Desenvolvimento de uma interface USB para aquisição de dados de um arranjo de microfones: aplicação em Prótese Auditiva. [Distrito Federal] 2006. xvii, 134p.,210 x 197 mm (ENE/FT/UnB, Engenheiro Eletricista,2006) Monografia de Graduação - Universidade de Brasília. Faculdade de Tecnologia. Departamento de Engenharia Elétrica. 1. USB 2. Firmware 3. Áudio 4. Microfone I. ENE/FT/UnB II. Título (série) REFERÊNCIA BIBLIOGRÁFICA SASAKI, MARCELLO GURGEL; CAIXETA, OTÁVIO VIEGAS (2006). Desenvolvimento de uma interface USB para aquisição de dados de um arranjo de microfones: aplicação em Prótese Auditiva. Monografia de Graduação, Publicação ENE 02/2006, Departamento de Engenharia Elétrica, Universidade de Brasília, Brasília, DF, 134p. CESSÃO DE DIREITOS NOME DOS AUTORES: Marcello Gurgel Sasaki, Otávio Viegas Caixeta. TÍTULO: Desenvolvimento de uma interface USB para aquisição de dados de um arranjo de microfones: aplicação em Prótese Auditiva. GRAU / ANO: Engenheiro Eletricista / 2006 É concedida à Universidade de Brasília permissão para reproduzir cópias desta dissertação de mestrado e para emprestar ou vender tais cópias somente para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte desta dissertação de graduação pode ser reproduzida sem a autorização por escrito dos autores. Marcello Gurgel Sasaki Otávio Viegas Caixeta SHIS QI 17, conj. 12, casa 10 - Lago Sul SQN 406, bl. E, apto. 205 - Asa Norte 71645-120 Brasília, DF - Brasil 70847-050 Brasília, DF - Brasil

Dedicatórias Eu dedico esse trabalho aos meus pais por confiarem em mim incondicionalmente. Que este seja um símbolo de sucesso não só meu, mas principalmente deles. Marcello Gurgel Sasaki A meus pais. Obrigado por nunca medirem esforços em me ensinar o que é certo e convencerme a confiar em mim mesmo. Não saberia chegar onde estou sem vocês me mostrando o caminho.. Otávio Viegas Caixeta

Agradecimentos Primeiramente eu agradeço a Deus que sempre se mostrou presente em minha vida. A minha família, meu pai, Eduardo Wagner, que nunca me deixou faltar nada, deixando o caminho aberto para que eu seguisse o que era de minha vontade e vocação. Minha mãe, Vera Lúcia, que fez de tudo ao seu alcance para me estimular a crescer e buscar o conhecimento. Meus irmãos, Melissa e Wagner, com quem pude contar sempre. Minha avó, Bernadette, que sempre foi um exemplo de perseverança e força. Meus tios e primos que torceram sempre por mim. Aos meus colegas com os quais conviví nos últimos cinco anos e se tornaram amigos para sempre. Izumi, minha fiel escudeira de todos os momentos, os companheiros de projeto, Ana Ravena, Francisco e meu co-autor Otávio. Os amigos, Fernanda, Bianchi, Samuel, Marcos, Thompson, Maria Clara, Luíza, Branquinho, Ewerton, Rogério, Solino, Artur, Utida, entre outros pelos momentos de descontração em meio às horas inacabáveis de estudo. Aos professores e mestres por todo o conhecimento depositado em mim, em especial ao Prof. Ricardo Zelenovsky, orientador e fonte inesgotável de conhecimento. Ao Prof. Leonardo de Menezes pela primeira oportunidade acadêmica. Aos colaboradores de plantão do GPDS Edson Mintsu e Tiago Alves que nunca deixaram uma pergunta sem resposta. E aos colegas Carlos Vinícius e Raphael Hideki pela ajuda neste projeto. A todas as pessoas que me apoiaram uma hora ou outra durante esses anos contribuindo para minha atual sanidade. Marcello Gurgel Sasaki

Agradeço a minha família por todo o amor que recebi. A minha mãe, por todo seu carinho e por conseguir me ensinar que o mundo vai muito além do que eu vejo. A meu pai, por sua responsabilidade e dedicação em tudo o que se propõe a fazer. Você me inspira. A meu irmão, por sua paciência e amizade incondicionais. A meus colegas de engenharia, por trazerem alegria nos momentos mais cansativos edesafiadores de minha vida. Nunca esquecerei as noites em claro estudando e as conversas intermináveis na procrastinação do estudo. Izumi, Lulis, Clara, Ana, Féfis, Marcão, TJ, Samuca, Pombo e tantos outros que tornam impossível dar a todos os espaço que aqui merecem. Obrigado por fazer da elétrica meu segundo lar. A meus mestres, pelo exemplo de coerência e paixão pelo trabalho. Particularmente ao professor Ricardo Zelenovsky, por toda a orientação e apoio nos becos sem saída. Seu bom humor é contagiante. A minha namorada, Marcela, por todo o apoio nas horas difíceis e por me fazer me esforçar sempre mais. Você me faz uma pessoa melhor. Um obrigado também aos companheiros de GPDS, sempre presentes para elucidar qualquer dúvidas e aliviar a tensão. Em particular gostaria de agradecer ao Mintsu, Thiago Alves, Raphael Hideki e Carlos Vinicius por suas contribuições valiosas ao presente trabalho. E um agradecimento especial a meu co-autor Sasaki, amigo sempre surpreendente, e meus parceiros de projeto Chico e Ana, por toda a dedicação e ânimo nos projetos que enfrentamos. Sem vocês esse projeto seria impossível. Otávio Viegas Caixeta ii

RESUMO O barramento USB se tornou o padrão em conexões entre computador e periféricos. A implementação de uma interface USB para um arranjo de microfones propicia uma oportunidade adequada de estudo desta tecnologia. O presente trabalho apresenta conceitos básicos de USB e programação de microcontroladores. São também estudados recursos da tecnologia USB específicos para dispositivos que lidam com áudio, bem como sua aplicação no desenvolvimentode umfirmware de captação sonora para o computador e uma interface gráfica para o tratamento dos sinais. O resultado deste trabalho em conjunto com o resultado do projeto de um front-end de 8 microfones [1] formam um ambiente suficiente para captação e tratamento de sinais sonoros na faixa de frequência da voz humana. Depois de captados pelos 8 microfones presentes no frontend, os sinais de áudio são digitalizados e transferidos ao PC pelo barramento USB. No PC, os sinais são tratados por rotinas em Matlab. O ambiente é todo controlado por estas rotinas, que têm o objetivo de receber os sinais capturados pelos microfones e estimar a direção de chegada deste conjunto de amostras. Para a estimação da direção de chegada são utilizados os métodos DS, CAPON, MUSIC e SPRIT [1]. ABSTRACT The Universal Serial Bus has become the more pervasive technology to connect peripherals to a PC. The implementation of a USB interface for a microphone array presents itself as a suitable opportunity for studying this technology. The present work yields basic USB and microcontroller programming concepts. Audiospecific USB functionality is also presented, as well as its application on firmware for audio capture peripherals. The results achieved in this work combined with those of an 8-microphone front-end [1], create an adequate workstation to record and process sound signals at the human voice frequency band. After being captured by the front-end s 8 mics, the audio signal is digitalized and sent to the PC through the USB port. Finally, Matlab routines process the sampled data on the PC. The process is completely managed by the afore-mentioned routines, whoseobjectiveis to receive the signal captured by the mics and estimate it s DOA (Direction Of Arrival). DS, CAPON, MUSIC and SPRIT methods are used to estimate the DOA [1]. iii

SUMÁRIO 1 INTRODUÇÃO.... 1 1.1 EVOLUÇÃO DAS INTERFACES DIGITAIS... 1 1.2 PROJETO PAI... 2 1.3 OBJETIVOS... 3 1.4 CONTEÚDO... 3 2 O BARRAMENTO USB... 5 2.1 ARQUITETURA... 5 2.1.1 FÍSICA... 5 2.1.2 LÓGICA... 6 2.2 BARRAMENTO FÍSICO... 7 2.3 PROTOCOLO DE COMUNICAÇÃO... 8 2.4 TIPOS DE PACOTES... 10 2.4.1 START OF FRAME - SOF... 10 2.4.2 PACOTES TOKEN - SETUP, IN E OUT... 11 2.4.3 PACOTES DE DADOS - DATA0, DATA1, DATA2 E MDATA... 11 2.4.4 PACOTES DE Handshake - ACK, NAK, STALL, NYET... 12 2.4.5 PACOTES ESPECIAIS - PRE, ERR, SPLIT E PING... 12 2.5 TIPOS DE TRANSAÇÕES... 13 2.5.1 INTERRUPT... 14 2.5.2 BULK... 14 2.5.3 ISOCHRONOUS... 15 2.5.4 CONTROL... 15 3 ENUMERAÇÃO... 17 3.1 ETAPAS DA ENUMERAÇÃO... 17 3.2 PC REQUESTS PADRÕES... 20 3.2.1 GET STATUS... 21 3.2.2 CLEAR FEATURE... 22 3.2.3 SET FEATURE... 22 3.2.4 SET ADDRESS... 23 3.2.5 GET DESCRIPTOR... 24 3.2.6 SET DESCRIPTOR... 25 3.2.7 GET CONFIGURATION... 26 3.2.8 SET CONFIGURATION... 26 3.2.9 GET INTERFACE... 27 3.2.10 SET INTERFACE... 27 3.2.11 SYNCH FRAME... 28 3.3 DESCRITORES... 28 3.3.1 DISPOSITIVO... 29 3.3.2 CONFIGURAÇÃO... 31 3.3.3 INTERFACE... 32 3.3.4 ENDPOINT... 33 3.3.5 TEXTO... 35 4 CLASSES... 37 4.1 HID (Human Interface Devices)... 38 v

4.2 MASS STORAGE... 38 4.3 VIDEO... 39 4.4 AUDIO... 39 4.5 HUB... 40 5 AUDIO CLASS... 41 5.1 ABRANGÊNCIA... 41 5.2 CARACTERÍSTICAS... 41 5.2.1 INTERFACES... 41 5.2.2 SINCRONIA... 42 5.2.3 TOPOLOGIA FUNCIONAL... 43 5.3 DESCRITORES... 47 5.3.1 DESCRITORES DA INTERFACE AUDIOCONTROL (AC)... 47 5.3.2 DESCRITORES DA INTERFACE AUDIOSTREAMING (AS)... 50 5.3.3 DESCRITORES DO endpoint AUDIOSTREAMING (AS)... 51 5.4 REQUESTS... 53 6 ARQUITETURA ARM E AT91SAM7S... 55 6.1 INTRODUÇÃO... 55 6.2 PRINCIPAIS CARACTERÍSTICAS... 55 6.3 CONVERSOR ANALÓGICO/DIGITAL (ADC)... 56 6.4 TIMER/COUNTER (TC)... 57 6.4.1 MODO DE CAPTURA... 58 6.4.2 MODO DE FORMA DE ONDA... 58 6.5 PORTA DE DISPOSITIVO USB (UDP)... 60 6.5.1 ENDPOINTS... 60 6.5.2 TRANSFERÊNCIA DE DADOS... 61 7 IMPLEMENTAÇÃO... 63 7.1 O PROJETO... 63 7.2 RESULTADOS... 68 7.3 FIRMWARE... 69 7.3.1 ESTRUTURA DE ARQUIVOS... 70 7.3.2 INICIALIZAÇÃO... 71 7.3.3 MÓDULO ADC... 71 7.3.4 MÓDULO USB... 71 7.3.5 MÓDULO DE TEMPORIZAÇÃO... 77 7.3.6 MÓDULO PRINCIPAL... 78 8 CONCLUSÕES... 81 REFERÊNCIAS BIBLIOGRÁFICAS... 83 ANEXOS... 85 I CÓDIGO FONTE... 87 I.1 GLOBALVAR.H... 87 I.2 MAPA.H... 87 I.3 MAIN.C... 89 I.4 ADCMODULO.C... 90 I.5 USBMODULO.C... 91 I.6 TIMERMODULO.C... 97 vi

LISTA DE FIGURAS 2.1 Arquitetura lógica da conexão USB... 6 2.2 Tipos de conectores USB... 7 2.3 Exemplo de codificação NRZI... 9 2.4 Exemplo de codificação NRZI com bit stuffing... 9 2.5 Esquema de frames e sub-frames do protocolo USB... 10 3.1 Detalhes da conexão do cabo USB... 17 3.2 Mapeamento dos bits do parâmetro bmrequest... 20 5.1 Símbolos dos terminais... 44 5.2 Símbolo da Unidade de Mixagem... 44 5.3 Símbolo da Unidade Seletora... 45 5.4 Símbolo da Unidade de Características... 45 5.5 Símbolos das PU 3D Stereo, Dolby Prologic, Chorus e Compressor de Banda Dinâmica... 46 5.6 Símbolo da Unidade de Extensão... 46 6.1 Diagrama de Blocos ADC... 57 6.2 Formas de onda de um TC no modo UP... 59 6.3 Formas de onda de um TC no modo UP/DOWN... 59 6.4 Transferência com atributo ping-pong... 61 7.1 Comparação entre representação signed e unsigned de uma variável... 64 7.2 Temporização do módulo ADC... 66 7.3 Resultados de teste de envio sequencial de números a 80 ksamples/s... 67 7.4 Interface desenvolvida para utilização do ambiente... 68 7.5 Diagrama simplificado do Projeto PAI... 69 7.6 Fluxograma da função ADC_Convert()... 72 7.7 Topologia de um microfone USB... 73 7.8 Hierarquia de descritores de um microfone USB... 74 7.9 Fluxograma da função IsConfigured(pAudio) do módulo USB... 76 7.10 Fluxograma do módulo principal... 79 vii

LISTA DE TABELAS 2.1 Pinagem dos cabos USB... 7 2.2 Estados lógicos do barramento USB... 8 2.3 Tipos de pacotes USB 2.0... 9 2.4 Pacote de inicio de quadro - SOF... 10 2.5 Pacotes de configuração - SETUP, IN e OUT... 11 2.6 Pacotes de dados - DATA0, DATA1, DATA2 e MDATA... 11 2.7 Pacotes de handshake - ACK, NAK, STALL e NYET... 12 2.8 Tipos de transferências USB e suas características... 13 3.1 Identificadores dos Standard PC Requests... 21 3.2 Seletores de modo de teste... 23 3.3 Tipos de Descritores... 29 3.4 Descritor de dispositivo - DEVICE... 30 3.5 Segundo descritor para dispositivos high-speed - DEVICE_QUALIFIER... 31 3.6 Descritor de configuração - CONFIGURATION... 31 3.7 Descritor de interface - INTERFACE... 33 3.8 Descritor de endpoint - ENDPOINT... 34 3.9 Descritor de string 0 - STRING... 35 3.10 Descritor de string - STRING... 36 5.1 Descritor de cabeçalho da Interface AC... 48 5.2 Descritor de terminal de entrada... 49 5.3 Descritor de terminal de saída... 49 5.4 Descritor de Interface AS específico da classe de áudio... 51 5.5 Descritor de endpoint isochronous expandido... 52 5.6 Descritor de endpoint isochronous específico da classe de áudio... 52 6.1 Características dos endpoints do UDP... 60 6.2 Características das transferências suportadas pelo UDP... 61 ix

LISTA DE SIMBOLOS Símbolos Gregos δ atraso [ms] Siglas AC ADC AIC ARM AS CI CRC DMA FIFO FINATEC FFT FU IRQ IT LSB MCK MIPS MPEG MSB MU NRZI OT PC PCM PLL PU RAM RISC SU TC U(S)ART UDP USB USB-IF XU AudioControl Analog to Digital Converter Audio Interface Class Advanced RISC Machine AudioStreaming Circuito Integrado Cyclic Redundancy Check Direct Memory Access First In,FirstOut Fundação de Empreendimentos Científicos e Tecnológicos Fast Fourier Transform Feature Unit Interrupt Request Input Terminal Least Significant Byte Main CLOCK Millions of Instructions Per Second Moving Picture Experts Group Most Significant Byte Mixing Unit Non Return to Zero Inverted Output Terminal Personal Computer Pulse Code Modulation Phase-Locked Loop Processing Unit Random Access Memory Reduced Instruction Set Complex Selector Unit Timer/Counter Universal (Synchronous)/Asyncrhonous Receiver-Transmitter USB Device Port Universal Serial Bus USB Implementers Forum Extension Unit xi

1 INTRODUÇÃO 1.1 EVOLUÇÃO DAS INTERFACES DIGITAIS Desde o início da era digital, com o advento dos primeiros computadores, estudou-se a possibilidade de interconexão entre sistemas digitais. Com o surgimento do micro-computador e o conceito de computador pessoal (PC) essa possibilidade se tornou uma necessidade. O computador pessoal precisa de periféricos para interfaceamento com o mundo real, inclusive com o próprio usuário. Entre outros exemplos de periféricos estão os dispositivos de interface humana tais como monitor, mouse e teclado. Para o PC original foram definidos dois padrões de comunicação: serial e paralelo. Nestes padrões, a conexão física de um único periférico é feita através de um cabo ligado a uma porta paralela ou serial do PC. A primeira porta paralela do PC utilizava sinal unidirecional no sentido PC periférico, mas em 1980 foram adicionados mais 8 sinais para comunicação na direção contrária. Nas versões seguintes, esforços foram feitos para tornar a comunicação mais eficiente através do uso de técnicas de controle de fluxo e compressão de dados. Já o sinal serial funcionava com bits sendo transmitidos em série por apenas um par de fios. O CI responsável por esta comunicação era chamado de UART (Universal Asynchronous Receiver-Transmitter) e seu desenvolvimento definiu a evolução da porta serial. As primeiras UARTs suportavam taxas abaixo de 9600 bps (aprox. 9600 bits por segundo). Um marco na evolução da comunicação serial foi a inclusão de uma FIFO (First In, First Out) na UART, pois isso possibilitou a transmissão serial de dados sem a total atenção do processador. Tanto a porta paralela quanto a serial atingiram seu ponto máximo de evolução. No entanto, ainda se sentia a necessidade de mais banda e mais portas de expansão. Com essa idéia em mente, em 1994 um grupo de sete empresas líderes da indústria de computadores fundou um consórcio para a criação de um novo padrão de conexão de periféricos. Nascia o barramento Universal Serial Bus, ousb.aintensão era de que a USB substituísse as portas serial, paralela, PS/2 e de jogos. Com o tempo, não só essas 1

tecnologias foram substituídas como ainda surgiram outras aplicações bastante criativas para o barramento USB, tornando-o de fato um tipo universal de conexão. Essa história de sucesso se deve em parte à especificação minuciosa do padrão USB. Na maioria dos projetos de interconexão com o PC, a interface USB é a que oferece mais vantagens. Além de ser o atual padrão para conexão de periféricos ao computador, a interface USB oferece alta taxa de transmissão de dados, até 480 Mbps, permite hot swap, ou seja, conexão e configuração sem a necessidade de reiniciar o computador, utiliza um protocolo de comunicação robusto com detecção e supressão automática de erros e ainda permite a alimentação do periférico pelo próprio barramento. O barramento USB se tornou bastante versátil e pode ser aplicado a praticamente qualquer dispositivo. Algumas funções como áudio, vídeo, transferência e armazenamento de arquivos foram previstas. Muitas outras podem ser implementadas à medida que forem criadas. 1.2 PROJETO PAI O arranjo de sensores em paralelo junto a uma unidade digital de processamento constitui uma ferramenta poderosa de processamento de sinais. Atualmente, diversas pesquisas são feitas usando arranjos de microfones em paralelo para aplicações com voz humana. Essa configuração além de aumentar a sensibilidade possibilita a seletividade espacial, melhorando assim a qualidade da onda sonora captada. O presente trabalho visa a implementação da interface USB entre um arranjo de microfones e um computador PC. Esta tarefa faz parte de um projeto maior chamado de projeto PAI - Prótese Auditiva Inteligente. O objetivo deste projeto é a estimação da direção de chegada da voz humana através do processamento do sinal obtido pelo arranjo de microfones. Como este processamento exige um grande esforço computacional, foi decidido que os sinais dos microfones seriam digitalizados por um microcontrolador e enviados para o PC, onde deles seriam estimados a direção de chegada. No projeto PAI foi especificado um arranjo composto por oito microfones, cada um com banda de 5 khz, suficiente para registrar claramente a voz humana. A amostragem do sinal seria feita a 10 khz de forma a satisfazer o teorema da amostragem de Nyquist. Para enviar o sinal ao PC, optou-se pelo uso de um microcontrolador com arquitetura ARM. Essa arquitetura foi escolhida por sua universalidade e facilidade 2

de emprego. O microcontrolador será a ponte entre o arranjo de microfones e o computador, utilizando o barramento USB como meio físico para a transferência dos dados captados pelos microfones. [1] O projeto PAI foi dividido em duas frentes paralelas de trabalho: o desenvolvimento de um hardware front-end de captura dos sinais analógicos e o de um software de captura e tratamento digital dos sinais. O hardware consiste no projeto de um dispositivo para a captura de sinais sonoros utilizando o arranjo de microfones em paralelo. O projeto do front-end envolve não só os sensores sonoros bem como a filtragem, pré-amplificação e entrega dos sinais analógicos adquiridos ao módulo de conversão analógico/digital. A frente de software, contemplada neste trabalho, ficou responsável por digitalizar os sinais e enviá-los em tempo hábil para o PC através do barramento USB. Também é responsabilidade da frente de software o recebimento dos dados pelo computador e sua entrega às rotinas que estimam a direção de chegada. 1.3 OBJETIVOS Este sub-projeto tem como um dos objetivos desenvolver um firmware para a plataforma ARM escrito em linguagem C que satisfaça a especificação USB 2.0. Após a implementação da interface USB o firmware deve receber os sinais digitalizados de oito microfones, realizar um processamento mínimo dos sinais e em seguida transferí-los para o computador, onde será feita a maior parte do processamento. É também tarefa deste projeto desenvolver uma plataforma, residente no computador, que realize o recebimento dos sinais amostrados e estime a direção de chegada utilizando os programas já desenvolvidos. 1.4 CONTEÚDO Inicialmente, no capítulo 2, será feita uma introdução às características do barramento USB. Nas seções seguintes são apresentadas a especificação para o desenvolvimento de um dispositivo USB 2.0 (capítulo 3) e as possibilidades de funções que esses dispositivos podem agregar (capítulos 4 e 5). Enfim as características da arquitetura ARM são discutidas no capítulo 6, seguidas pelo desenvolvimento e resultados no capítulo 3

7 e as conclusões do trabalho nocapítulo 8. 4

2 O BARRAMENTO USB 2.1 ARQUITETURA A arquitetura USB é composta basicamente por três elementos bem definidos: o hospedeiro, ou host, o dispositivo, ou device, e a interconexão entre eles. Na interconexão é definida a topologia do barramento USB, os modelos de transferência de dados e o agendamento de transferências. 2.1.1 Física O barramento foi definido no formato mestre-escravo, onde o host é o mestre e detém total controle sobre o barramento. Somente o host pode iniciar uma transferência, o que torna o desenvolvimento dos dispositivos mais simples, pois estes apenas devem obedecer aos pedidos feito pelo host. Assim sendo, todas as transferências são referenciadas ao host. Ofluxo de dados saindo dos dispositivos em direção ao controlador host é chamado de upstream, enquanto que o fluxo de dados no sentido contrário é chamado de downstream. Esta simplicidade no projeto do dispositivo vem ao custo de uma maior complexidade no software do host. Entre as tarefas por ele acumuladas estão o controle e gerenciamento de todas as transferências, a alimentação dos dispositivos a ele conectados e verificação constante da conexão de novos dispositivos. No barramento pode existir apenas um host que é definido por um host controller. Aestehost controller está integrado um root hub que proporciona uma ou mais portas. A topologia do barramento USB pode ser composta por até 127 dispositivos, entre hubs e funções. Os hubs aumentam a quantidade de dispositivos que podem ser conectados ao barramento adicionando mais portas. No entanto, é definido pela especificação que um dispositivo pode ser conectado com no máximo 5 níveis de hubs entre ele e o root hub. Três velocidades são especificadas para o barramento USB, low-speed de 1.5 Mb/s para dispositivos que não necessitam de muita banda, full-speed de 12 Mb/s e high-speed de 480 Mb/s. Esta última velocidade foi definida pela versão 2.0 da especificação USB. 5

2.1.2 Lógica Um PC host cria dados para, ou consome dados do mundo real. Os dispositivos USB são responsáveis pela transdução desses dados. Devido à grande variedade de funções que podem ser empregadas, uma estrutura lógica bem definida foi especificada para o caminho desses dados. A estrutura lógica de conexão USB pode ser vista na figura 2.1. Figura 2.1: Arquitetura lógica da conexão USB Otermoendpoint é utilizado para descrever um ponte de entrada ou saída de dados de um sistema USB. O conjunto de um ou mais endpoints que implementam uma conexão com o mundo real é chamado de interface. Cada interface está associada a um device driver no host através de somente um pipe, ou canal. Um dispositivo pode ter mais de uma interface e todas elas funcionam em paralelo, cada uma com seu respectivo driver. Um conjunto de interfaces pertence a uma configuração, e somente uma configuração pode estar ativa num dado momento. 6

2.2 BARRAMENTO FÍSICO O barramento físico USB é composto por quatro condutores: V bus, D+, D- e GND. Os dados são transmitidos de forma diferencial pelos condutores D+ e D-. OsinalV bus é responsável por fornecer alimentação aos dispositivos. Essa alimentação tem um limite máximo de 100 ma e, devido à sua praticidade, ajudou a tornar o padrão USB muito popular. Tabela 2.1: Pinagem dos cabos USB Pino Sinal Cor 1 V bus (5V ou 3V3) vermelho 2 D- branco 3 D+ verde 4 GND preto Os cabos USB possuem especificações distintas para os terminais de upstream (conector tipo A) e downstream (conector tipo B). Há um outro padrão para conectores downstream, que foi aprovado pelo USB Implementers Forum (USB-IF) somente após a versão 1.1 da especificação USB. Este padrão, usado principalmente para dispositivos menores, é chamado de mini-b. Os cabos USB podem ter um comprimento máximo de 5 metros. Os conectores podem ser visto na Figura 2.2. (a) Conector tipo A (upstream) (b) Conector tipo B (downstream) Figura 2.2: Tipos de conectores USB O cabo USB deve ser blindado com impedância de 90 Ω entre os condutores diferenciais D- e D+. Tanto os dispositivos quanto os hubs devem possuir resistores de pull-up ou pull-down conectados a esses condutores. Nos hubs, tantod- quanto D+ são conectados a resistores de pull-down para garantir o estado D0 quando não há nenhum dispositivo ou hub conectado à porta. Nos dispositivos, a configuração dos resistores de pull-up define sua velocidade. Um resistor conectado a D- indica operação a 1,5 Mb/s enquanto que se estiver conectado a D+ indica operação a 12 Mb/s. Os dispositivos high-speed são inicialmente configurados como full-speed e durante a enumeração negociam a velocidade de 480 Mb/s com o host. 7

Valores típicos para os resistores são de 15 kω para os de pull-down ede1,5kω para os de pull-up. 2.3 PROTOCOLO DE COMUNICAÇÃO Conforme dito anteriormente, os sinais D+ e D- são responsáveis pela comunicação serial no barramento. Para tanto, a especificação USB define 3 estados lógicos como vistos na Tabela 2.2. Tabela 2.2: Estados lógicos do barramento USB Estado Low Speed High/Full Speed D- D+ K J baixo alto J K alto baixo SE0 SE0 baixo baixo Existe ainda um estado chamado idle, ou ocioso, que representa a ausência de atividade no barramento. Para dispositivos low-speed ou full-speed, este estado é equivalente ao estado J. A comunicação entre o host e um dispositivo USB é feita através de transações compostas por pacotes. O primeiro pacote é sempre enviado pelo host. Dependendo do tipo de transação, os pacotes seguintes podem ser iniciados tanto por um hub, quanto por uma função [2]. Os pacotes são constituídos de pelo menos três campos: um de sincronização, chamado de SYNC, um de identificação do pacote chamado de PID (Packet IDentificator) eoeop(end Of Packet) indicando o fim do pacote, definido por dois SE0. Entre o campo de PID e o campo EOP pode haver um campo de dados de no máximo 8 bytes para um dispositivo low-speed, 1023 para um full-speed e 1024 bytes para um high-speed. O campo SYNC é uma sequência KJKJKJKK de 8 bits para dispositivos low/full-speed; jáparao high-speed, o SYNC é formado de 15 transições KJ mais o KK no final, totalizando 32 bits. O PID identifica o tipo de pacote, sendo ele composto por quatro bits identificadores seguidos pelo seu complemento, totalizando 8 bits. Os tipos de pacotes e seus respectivos PID estão listado na Tabela 2.3. Para a transmissão de dados é utilizado a codificação NRZI (Non Return to Zero Inverted). Nesta codificação, o 0 é representado pela inversão de estado nas linhas D- e D+, ou seja, de J para K ou viceversa. Já 1 é representado mantendo-se os estados. Este esquema pode ser visto na Figura 2.3. 8

Tabela 2.3: Tipos de pacotes USB 2.0 PID pacote tipo 0101 SOF 1101 SETUP token 1001 IN 0001 OUT 0011 DATA0 data 1011 DATA1 0111 DATA2 1111 MDATA 0010 ACK 1010 NACK handshake 1110 STALL 0110 NYET 1100 PRE 1100 ERR special 1000 SPLIT 0100 PING 0000 (reservado) (reservado) Figura 2.3: Exemplo de codificação NRZI Visto que o CLOCK do barramento é transmitido através das transições das linhas D- e D+, a especificação USB determinou a inserção de um bit de stuffing, de forma que as linhas não permanecessem muito tempo em um mesmo estado durante a transmissão de uma sequência de 1 s. Assim, a cada seis bits 1, um 0 é enviado de forma redundante. Um exemplo pode ser visto na Figura 2.4 Figura 2.4: Exemplo de codificação NRZI com bit stuffing 9

2.4 TIPOS DE PACOTES A seguir será explicado um pouco do que significa cada pacote e como eles são usados para organizar as transações pelo barramento USB. 2.4.1 Start Of Frame - SOF Este pacote é enviado pelo host a cada 1 ms com a única finalidade de sincronismo. Ele é enviado a todos os dispositivos conectados ao barramento, ou seja, não tem distinção de endereço. Este pacote marca o início de um frame (ou quadro). No caso de um root hub high-speed, um quadro é dividido em 8 sub-quadros. Isto é feito usando SOFs adicionais. Sendo assim, cada sub-quadro tem uma duração de 125 μs. A Figura 2.5 mostra esse esquema de quadros e sub-quadros. Figura 2.5: Esquema de frames e sub-frames do protocolo USB No campo de dados desse pacote é enviado um contador crescente de quadros de 11 bits com mais 5 bits de CRC (Cyclic Redundancy Check) para checagem de erros durante a transmissão. Tabela 2.4: Pacote de inicio de quadro - SOF KJKJ..KK 8bits 11 bits 5bits 2xSE0 SYNC PID contador de quadros CRC EOP O CRC é gerado pelo transmissor apenas com os bits do campo de dados anterior ao CRC. Quando o pacote chega ao receptor, este cria um CRC a partir dos bits recebidos e, caso não seja igual ao CRC recebido, rejeita o pacote. 10

2.4.2 Pacotes Token - SETUP, IN e OUT Os pacotes SETUP, IN e OUT são pacotes token enviados por hubs para indicar qual dispositivo vai participar da transação. O pacote SETUP é sempre endereçado ao endpoint 0 de um dispositivo, indicando que o host quer enviar algum comando de controle. Ele deve ser atendido o quanto antes, interrompendo qualquer outra transação. Pacotes IN e OUT são endereçados a qualquer endpoint de um dispositivo e indicam a direção do próximo pacote; IN é de leitura da função e OUT de escrita da função. O campo de dados do pacote é formado por 7 bits de endereçamento do dispositivo, 4 bits de identificação do endpoint e mais 5 bits de CRC. Tabela 2.5: Pacotes de configuração - SETUP, IN e OUT KJKJ..KK 8bits 7bits 4bits 5bits 2xSE0 SYNC PID ADDR ENDP CRC EOP 2.4.3 Pacotes de Dados - DATA0, DATA1, DATA2 e MDATA Os pacotes de dados são enviados logo após um pacote de token, dohost para o dispositivo se o pacote de token foi um SETUP ou um OUT e no sentido contrário se o token foi do tipo IN. O formato básico do campo de dados desse pacote é constituído pela informação, que varia de 0 a 1024 bytes mais 16 bits de CRC. Tabela 2.6: Pacotes de dados - DATA0, DATA1, DATA2 e MDATA KJKJ..KK 8bits 0 a 1.023 x 8 bits 16 bits 2xSE0 SYNC PID informação CRC16 EOP De forma a garantir a sincronização e sequência dos pacotes de dados, o protocolo USB utiliza um mecanismo chamado Data Toggle em alguns tipos de transmissão. Quando a informação a ser enviada ultrapassa o limite de 1024 bytes do pacote, ela é separada em vários pacotes que são mandados em sequência, alternando entre DATA0 e DATA1. No receptor os dados são validados apenas se a sequência for respeitada. Se ocorrer algum erro e dois pacotes DATA0 ou DATA1 forem recebidos em sequência, o receptor indica um erro na transmissão. Na especificação 2.0 foram adicionados os pacotes DATA2 e 11

MDATA, utilizados apenas para transferências do tipo isochronous em high-speed. 2.4.4 Pacotes de Handshake - ACK, NAK, STALL, NYET Os pacotes de handshake são utilizados para negociar o estado da transação. Eles vão sempre na direção oposta à do último pacote enviado. Seu campo de dados é nulo. Tabela 2.7: Pacotes de handshake - ACK, NAK, STALL e NYET KJKJ..KK 8bits 2xSE0 SYNC PID EOP ACK indica o recebimento com sucesso do pacote de dados ou de um token. NAK indica que o receptor por algum motivo não está apto a receber o pacote anterior. STALL indica que o receptor detectou um erro na transmissão, como um pedido inválido. O pacote NYET, implementado na versão 2.0 da especificação, é uma resposta ao pacote PING enviada pelo host. Esse pacote será melhor explicado mais adiante. 2.4.5 Pacotes Especiais - PRE, ERR, SPLIT e PING A maioria dos pacotes dessa categoria é utilizada pelo host para se comunicar com hubs. O pacote PRE é utilizado pelos hubs para indicar uma transação com um dispositivo low-speed. Os pacotes ERR e SPLIT são utilizados em transações com hubs para diminuir a armazenagem de dados pelo hub, sendo o primeiro utilizado para indicar um erro nessa operação. O pacote PING foi especificado na versão 2.0 para tornar o uso do barramento mais eficiente para dispositivos high-speed. Aoinvésdohost mandar sempre um pacote de dados OUT com o risco de receber um NAK, é enviado um pacote PING, que por ser bem menor utiliza menos banda do barramento. Caso o dispositivo esteja inapto a receber o pacote de dados ele deve responder com um NYET. O host então vai continuar enviando pacotes PING até que o dispositivo responda com um ACK, quando então o pacote de dados será finalmente transmitido. 12

2.5 TIPOS DE TRANSAÇÕES Todas as transações USB são compostas pelos pacotes abordados na seção anterior. Uma transação deve ocorrer dentro de um mesmo quadro (ou microquadro) e quando iniciada não pode ser interrompida por outras transações até o seu término. As transações são compostas por três estágios. O primeiro estágio é sempre efetuado pelo host. Nele é enviado um dos pacotes token com as configurações da transação. No segundo estágio é feita a transferência de dados na direção especificada pelo pacote token. No terceiro estágio são enviados os pacotes de handshake confirmando o recebimento dos dados. A direção do segundo e do terceiro estágio são sempre opostas. Uma transferência pode conter uma ou mais transações. De acordo com a especificação USB, são definidos quatro tipos de transferências: Interrupt (interrupção), Bulk (volumosa), Isochronous (isócrona) e Control (controle)[2]. Cada tipo de transferência é definida para diferentes tipos de dados que podem ser transmitidos. As principais características dos tipos de transferência podem ser vistos na Tabela 2.8. Tabela 2.8: Tipos de transferências USB e suas características tamanho máximo tipo caracteristicas LS FS HS Interrupt tempo e integridade 8 64 3072 Bulk integridade - 64 512 Isochronous tempo - 1023 3072 Control tempo e integridade 8 64 64 Os parâmetros para classificar os tipos de transferência são tempo e integridade dos dados. Tipos de transferências onde o tempo é fator crítico são aquelas em que os dados devem ser entregues a uma taxa definida e qualquer informação corrompida durante a transmissão perde sua importância, ou seja, são descartadas. Como exemplo têm-se os sinais de áudio e vídeo. No entanto, transferências onde a maior importância está na integridade dos dados entregues utilizam algumas técnicas de detecção e correção de erros, como o esquema de acknoledgment e retransmissão de pacotes. Assim, a taxa de informação pode não ser constante. A seguir serão detalhadas as características de cada tipo de transferência. 13

2.5.1 Interrupt As transações do tipo interrupt são recomendadas para transmissões que requerem tanto uma certa taxa quanto acurácia nos dados transmitidos. Apesar do nome, ela é feita de forma que o host use um polling periódico para checar por novos dados. Quando o buffer de envio ou de recepção deve receber novos dados, aquele endpoint ativa uma flag indicando o pedido de transmissão. Estas flags são verificadas pelo host. Os dados são então enviados ou recebidos a uma taxa baixa, usando todos os artifícios de tratamento de erros disponíveis. O host garante no máximo uma transmissão do tipo interrupt por quadro. Geralmente, os dispositivos que utilizam esse tipo de transferência utilizam uma taxa com período de alguns milisegundos. Ataxadepolling é pré-configurada e agendada pelo controlador host. Dentro dessa taxa o host inicia a transação enviando um pacote token do tipo IN ou OUT e o dispositivo deve responder de acordo. No caso da transação ser do tipo IN, o dispositivo envia um pacote de dados e espera um ACK do host, massenão houver nenhum dado novo para envio ele apenas responde com um NACK. No caso da transação ser do tipo OUT o dispositivo deve estar preparado para receber um pacote de dados do host e, após o recebimento, deve responder com um ACK, ou NAK caso ocorra algum erro durante a transação. O dispositivo ainda pode responder com um STALL caso algum erro grave aconteça. 2.5.2 Bulk A transação do tipo bulk utiliza exatamente os mesmo pacotes das transações do tipo interrupt. A diferença está no agendamento. O host aloca todo o espaço não utilizado de um quadro (ou sub-quadro) para as transações do tipo bulk. Essas transações têm como característica a acurácia dos dados. Logo, são utilizados pacotes de dados do tipo DATA0 e DATA1 para sincronização e checagem de erros. Os pacotes podem ser validados com ACKs ou descartados caso os CRC sejam diferentes. Neste caso é enviado um NAK e o pacote de dados deve ser retransmitido. Em dispositivos high-speed podem ser utilizados os pacotes do tipo PING e NYET para tornar a transferência mais eficiente e fazer melhor uso do barramento. 14

2.5.3 Isochronous Às transações do tipo isochronous são garantidas um pedaço de cada quadro (ou sub-quadro). Nessas transações os pacotes de handshake não são utilizados, pois um dado atrasado é tão inútil quanto dado nenhum [3]. Os dados são transmitidos em pacotes do tipo DATA0 que podem conter de 0 a 1023 bytes. Quando um dispositivo que utilize esse tipo de transação é conectado ao barramento, o host deve garantir a banda requerida pelo dispositivo. A banda requerida será garantida em cada quadro (sub-quadro), porém não será garantida a sua posição dentro do mesmo, podendo haver jitter, ou pequenas variações na taxa de entrega dos dados. Caso essa banda não esteja disponível o dispositivo não será inicializado e a conexão não será estabelecida. Para dispositivos full-speed, que requerem uma banda larga, podem ser agendadas até três transações isochronous. Nesse caso obtém-se uma banda de 53 MB/s. Pacotes token adicionais são utilizados para a checagem de erros nas três transações. Esse procedimento é feito entre o host eohub e é totalmente transparente do ponto de vista do dispositivo. 2.5.4 Control Transações do tipo control são geralmente endereçadas ao endpoint 0 e carregam os pedidos prédefinidos do protocolo USB, chamados de device requests. Essas transações são as mais complexas, pois devem ser tratadas imediatamente e não toleram a existência de erros. Por isso, grande esforço foi colocado na especificação desse tipo de transação. Uma transação do tipo control tem três fases. A primeira, chamada de setup, consiste em um pacote do tipo SETUP, um pacote de dados de tamanho fixo igual a 8 bytes e um pacote de handshake. A segunda fase, a de dados, é opcional. Ela consiste em um ou mais pacotes de dados, todos eles precedidos de um pacote de IN ou OUT e seguidos de um pacote de handshake. O final dessa fase é sinalizado com um pacote curto, ou seja, que não utiliza o tamanho máximo do pacote. A última fase, chamada de Status, é utilizada para confirmar a recepção da fase de setup ou de dados. Essa fase é composta de um pacote IN ou OUT, dependendo da direção da fase anterior, um pacote de dados de tamanho igual a zero e um pacote de ACK. Caso a fase anterior não seja validada pelo dispositivo, esta fase consistirá em um pacote do tipo 15

IN e um NAK ou STALL. Na fase de setup é sempre enviado um pacote do tipo DATA0 de 8 bytes. Os dados desse pacote são pré-definidos pela especificação USB. São 5 parâmetros utilizados para definir o tipo de pedido: bmrequesttype, brequest, wvalue, windex e wlength. O primeiro parâmetro, bmrequesttype, usa 8 bits para indicar a direção da próxima transação, o tipo de pedido e o destinatário do pedido. O segundo parâmetro, brequest, indica qual informação o host está pedindo com 1 byte. Os próximos três parâmetros são de 2 bytes e são utilizados como suporte para os dados trocados. O parâmetro wvalue é utilizando quando apenas um byte ou palavra é requerida. windex é utilizado quando um único índice é requerido. O parâmetro wlength, quando maior que um, indica o tamanho da próxima transferência de dados. Além dos pedidos padrões, cada classe tem seus pedidos específicos e outros ainda podem ser criados pelo próprio fabricante. Esses pedidos serão melhor explorados mais adiante. 16

3 ENUMERAÇÃO A proposta do padrão USB foi a de criar um barramento de expansão para qualquer tipo de dispositivo, de forma que a conexão de novos dispositivos aconteça sem a intervenção do usuário. Para isso, o conceito de plug and play foi expandido e aplicado a todos os dispositivos USB. Dessa forma o usuário não precisa se preocupar com configurações de endereços, portas, IRQs ou DMAs. O processo de enumeração é realizado quando um dispositivo novo é detectado. Esse processo se encarrega das configurações, inclusive da escolha e instalação do driver correto para o dispositivo. 3.1 ETAPAS DA ENUMERAÇÃO A enumeração se inicia com a detecção de um novo dispositivo. Este trabalho é realizado pelo hub, seja ele embarcado no controlador host ou um dispositivo físico conectado a uma das portas do primeiro. A partir do momento em que o host é iniciado, este faz um polling periódico no root hub a fim de descobrir se algum dispositivo novo foi conectado ao barramento. Todos os hubs devem responder a esse polling indicando os dispositivos detectados por eles ou simplesmente enviar um NAK caso nada tenha mudado desde o último pedido. Figura 3.1: Detalhes da conexão do cabo USB Como dito anteriormente, os hubs têm resistores de pull-down de cerca de 15 kω, conectados às linhas D- e D+ de cada uma de suas portas, o que mantém as tensões nessas linhas próximas de zero. Quando um 17

dispositivo é conectado, a tensão em uma das linhas se eleva para próximo de V bus. Isso acontece por que os dispositivos têm resistores de pull-up de 1,5 kω ligados à linha D- (low-speed 1,5 Mb/s) ou à linha D+ (full-speed 12 Mb/s), detalhes podem ser vistos na Figura 3.1. O divisor resistivo faz com que o nível de tensão na linha fique mais próximo de V bus.ohub, ao sentir essa mudança de nível informa ao host,no próximo polling, que um novo dispositivo foi conectado ao barramento. Antes de conectado, o dispositivo se encontra no estado unattached. Ao ser conectado ao hub, o dispositivo passa para o estado attached. Comoohub já se encontra configurado e em operação, o dispositivo logo passa para o estado powered. Ohub então atualiza o estado do dispositivo num registrador de status e espera pedidos do host. Nesse momento se inicia o processo de enumeração totalmente controlado pelo host. Este vai enviar pedidos tanto para o hub ao qual o dispositivo foi conectado quanto para o próprio dispositivo, afim de conhecê-lo e configurá-lo apropriadamente. O seguinte processo exemplifica os pedidos feito por um host em plataforma Windows. De forma a ser compatível com qualquer plataforma, o dispositivo deve estar preparado para receber os pedidos em qualquer ordem e a qualquer momento, respondendo apropriadamente a cada um. 1. Request: Get_Port_Status. Para: hub. O host detecta um novo dispositivo. 2. Request: Clear_Port_Feature(C_PORT_CONNECTION). Para: hub. Limpa a flag indicando uma mudança de estado na porta do hub. 3. Request: Set_Port_Feature(PORT_RESET). Para: hub. O hub responde mandando um reset para o dispositivo. O hub mantém o reset por 10 ms e então habilita a porta. O PC host vai detectar essa mudança no próximo período de polling. É durante esse tempo de reset que o hub configura a velocidade do dispositivo. Se detectar uma tensão alta em D-, configura o dispositivo em low-speed. Se detectar nível alto em D+, configura como full-speed. Se o dispositivo suportar high-speed, ele primeiramente é configurado como full-speed e dentro desses 10 ms de reset ele manda um sequência de KJKJ... em alta velocidade. Se o hub suportar high-speed ele vai detectar essa sequência e responder ao dispositivo, configurando-o como high-speed. Caso contrário, o hub não consegue detectar essa sequência de KJKJ... e não responderá, fazendo com 18

que o dispositivo permaneça configurado como full-speed. 4. Request: Get_Port_Status. Para: hub. O host espera até que o dispositivo tenha retornado do estado de reset. 5. Request: Clear_Port_Feature(C_PORT_RESET). Para: hub. Limpa aflag no registrador do hub. Nesse ponto o dispositivo está alimentado e já foi reiniciado, logo ele se encontra no estado default. O dispositivo a partir de agora vai responder aos pedidos enviados ao endereço 0 (endereço padrão). Como o processo de enumeração ocorre de forma exclusiva apenas um dispositivo responderá pelo endereço padrão. 6. Request: Get_Device_Descriptor. Para: dispositivo. O dispositivo responde enviando o device descriptor, ou descritor do dispositivo. 7. Request: Set_Address. Para: dispositivo. OPChost aloca um endereço para o dispositivo. A partir desse momento todos os pedidos para esse dispositivo serão enviados para esse endereço. O dispositivo deve guardar o endereço e responder a todos os pedidos endereçados a ele. 8. Request: Get_Device_Descriptor. Para: dispositivo. O PC host repete este pedido para o novo endereço como verificação. Ele deve obter exatamente a mesma resposta obtida no pedido 6. 9. Request: Get_Configuration_Descriptor. Para: dispositivo. O PChost começa a coletar maiores informações sobre o dispositivo, suas configurações, interfaces e endpoints. Nesse ponto pode ser necessário intervenção do usuário, mas geralmente não é o caso. 10. Seleção do driver. O PC host inicia a busca por drivers para o dispositivo. Primeiramente, ele tenta encontrar um arquivo.inf com VendorID e ProductID equivalentes aos coletados durante a enumeração. Não encontrando, ele vai então analisar se o dispositivo se encaixa em uma classe específica e, caso consiga, vai carregar os drivers USB padrão. Caso não tenha obtido sucesso em nenhuma destas tentativas o usuário será perguntado pelos drivers do dispositivo. 19

11. Request: Set_Configuration. Para: dispositivo. O dispositivo agora se encontra configurado e operacional, passando para o estado configured. 3.2 PC REQUESTS PADRÕES PC Requests são todos os pedidos enviados pelo host por um canal de controle, normalmente pelo endpoint 0 que é obrigatório em todo dispositivo. Este canal de controle está sempre aberto e operacional. Nessa seção serão explorados todos os Standard PC Requests, que são os pedidos mínimos ao qual um dispositivo deve responder, listados na Tabela 3.1. Os pedidos são totalmente definidos por dois parâmetros, o bmrequesttype eobrequest. Oparâmetro bmrequesttype é mapeado bit a bit da seguinte maneira: o bit 7 define a direção da fase de dados que segue afasedesetup, os bits 6..5 definem o grupo ao qual o pedido pertence e os bits 4..0 definem o destinatário do pedido. Os possíveis valores podem ser vistos na Figura 3.2, valores não mostrados são reservados. Figura 3.2: Mapeamento dos bits do parâmetro bmrequest Já o parâmetro brequest é um valor correspondente ao pedido, como pode ser visto na tabela 3.1. Devido à sua importância, os pedidos padrões serão explicados um a um. Vale notar que a USB representa variáveis de mais de um byte na forma little-endian. Dessa forma, o primeiro byte representado é o menos significativo (LSB, Less Significant Byte), seguido pelo byte mais significativo (MSB, Most Significant Byte). 20

Tabela 3.1: Identificadores dos Standard PC Requests brequest Requests 0 GET_STATUS 1 CLEAR_FEATURE 2 Reservado 3 SET_FEATURE 4 Reservado 5 SET_ADDRESS 6 GET_DESCRIPTOR 7 SET_DESCRIPTOR 8 GET_CONFIGURATION 9 SET_CONFIGURATION 10 GET_INTERFACE 11 SET_INTERFACE 12 SYNCH_FRAME 3.2.1 Get Status Esse pedido retorna o atual status do destinatário especificado. bmrequesttype: 10000000b (dispositivo), 10000001b (interface), 10000010b (endpoint). brequest: GET_STATUS. wvalue: zero. windex: especifica a interface ou endpoint. É igual a zero se for destinada ao dispositivo. wlength: dois. Dados: status do dispositivo, interface, ou endpoint. Este campo é mapeado bit a bit e seus valores dependem do destinatário do pedido. Para o dispositivo, o bit 0 indica se este está atualmente alimentado externamente (1) ou pelo barramento (0), e o bit 1 indica se o dispositivo está atualmente habilitado para remote wakeup (1). O valor padrão para esse bit é 0, ou desabilitado. O valor do bit 1 pode ser alterado com os pedido SET_FEATURE e CLEAR_FEATURE. Todos os outros bits são reservados e devem ser iguais a zero. Para interface nenhum bit é especificado, todos são reservados e devem ser igual a zero. Para endpoint, somente o bit 0 é especificado, ele indica se o endpoint está inoperante (halt) (1), ou em operação normal (0). Esse bit pode ser modificado com os pedidos SET_FEATURE e CLEAR_FEATURE. 21

Estados válidos: addressed e configured. Caso o pedido especifique uma interface ou endpoint que não exista o dispositivo responde com STALL. 3.2.2 Clear Feature Este pedido é utilizado para desativar uma feature, ou função, do dispositivo, interface ou endpoint. bmrequesttype: 00000000b (dispositivo), 00000001b (interface), 00000010b (endpoint). brequest: CLEAR_FEATURE. wvalue: feature, ou função. Os valores possíveis de função dependem do bmrequesttype. Se for para endpoint, tem apenas a função ENDPOINT_HALT (0) que coloca um endpoint em estado inoperante. Para o dispositivo, tem duas funções, DEVICE_REMOTE_WAKEUP (1) que habilita o dispositivo a retirar o host do estado suspenso, e TEST_MODE (2) que ativa a bateria de testes definidas na especificação USB. Para interface não tem nenhuma função definida. windex: indica qual interface ou endpoint é o destinatário. No caso em que o dispositivo é o destinatário, o valor é igual a zero. wlength: zero. Dados: vazio. Estados válidos: addressed: somente para o endpoint 0; configured. Em caso de erro: o dispositivo deve responder com um STALL. 3.2.3 Set Feature Este pedido é utilizado para habilitar uma certa função. bmrequesttype: 00000000b (dispositivo), 00000001b (interface), 00000010b (endpoint). brequest: SET_FEATURE. 22