UFMG - ICEx DEPARTAMENTO DE CIÊNCIA DA C O M P U T A Ç Ã O UNIVERSIDADE FEDERAL DE MINAS GERAIS Um agente embutido para conversão de uma interface serial em USB NÚMERO Ana Luiza de Almeida Pereira Zuquim ana@dcc.ufmg.br MÊS ANO PUBLICAÇÃO
Resumo Este documento tem como objetivo descrever o processo de desenvolvimento de um conversor de interface serial para USB Universal Serial Bus genérico, utilizando como exemplo de dispositivo o no-break da Engetron. USB é um novo padrão de conexão de periféricos criado com o objetivo de facilitar a conexão de periféricos e torná-la eficiente. Permite a conexão de até 127 dispositivos simultaneamente e reduz o custo para o usuário final. Foi criado em função da crescente demanda por interfaces de comunicação, uma vez que o número de dispositivos conectados ao microcomputador também cresceu muito, tornando o número de portas de comunicação existentes nos micros de hoje insuficiente para as aplicações existentes. Outras características, como velocidade de transmissão/recepção destas portas e dificuldade de configuração para o usuário final, estimularam a criação de um novo protocolo, mais fácil, rápido e eficiente. Apesar da especificação do protocolo USB trazer inúmeros benefícios, é necessário prover uma forma de se manter a compatibilidade com os equipamentos já existentes. Considerando que o protocolo serial é um dos protocolos mais utilizados nos dias de hoje, o projeto de um conversor de interface serial para USB é de grande valor prático.
ÍNDICE RESUMO 2 1 INTRODUÇÃO 4 2 USB VISÃO GERAL 5 2.1 CARACTERÍSTICAS FUNCIONAIS 5 2.2 CLASSES USB 7 2.2.1 HUMAN INTERFACE DEVICE CLASS (HID) 7 2.3 TIPOS DE TRANSFERÊNCIAS 8 2.4 REQUISIÇÕES 9 3 ESPECIFICAÇÃO DO SISTEMA 9 3.1 REQUERIMENTOS DO HOST 9 3.2 REQUERIMENTOS DO DISPOSITIVO 10 4 DESCRIÇÃO DO HARDWARE 11 5 PROJETO E IMPLEMENTAÇÃO DO SOFTWARE 12 5.1 DEFINIÇÃO DOS DESCRITORES 12 5.2 ROTINAS DE INTERRUPÇÃO NOS ENDPOINTS 16 5.3 DETECÇÃO E ENUMERAÇÃO DO DISPOSITIVO 17 5.4 O PROCESSO DE ENVIO E RECEPÇÃO DE DADOS 18 6 DRIVERS E APLICAÇÕES 18 7 CONCLUSÕES 19 AGRADECIMENTOS 19 REFERÊNCIAS BIBLIOGRÁFICAS 19 ANEXO A 20
1 Introdução Este documento descreve a especificação e implementação de um conversor de interface serial para interface USB Universal Serial Bus. O conversor é responsável por receber dados de uma interface serial de um periférico (ou dispositivo) e repassá-los à interface USB de um microcomputador, permitindo, da mesma forma, o envio de dados do PC para o dispositivo. Em função da crescente demanda por interfaces de comunicação, provocada por um número cada vez maior de periféricos conectados ao computador, o número de portas de comunicação disponíveis nos micros de hoje tornou-se insuficiente para a gama de aplicações existentes. Além disso, características como velocidade de transmissão/recepção das portas existentes e dificuldades associadas ao custo, configuração e conexão de periféricos estimularam, ainda mais, a criação de um novo protocolo que simplificasse todo o processo do ponto de vista do usuário final e que fosse mais rápido e eficiente. USB surgiu como um novo padrão de conexão de periféricos desenvolvido por líderes da indústria de computadores e telecomunicações 1 a partir da necessidade de se integrar de uma melhor forma estes dois ramos que cresceram separadamente e que, nos dias de hoje, convergem para um mesmo objetivo. O padrão USB utiliza a tecnologia Plug and Play, onde um dispositivo é conectado e automaticamente reconhecido. Permite ainda conexão dinâmica (hot attachment), onde um dispositivo pode ser conectado com o computador ligado, não sendo necessário reinicializar a máquina. Através de uma porta USB é possível conectar até 127 dispositivos simultaneamente em um computador, resolvendo diversos problemas de conflito de recursos (DMA s, IRQ s, jumpers, etc.). USB apresenta-se, portanto, como um protocolo que regulamenta meios físicos, software do host, firmware dos dispositivos, plugs e hubs para conexão de periféricos a computadores [8]. Implica, ainda, em aumento de performance com baixo consumo, resultando em baixo custo. Se adequam a essa nova tecnologia periféricos de baixa e média velocidades, como monitores, mouses, dispositivos de E/S de áudio, telefones, modems, teclados, impressoras, entre outros [2,3]. Essa tecnologia já está sendo implementada e comercializada amplamente, estando presente em PCs e periféricos. O projeto de um conversor de interface serial para USB permite que um dispositivo com interface serial se comunique através de uma interface USB, liberando a interface serial do micro para outras aplicações. Desta forma, não estaremos mais restritos à disponibilidade de uma porta de comunicação serial, além de podermos usufruir das vantagens do protocolo USB. A utilização de um conversor de interfaces permite ainda que mantenhamos o hardware e software do dispositivo utilizados inalterados, passando para o conversor a responsabilidade de lidar com as diferenças entre os protocolos de comunicação. O projeto foi desenvolvido baseado nos no-breaks Engetron 2, que podem ser gerenciados através da interface serial para troca de dados com o PC. Esta comunicação com os no-breaks é feita, muitas vezes, periodicamente, uma vez que a utilização da porta de comunicação não pode ficar restrita a um único periférico. Para o desenvolvimento do projeto tornou-se necessário um estudo prévio do padrão USB, de sua interação com drivers e aplicativos, além de uma análise das arquiteturas de processadores com interface USB existentes no mercado. O desenvolvimento de um dispositivo USB envolve a implementação do periférico propriamente dito além do desenvolvimento de um software que execute no PC e que se comunique com o mesmo. 1 Empresas fundadoras do USB Forum: Compaq, IBM, Intel, Microsoft, DEC, NEC e Northern Telecom. 2 Engetron é uma empresa conceituada especializada no desenvolvimento de no-breaks inteligentes (smart UPSs)
Para melhor entendimento do texto, serão introduzidos conceitos importantes do padrão USB, tornando assim mais claras as decisões de projeto. Uma breve descrição da família de microcontroladores utilizado permitirá ainda uma contextualização da estrutura exposta na especificação em relação ao hardware e firmware implementado. As estruturas de dados e decisões de projeto serão explicitadas no texto, assim como as etapas do desenvolvimento, possibilitando ao leitor uma fácil adaptação do código do conversor para outros periféricos. 2 USB Visão Geral A especificação USB [1] descreve os atributos do barramento, define o protocolo, tipos de transações, gerenciamento do barramento e programação da interface, operações estas requeridas no processo de desenho e implementação de sistemas e periféricos compatíveis ao padrão USB. No protocolo USB, o barramento toma para si a responsabilidade de instalar drivers e reconfigurar automaticamente o sistema quando da inserção ou remoção de um dispositivo. Padroniza ainda dois tipos de conectores diferentes, permitindo a transmissão bidirecional e evitando confusões nas conexões. O primeiro tipo é utilizado para conexão ao microcomputador, e é único para todo tipo de periférico. O segundo tipo é utilizado para se conectar o cabo ao periférico, em casos onde a utilização de um cabo fixo é impraticável. A conexão de dois ou mais periféricos é conseguida através da utilização de hubs, que podem ser implementados como dispositivos independentes ou embutidos em periféricos como monitores, teclados, etc. Os dispositivos compartilham a largura de banda utilizando um protocolo baseado em tokens e comandado pelo host. 2.1 Características Funcionais USB se comporta como um barramento Master/Slave onde o Master é o USB Host, que toma conhecimento da inserção e remoção dos periféricos, inicia o processo de enumeração e comanda todas as transações subsequentes nele. É também de sua responsabilidade coletar o status e as estatísticas de cada periférico. Os periféricos são Slaves do barramento, podendo ser funcionais (teclado, mouse, joystick, etc.) ou hubs, utilizados para conectar outros dispositivos. A conexão de dispositivos pode ser feita em cascata ou em estrela. Os dispositivos USB não consomem recursos do sistema. Ao contrário dos dispositivos implementados seguindo padrões mais antigos, dispositivos USB não são mapeados em memória ou em endereços de I/O, nem utilizam IRQs e DMAs. Os únicos recursos de sistema utilizados por um sistema USB são as posições de memória utilizadas pelo software de sistema e as posições de memória e/ou endereços de I/O e IRQs utilizados pelo USB Host Controller. Os dispositivos contêm um número de registradores individuais, conhecidos como endpoints, que podem ser acessados indiretamente pelos device drivers. Quando uma transação é enviada pelo barramento, todos os dispositivos (exceto os de baixa velocidade) identificarão sua presença. Cada transação inicia com um pacote que determina o tipo de transação que será executada e o endereço do endpoint. Esse endereçamento é controlado pelo software USB. A Figura 1, extraída de [4], ilustra os elementos de hardware e software envolvidos em um sistema USB. Todas as transações são iniciadas pelo USB Client software. Esses acessos são tipicamente originados do USB device driver quando este necessita comunicar com seu respectivo dispositivo. O USB driver provê a interface entre o USB device driver e o USB host controller. É o responsável pela conversão da requisição do cliente em uma ou mais transações, que serão direcionadas do ou para o dispositivo alvo.
Do ponto de vista do dispositivo, as mesmas funcionalidades estão refletidas em três estruturas: a primeira (Function) representa a interface funcional do dispositivo, que consiste de uma classe particular de dispositivos que podem ser manipulados por um mesmo driver; a segunda (Logical Device) pode ser vista como uma coleção de endpoints, sendo responsável por lidar com os mecanismos de transferência USB e as suas características; a terceira (Bus Interface), por sua vez, é responsável por receber e enviar sinais elétricos pelo cabo USB. HOST SYSTEM USB DEVICE Client Software (Client Driver) Function FUNCTION LAYER System Software (USB Drv + HC Drv) Logical Device USB DEVICE LAYER Host Controller/Hub USB Cable Bus Interface USB BUS INTERFACE LAYER Figura 1 - Fluxo de Comunicação em um sistema USB Os dispositivos USB (USB Devices) contêm um conjunto de descritores que especificam os atributos e características do dispositivo. Essa informação é necessária para que o host configure o dispositivo e localize seu respectivo driver, além de ser utilizada pelo device driver para acessar o dispositivo. Cada dispositivo possui um endpoint 0, que é reservado para configuração. É através desse endpoint que o software de sistema acessa os descritores do dispositivo. Os dispositivos USB podem ser implementados como de baixa ou alta velocidade. Os dispositivos de alta velocidade enxergam todas as transações no barramento, enviando e recebendo dados à taxa de 12Mb/s. Os dispositivos de baixa velocidade estão limitados à taxa de 1,5Mb/s e só enxergam as transações que seguem um pacote especial denominado preamble packet. As portas de baixa velocidade dos hubs ficam desabilitadas durante transações de alta velocidade, fazendo com que os dados que devem ser transmitidos à alta velocidade não transitem em cabos de baixa velocidade. O cliente USB requisita uma transferência e fornece um buffer de memória que será utilizado na mesma. O USB Host Controller Driver recebe a requisição e organiza a transferência em transações. O Host Controller gera a transação baseada no Descritor de Transferência, que foi construído pelo Host Controller Driver. Cada transação resulta na transferência de dados do buffer para o dispositivo, ou viceversa. Quando a transação é completada, o software do sistema notifica o driver cliente. Um dispositivo deve se descrever ao host software através de descritores (Descriptors), que se relacionam utilizando uma estrutura do tipo Árvore, mostrada na Figura 2. Os descritores contêm informações sobre o dispositivo, suas configurações, classes, utilização de energia e características dos endpoints. Suas funcionalidades são descritas a seguir: Device Descriptor: contém informações sobre o dispositivo, suas configurações e classes, além de fornecer as características do barramento de comunicação padrão que será utilizado para configurar o dispositivo.
Configuration Descriptors: informa características e habilidades de cada uma das configurações possíveis para um dispositivo, como por exemplo, utilização de energia e número de interfaces suportadas Interface Descriptors: contém informações relacionadas a uma interface, como por exemplo, classe e subclasse, e aos endpoints utilizados por ela. Endpoint Descriptors: contêm informações relativas ao endereço do endpoint, informando o número e direção deste, tamanho máximo do pacote de dados e frequência na qual este deve ser consultado para transferência de dados. Figura 2 Descritores de Dispositivos Outros descritores podem ser utilizados conforme as características do periférico a ser implementado, tais como String Descriptors e Class Descriptors. String descriptors contêm uma descrição textual de determinadas características do periférico, tais como nome do fabricante, nome do produto, número serial, etc. Class Descriptors identificam o tamanho e o tipo dos descritores adicionais utilizados para descrever um determinado dispositivo pertencente a uma dada classe. 2.2 Classes USB Na especificação USB, dispositivos que possuem funções similares são agrupados em classes, de forma que se possa compartilhar funcionalidades comuns, além de utilizarem device drivers comuns. Cada classe de dispositivos pode definir descritores próprios (class-specific descriptors) e a inserção desses descritores na definição da estrutura geral do dispositivo é definida pelas próprias classes. Um dispositivo pode pertencer a uma única classe ou ser composto de várias classes. Por exemplo, um telefone possui elementos de áudio, interação humana (HID) e telefonia. Isso é possível em função da estrutura que descreve um dispositivo USB e a indicação desta característica é feita através da definição de várias interfaces. Para a implementação do conversor, foram estudadas duas classes em especial: a Communication Interface Device Class e a Human Interface Device Class. O conversor se enquadrou na classe HID e, por este motivo, esta é apresentada em maior grau de detalhes logo a seguir. 2.2.1 Human Interface Device Class (HID) De forma geral, a classe HID [3] consiste de dispositivos que são utilizados por pessoas para controlar a operação de sistemas de computação. Fazem parte desta classe dispositivos como mouse, teclados, controles utilizados em jogos e simulações, entre outros dispositivos. Inclui também dispositivos que, apesar de não requererem interação humana, provêm dados em um formato similar, como leitores de códigos de barras, termômetros, etc [4].
A classe HID define uma estrutura que descreve um dispositivo HID. Além dos descritores padrões definidos pela especificação de USB, esta utiliza um descritor de classe (Class Descriptor) através do qual podem ser definidos dois outros tipos de descritores: Report Descriptor e Physical Descriptor. Report Descriptors, diferentemente dos outros descritores, não consistem apenas de tabelas de valores. O tamanho e o conteúdo de um Report Descriptor varia dependendo do número de campos de dados necessários para descrever um dispositivo. É composto por itens que provêm informações sobre o dispositivo. Physical Descriptors descrevem parte ou partes do corpo utilizadas para se ativar um determinado controle. Neste trabalho não foram utilizados Physical Descriptors. A identificação do dispositivo como um HID é feita dentro do descritor de interface, sendo então definido um conjunto de descritores para cada Interface. A estrutura geral dos descritores para um dispositivo HID pode ser vista na Figura 2. Um dispositivo HID utiliza, normalmente, dois canais de comunicação, com transferências do tipo Interrupt e de Controle (endpoint 0), que são explicadas com maior detalhe na próxima seção. 2.3 Tipos de Transferências O barramento USB é um barramento compartilhado e que pode estar sendo utilizado, simultaneamente, por vários dispositivos. O driver cliente comunica ao driver USB que deseja efetuar uma transferência do/para o seu dispositivo correspondente. Algumas dessas transferências consistem de blocos maiores de dados, as quais precisam ser quebradas em várias transações. A transferência de dados é feita em intervalos regulares denominados frames. Um frame é composto de uma ou mais transações que devem ser executadas dentro de 1ms. Cada dispositivo USB é composto por uma coleção de registradores (endpoints) que podem ser acessados pelo driver cliente quando este necessita transferir dados ao seu dispositivo correspondente. Cada endpoint suport um determinado tipo de transferência. Estes são descritos a seguir: Isochronous: taxa de transmissão de dados constante O foco desse tipo de transferência é garantir a entrega dos dados dentro de um determinado tempo, sendo dispensável a verificação de erros. Não pode ocorrer distorção no envio dos dados e o sincronismo é o foco deste tipo de transferência. Portanto, só é suportada por dispositivos de alta velocidade (12Mb/s). É unidirecional e possui um payload de dados de 1023 bytes/frame. Exemplos de dispositivos que utilizam este tipo de transferência são microfones, som de uma maneira geral. Interrupt O objetivo desse tipo de transferência é verificar se algum dispositivo necessita de transferir algum dado para o host. Esse processo ocorre de tempos em tempos, e o intervalo é denominado Polling Interval. Dessa forma, o host sonda os devices e caso seja necessário, a transferência é feita. É feita verificação de erros. Possui um payload de dados de 64 bytes/frame. Exemplo de dispositivos que utilizam este tipo de transferência são o teclado e o mouse. Bulk Esse tipo de transferência é utilizado para blocos maiores de dados, onde a taxa de transferência não é fator relevante. O que é importante nesse tipo de transferência é o grau de correção em que os dados chegarão ao destino, sendo indispensável a verificação de erros. Possui um payload de dados de 8, 16, 32
ou 64 bytes por frame. A largura de banda disponível para esse tipo de transferência varia de acordo com a disponibilidade. Um bom exemplo de um dispositivo que utiliza esse tipo de transferência são as impressoras. Controle Tipo de transferência utilizado pelo host para fazer requisições ao dispositivo. É nesse tipo de transferência que é feita a leitura dos descritores, por exemplo. Para esse tipo de transferência acontece também a verificação de erros. Transferências do tipo Isochronous e Interrupt têm uma maior prioridade em relação às outras quando distribuídas em um frame. Transferências do tipo Bulk só serão executadas quando houver disponibilidade de espaço dentro de um frame. 2.4 Requisições O protocolo USB é baseado em requisições, que são enviadas pelo host e processadas pelos dispositivos. Essas requisições possuem um limite de tempo para serem processadas pelos dispositivos que as recebem e são respondidas através do Default Control Pipe de cada dispositivo (endpoint 0). Essas requisições são feitas utilizando transferências de controle e a requisição e seus parâmetros são enviados ao dispositivo através de um pacote de setup. Existem algumas requisições que são comuns a todo tipo de dispositivo, enquanto outras são específicas de cada classe. As requisições devem ser direcionadas ao dispositivo, a uma interface dentro de um dispositivo ou ainda a um endpoint específico dentro de um dispositivo. Exemplos de requisições são Get_Configuration e Get_Descriptor, que retornam o valor da configuração e o descritor especificado respectivamente. O detalhamento das requisições será omitido pois foge do escopo deste documento. 3 Especificação do sistema Para o desenvolvimento de um dispositivo USB são necessários: Um host que suporte USB Driver que execute no host e seja capaz de se comunicar com o periférico Aplicação que execute no host e permita o acesso ao periférico. Um microcontrolador com interface USB Implementação no microcontrolador do código responsável pela comunicação USB Implementação das demais funcionalidades do periférico no microcontrolador 3.1 Requerimentos do Host A escolha do sistema operacional a ser utilizado pelo host, feita em 1999, baseou-se no suporte à tecnologia USB. O sistema operacional deveria prover toda uma infra-estrutura de drivers e suporte a características do protocolo, como por exemplo Plug and Play. Na época, os únicos sistemas operacionais que ofereciam tal suporte eram Windows95 OSR2 e Windows98, sendo que o primeiro estava ainda restrito a algumas aplicações. Por este motivo, a escolha do Windows98 como sistema operacional tornou-se evidente, uma vez que este trazia um melhor suporte à USB.
O host deve ser capaz de receber dados USB utilizando para isso device drivers e disponibilizá-los às aplicações quando solicitados. É indispensável que tenhamos executando no host um driver capaz de efetuar as transferências USB (reconhecer o dispositivo, receber e enviar dados, etc). É desejável que tenhamos um driver virtualizado que simule o funcionamento de uma porta serial. Este driver deve ter a capacidade de obter os dados do driver USB e permitir com que uma aplicação os receba como se estivesse acessando uma porta serial. A presença deste driver não é indispensável, uma vez que as aplicações podem receber dados USB diretamente. É desejável uma vez que não seriam necessárias mudanças nas aplicações. Do ponto de vista das aplicações, estas devem ser capazes de receber e enviar dados, o que pode ser feito através de uma porta serial padrão (virtualizada) ou ainda modificando as aplicações para que estas acessem uma porta USB diretamente. A Microsoft provê um driver denominado USB POS driver [12], que foi implementado com o objetivo de permitir que as aplicações enxergassem dispositivos USB como se estes estivessem conectados a uma porta serial padrão. A estrutura geral do projeto é mostrada na Figura 5. 3.2 Requerimentos do dispositivo Figura 5 Estrutura geral do sistema Foram definidos alguns requisitos a serem observados no processo de comunicação do dispositivo para a escolha do microcontrolador, como a velocidade de transmissão, a frequência em que estas ocorrem e o volume de dados a serem enviados e recebidos. Levando em consideração a velocidade de comunicação de dispositivos USB, verificou-se que um conversor de interface serial pode ser implementado como um dispositivo de baixa velocidade, com velocidade de transmissão variando de 10 a 100Kb/s. Em relação ao volume de dados transmitidos e frequência das transmissões, definiu-se a utilização de transferências do tipo Interrupt, na qual quantidades moderadas de dados devem ser transmitidas em períodos de tempo específicos. O host é responsável por verificar se o dispositivo possui dados a serem transmitidos em intervalos determinados de tempo. As transferências do tipo Interrupt podem ocorrer, não simultaneamente, nos dois sentidos, tanto para o envio de dados do PC ao conversor, quanto o contrário. Este tipo de interrupção é suportado pelo sistema operacional, que já disponibiliza drivers para a classe HID, a qual utiliza este tipo de transferência. O tamanho do pacote de dados para uma única transação, no caso de dispositivos de baixa velocidade, é de 8 bytes. Para envio de uma quantidade maior de dados, estes são subdivididos em múltiplas transações. Outra característica definida foi o número de endpoints que seriam necessários. Conforme explicado anteriormente, endpoints são estruturas capazes de armazenar múltiplos bytes sendo, tipicamente, blocos
de dados na memória ou registradores de um microcontrolador. Cada endpoint possui um endereço único e uma direção pré-definida. Um caso especial trata-se do Endpoint 0, utilizado para controle, que permite transferência de dados bidirecional e é utilizado para configuração do dispositivo e troca de mensagens com o host. Foram definidos três endpoints, sendo um para o envio de dados ao host (IN) e outro para recepção (OUT), além do Endpoint 0 (controle), que está presente em todos os periféricos. A definição do número de endpoints foi feita em função da definição de POS driver da Microsoft, que traz como exigência a disponibilidade de um número par de endpoints além do Endpoint 0. Desta forma, o conversor de interface serial para USB pode ser implementado como um dispositivo da classe HID, que possui exatamente as características mencionadas acima. 4 Descrição do Hardware Com estes requisitos levantados, a escolha do microcontrolador a ser utilizado na implementação pôde ser feita, buscando aquele que tivesse, além das características especificadas, uma melhor documentação e outras aplicações já implementadas. A família CY7C634xx/5xx da Cypress é constituída de microcontroladores de 8 bits RISC, que utilizam arquitetura Harvard, possuem um número razoável de pinos de I/O, 256 bytes de RAM e de 4K a 8Kbytes de EPROM, variando de acordo com o microcontrolador. Esta família de microcontroladores é compatível com a versão 1.0 da Especificação USB [1]. Os microcontroladores desta família suportam três tipos de Reset: Power On Reset, WatchDog Reset e USB Bus Reset (non-hardware reset). Não possuem uma interface serial em hardware, a qual foi implementada utilizando-se pinos de I/O e um software que incorporasse as funções seriais. Todas as interrupções são mascaráveis através de dois registradores Global Interrupt Enable Register e USB Endpoint Interrupt Enable Register. Cada interrupção está associada a um fragmento de código responsável por tratá-la. O conjunto de instruções foi otimizado para implementação de dispositivos USB, e todos os microcontroladores da família possuem um USB transceiver e uma USB Serial Interface Engine (SIE) (ver Figura 3 retirada de [6]). Apesar disto, estes microcontroladores podem ser utilizados para outras aplicação não-usb. A SIE permite que o microcontrolador se comunique com o host. Ela simplifica a interface entre o microcontrolador e o host, incorporando o hardware que lida com as atividade do barramento independentemente do controlador. Os microcontroladores da família CY7C634xx/5xx provêm um endereço para o dispositivo e três endpoints. O endereço é atribuído ao dispositivo e salvo em um registrador - USB Device Address Register (7 bits) - durante o processo de enumeração. O USB Controller comunica-se com o Host utilizando buffers dedicados, um por endpoint. Cada buffer é implementado como um conjunto de 8 bytes de memória SRAM e seu status e controle é feito utilizando os registradores Mode Register e Count Register. A organização da memória RAM pode ser vista na Figura 4, onde estão salientados os endereços de memória utilizados pelos endpoints.
Figura 4 Organização da memória RAM dos microcontroladores da família CY7C634xx/5xx da Cypress Figura 3 Diagrama de blocos lógicos Foi utilizado o kit de desenvolvimento (CY3651) correspondente à família CY7C634xx/5xx, o que permitiu uma maior flexibilidade em relação à quantidade de memória necessária para o código. 5 Projeto e implementação do Software O desenvolvimento do conversor pode ser dividido em algumas fases: Definição dos descritores Implementação das rotinas para tratamento de interrupções Módulo de detecção e enumeração do dispositivo Módulo de troca de dados USB Módulo de troca de dados seriais Interseção dos módulos USB e Serial para que trabalhassem conjuntamente A definição de fases não implica que estas devam ser executadas de forma independente (disjunta). 5.1 Definição dos descritores A principal estrutura de dados a ser implementada é formada por um conjunto de descritores de dispositivo que, definidos na especificação USB [1], armazenam características do periférico e permitem que o host o conheça melhor. Cada um dos descritores contém informações sobre o dispositivo como um todo ou de suas partes.
O Device Descriptor contém informações básicas sobre o dispositivo e é o primeiro a ser lido pelo host. É através dele que o host consegue acessar os demais descritores de forma a obter toda a informação necessária para a configuração do dispositivo. Os valores de seus campos foram definidos de acordo com as características do conversor [8]. Para a implementação de um novo dispositivo, estes valores devem ser reavaliados e modificados, caso necessário. A versão da especificação de dispositivos HID utilizada para a implementação foi a v1.1 [3]. As especificações da classe e subclasse do dispositivo são feitas no descritor de interface, pois o dispositivo foi implementado como um HID. O descritor do dispositivo foi definido utilizando o código de vendedor da Lakeview Research (0925h), por ter sido baseado em um exemplo fornecido juntamente com um livro desta editora [5]. Portanto, foi definido para o código do dispositivo o valor 0x1234h, por se tratar de uma aplicação exemplo. Não foi necessário obter um código próprio para a Engetron por este projeto se tratar apenas de um protótipo. Para a implementação efetiva seria necessário obter um Vendor ID através da associação ao USB Implementers Forum. Para um conversor genérico, os campos em destaque devem ser alterados de acordo com as requisições do dispositivo e da versão da especificação que estiver sendo utilizada. Device Descriptor (18 bytes) Campo Offset / tamanho Descrição (bytes) Blength 0/1 Tamanho deste descriptor (em bytes) 0x12 BDescriptorType 1/1 Tipo do descriptor (device descriptor) 0x01 BcdUSB 2/2 Versão da especificação de USB utilizada 0x0110 BDeviceClass 4/1 Classe do dispositivo 3 0x00 BDeviceSubClass 5/1 Subclasse do dispositivo 3 0x00 Valor Assumido BDeviceProtocol 6/1 Código do protocolo qualificado pela subclasse 3 0x00 BMaxPacketSize0 7/1 Tamanho máximo do pacote para o endpoint0 0x08 IdVendor 8/2 Identificação do vendedor 0x0925 (Lakeview Research) IdProduct 10/2 Identificação do dispositivo 0x3412 (exemplo) BcdDevice 12/2 Versão do dispositivo 0x01 IManufacturer 14/1 Índice para o string descriptor contendo a identificação do fabricante IProduct 15/1 Índice para o string descriptor contendo a identificação do produto 0x00 (nenhum) 4 0x00 (nenhum) 4 ISerialNumber 16/1 Índice para o string descriptor contendo o número de série 0x00 (nenhum) 4 bnumconfigurations 17/1 Número de configurações possíveis 0x01 Tabela 1 Definição do Device Descriptor Uma configuração descreve as características e capacidades do periférico e, de forma geral, uma única configuração é suficiente. Dispositivos com vários modos ou casos de uso podem ter várias configurações e, consequentemente, vários descritores de configuração. Para o conversor implementado, foi definida uma única configuração, que utiliza a energia fornecida pelo barramento (Bus Powered) até um limite máximo de 100mA. 3 A definição da classe, subclasse e protocolo para um dispositivo foi feita dentro do descritor de interface pois o dispositivo implementado possui apenas uma configuração e uma interface. 4 Podem ser definidos descritores para descrever melhor atributos como nome do fabricante, do dispositivo e número serial. Para o caso, não foi necessário.