Introdução à LUFA

Universal Serial Bus (USB) é agora uma estrutura comum e vasta para comunicação serial. A interface não só permite a comunicação serial, mas também funciona como fonte de alimentação eletrônica. Felizmente, os populares microcontroladores AVR possuem o recurso de interface USB e podem ser programados para construir dispositivos USB. A especificação USB é longa e intimidante. Pode ser uma tarefa difícil escrever um driver USB específico para um dispositivo.

Felizmente, Dean Camera tomou uma iniciativa para a comunidade AVR e construiu uma estrutura USB de código aberto para Atmel AVR8 habilitado para USB e (alguns dos) microcontroladores AVR32. A estrutura é denominada Lightweight USB Framework for AVRs (LUFA) e até agora a quarta versão da estrutura foi publicada. A estrutura foi lançada sob a licença permissiva do MIT. A biblioteca de código aberto oferece suporte a todos os Atmel USB AVRs e placas USB AVR.

A interface USB permite comunicação ponto a ponto. O dispositivo que controla a comunicação de dados USB é denominado host e o outro dispositivo que é operado é denominado escravo ou periférico. O host controla a comunicação de dados enviando solicitações às quais o periférico responde com descritores. A primeira solicitação que o host envia para um evento periférico em anexo é para enumeração. Durante a enumeração, a solicitação do host para enumeração e dispositivo periférico envia sua própria descrição, após a qual o host atribui um endereço e um número de terminal ao dispositivo periférico. Os dispositivos periféricos USB são categorizados por classes. A seguir está a lista de classes de acordo com a especificação USB –:

1. Áudio

2. Comunicações e controle do CDC

3. Dispositivo de interface humana (HID)

4. Classe de dispositivo físico

5. Imagens estáticas

6. Impressora

7. Armazenamento em massa

8. Centro

9. Dados CDC

10. Cartão inteligente

11. Segurança de conteúdo

12. Vídeo

13. Cuidados de saúde pessoais

14. Dispositivos de áudio/vídeo

15. Dispositivo outdoor

16. Dispositivo ponte USB tipo C

17. Dispositivo de diagnóstico

18. Controlador sem fio

19. Dispositivo Diversos

20. Dispositivo específico do aplicativo

21. Dispositivo específico do fornecedor

As classes USB são meios de definir dispositivos com base em sua funcionalidade, para que o formato dos dados para os diferentes tipos de dispositivos possa ser definido especificamente. Cada classe USB possui subclasses (tipos de dispositivos que se bifurcam ainda mais) e segue especificações USB específicas dentro do protocolo USB. Assim como o dispositivo de classe de áudio seguirá a especificação de classe de dispositivo de áudio dentro do protocolo USB. Confira o site do Fórum de implementadores de USB para aprender sobre as classes USB e as especificações de protocolo associadas a elas. A estrutura LUFA atualmente possui drivers escritos para as seguintes classes USB.

1. Classe de Dispositivo de Interface Humana (HID)

2. Comunicações e controle do CDC

3. Impressora

4. Armazenamento em massa

5. Subclasse de atualização de firmware de dispositivo (DFU) da classe de dispositivo específico do aplicativo

Portanto, a estrutura pode ser usada para criar periféricos USB HID, CDC, impressoras e armazenamento em massa ou para implementar driver host para as classes USB mencionadas acima. Esses são os periféricos mais comuns usados ​​com computadores pessoais. A estrutura também vem com um grande número de projetos de demonstração, que incluem projetos de demonstração de dispositivos USB HID como mouse, teclado e joystick, projetos de demonstração de dispositivos de classe CDC como entrada de áudio, saída de áudio, dispositivo Ethernet e dispositivo serial virtual, etc. os drivers específicos da classe escritos na estrutura para implementar a funcionalidade específica do dispositivo. Assim como o projeto de demonstração para teclado, usa o driver HID Class para funcionar como um teclado HID genérico. A estrutura foi escrita de acordo com a especificação USB 2.0 e possui drivers de host e de dispositivo para as classes de dispositivos USB mencionadas acima. Os drivers incluídos na estrutura suportam os modos USB de baixa velocidade, velocidade total e alta velocidade.

Na camada de aplicação do protocolo USB, a comunicação de dados é feita através de relatórios de utilização e dados (entrada ou saída). A estrutura LUFA possui APIs de alto nível, ou seja, funções que gerenciam de forma independente o envio de relatórios de dados ou relatórios de uso, bem como APIs de baixo nível que implementam o protocolo USB para uma classe USB no nível de implementação mais baixo do protocolo específico.

Agora, deve ficar claro que

1. LUFA deve ser usado para construir dispositivos periféricos USB em microcontroladores AVR.

2. LUFA pode ser usado para fabricar periféricos USB específicos para HID, CDC, armazenamento em massa, impressoras e aplicativos.

3. LUFA inclui drivers genéricos para host e periférico, portanto, drivers USB de host para as classes USB mencionadas acima também podem ser implementados usando LUFA.

4. LUFA inclui projetos de demonstração que ilustram o uso de drivers específicos de classe para construir periféricos USB específicos ou implementar driver USB no lado do host.

Vamos baixar o framework LUFA e começar a explorar os arquivos da biblioteca. Ao descompactar a biblioteca, ela contém os seguintes arquivos e pastas.

Captura de tela da pasta LUFA

Fig. 1: Captura de tela da pasta LUFA

Pasta do bootloader – Qualquer periférico USB é controlado pelo host, portanto, o microcontrolador no periférico deve conter um bootloader para inicializar-se com o host. A pasta Bootloader contém os arquivos do bootloader para os dispositivos de classe USB HID, CDC, armazenamento em massa, impressora e DFU em pastas separadas.

Captura de tela da pasta Bootloader no LUFA

Fig. 2: Captura de tela da pasta Bootloader no LUFA

Pasta BuildTests – A pasta contém os modelos de driver da placa e os módulos de teste de construção para o bootloader.

Captura de tela da pasta BuildTests no LUFA

Fig. 3: Captura de tela da pasta BuildTests no LUFA

Pasta de demonstrações – A pasta contém os projetos de demonstração que ilustram o uso de drivers específicos de classe para construir periféricos USB específicos ou implementar o driver host.

Captura de tela da pasta Demos no LUFA

Fig. 4: Captura de tela da pasta Demos no LUFA

A pasta contém três pastas -:

Dispositivo – Projetos de demonstração para dispositivos que funcionam apenas como periféricos USB.

Duplo papel – Projetos de demonstração para dispositivos que funcionam tanto como periféricos quanto como host.

Hospedar – Projetos de demonstração que ilustram a implementação de drivers de host específicos de dispositivos.

Existem projetos de demonstração usando o driver de classe USB da biblioteca (dentro da pasta ClassDriver) e também APIs de baixo nível (dentro da pasta LowLevel). O projeto de demonstração dentro das pastas ClassDriver acessa os drivers da biblioteca específicos para uma classe USB (como HID, CDC, impressora etc.) por meio de APIs disponíveis para que o código de baixo nível específico do dispositivo seja abstraído pelas funções que manipulam os próprios relatórios de dados. Os projetos demo dentro da pasta LowLevel acessam os drivers da biblioteca através de funções que tratam diretamente da comunicação USB para a classe de dispositivo específica.

Pasta LUFA – Esta pasta contém os módulos de driver reais usados ​​para implementar o protocolo USB para diferentes classes USB. A pasta contém os arquivos de modelo, arquivos de configuração e o pacote deoxygen.

Captura de tela da pasta LUFA

Fig. 5: Captura de tela da pasta LUFA

Os módulos de driver estão especificamente na pasta Drivers. A pasta contém as seguintes pastas.

Captura de tela da pasta Drivers no LUFA

Fig. 6: Captura de tela da pasta Drivers no LUFA

A pasta Board contém os drivers da placa para os microcontroladores USB AVR. A pasta Misc contém drivers diversos. A pasta Peripheral possui drivers para implementação de códigos específicos do AVR para interfaces ADC, SPI, TWI, Rs-232 e Serial SPI. Os módulos de driver USB genéricos que realmente implementam o protocolo USB na estrutura LUFA estão na pasta USB. A pasta USB contém módulos de driver específicos da classe USB (como HID, CDC, impressora, etc.) dentro da pasta Class e possui módulos USB de baixo nível na pasta Core. Possui um arquivo USB.h que é importado em todos os projetos de demonstração e deve ser importado em qualquer projeto construído com LUFA. O arquivo de cabeçalho USB.h importa ainda módulos de driver específicos de classe USB (como HID, CDC, impressora, etc.) com provisão para importar o módulo de driver final do dispositivo ou final do host.

Pasta da plataforma – A pasta da plataforma contém os drivers de plataforma de hardware específicos da arquitetura.

Como usar o LUFA

O LUFA vem com um grande número de projetos de demonstração. Os projetos de demonstração são pré-configurados para serem construídos e executados corretamente no microcontrolador AT90USB1287 AVR, montado na placa Atmel USBKEY e rodando em um clock mestre de 8MHz. Os projetos de demonstração vêm nas variedades ClassDriver e LowLevel.

Será aconselhável começar com projetos de demonstração na pasta ClassDriver, pois eles usam drivers de classe USB pré-fabricados para simplificar o uso de classes USB padrão (como HID, CDC, etc.) em aplicativos de usuário. Nestes projetos de demonstração, o módulo específico do projeto e o arquivo de cabeçalho podem ser modificados ou reescritos para implementar um novo projeto. Da mesma forma, o projeto de demonstração para teclado na pasta LUFA-Source-FolderDemosDeviceClassDriverKeyboard contém módulos Keyboard.c e Keyboard.h que podem ser modificados para criar um dispositivo de teclado HID personalizado. Os módulos nesses projetos de demonstração usam funções pertencentes a APIs de alto nível que lidam diretamente com o uso ou relatórios de dados específicos da classe de dispositivo USB.

Como no Keyboard.c, a função CALLBACK_HID_Device_CreateHIDReport trata do relatório de entrada de dados e a função CALLBACK_HID_Device_ProcessHIDReport trata do relatório de saída de dados. Os relatórios de dados e uso são recursos da camada de aplicação do protocolo USB.

Se estiver usando outro microcontrolador que não seja AT90USB1287, o Makefile na mesma pasta deve ser modificado para configurar o código para o controlador AVR específico e sua velocidade de clock. Somente controladores AVR cujos drivers de placa estejam escritos e incluídos na estrutura podem ser usados.

Para controle absoluto sobre a implementação específica da classe USB (como HID, CDC, impressora, etc.), projetos de demonstração de baixo nível podem ser modificados. Em projetos de demonstração de baixo nível, a classe USB necessária é implementada diretamente usando APIs de nível mais baixo. Para modificar esses projetos, será necessário um forte entendimento do protocolo USB e sua implementação para a classe USB específica (como HID, CDC etc.). Se o trabalho nesses projetos de demonstração exigir que o engenheiro embarcado faça um brainstorming sobre as especificações da classe USB, não será uma surpresa. Portanto, ao avançar nesses projetos de demonstração, será descoberto como realmente um dispositivo ou driver de host específico para uma classe USB é implementado.

Além disso, a estrutura é de código aberto e um engenheiro embarcado pode se esforçar para escrever um driver de placa (não disponível na estrutura no momento) ou escrever o código do driver (host e dispositivo) para classe USB adicional.

Conteúdo Relacionado

Voltar para o blog

Deixe um comentário

Os comentários precisam ser aprovados antes da publicação.