Visão geral dos drivers de dispositivo periférico SPB

Um controlador de dispositivo periférico SPB controla um dispositivo periférico que está ligado a um barramento periférico simples (SPB). Os registos de hardware deste dispositivo estão disponíveis apenas através do SPB. Para ler ou gravar no dispositivo, o driver deve enviar solicitações de E/S para o controlador SPB. Somente este controlador pode iniciar transferências de dados de e para o dispositivo através do SPB.

A partir do Windows 8, o Windows passa a fornecer suporte de driver para dispositivos periféricos em barramentos periféricos simples (SPBs). SPBs, como I²C e SPI, são amplamente utilizados para se conectar a dispositivos de sensores de baixa velocidade, como acelerômetros, dispositivos GPS e monitores de nível de bateria. Esta visão geral descreve como um driver de dispositivo periférico SPB, em cooperação com outros componentes do sistema, controla um dispositivo periférico conectado ao SPB.

Um driver de dispositivo periférico SPB pode ser criado para usar o UMDF (User-Mode Driver Framework ) ou o KMDF (Kernel-Mode Driver Framework ). Para obter mais informações sobre como desenvolver um driver UMDF, consulte Introdução ao UMDF. Para obter mais informações sobre como desenvolver um driver KMDF, consulte Introdução ao Kernel-Mode Driver Framework.

Informações de configuração do dispositivo

Os registros de hardware de um dispositivo periférico conectado ao SPB não são mapeados pela memória. O dispositivo pode ser acessado apenas através do controlador SPB, que transfere dados em série de e para o dispositivo através do SPB. Para executar operações de E/S, o driver de dispositivo periférico SPB envia solicitações de E/S para o dispositivo e o controlador SPB executa as transferências de dados necessárias para concluir essas solicitações. Para obter mais informações sobre as solicitações de E/S que podem ser enviadas para dispositivos periféricos em SPBs, consulte Usando a interface de solicitação de E/S SPB.

O diagrama a seguir mostra um exemplo de configuração de hardware na qual um SPB — neste caso, um barramento I²C — conecta dois dispositivos periféricos a um módulo System on a Chip (SoC). Os dispositivos periféricos são externos ao módulo SoC e se conectam a quatro pinos no módulo. O módulo SoC contém o processador principal (não mostrado), além de um controlador I²C e um controlador de E/S de uso geral (GPIO). O processador usa o controlador I²C para transmitir dados em série de e para os dois dispositivos periféricos. As linhas de solicitação de interrupção desses dispositivos são conectadas a dois pinos GPIO que são configurados como entradas de interrupção. Quando um dispositivo sinaliza uma solicitação de interrupção, o controlador GPIO retransmite a interrupção para o processador.

Como o controlador GPIO e o controlador I²C neste exemplo estão integrados ao módulo SoC, seus registros de hardware são mapeados na memória e podem ser acessados diretamente pelo processador. No entanto, o processador pode acessar os registros de hardware dos dois dispositivos periféricos apenas indiretamente, através do controlador I²C.

Um SPB não é um barramento Plug and Play (PnP) e, portanto, não pode ser usado para detetar e configurar automaticamente novos dispositivos conectados ao barramento. As conexões de barramento e interrupção de um dispositivo conectado ao SPB são frequentemente permanentes. Mesmo que o dispositivo possa ser desligado de uma ranhura, esta ranhura é normalmente dedicada ao dispositivo. Além disso, um SPB não fornece um caminho de hardware em banda para retransmitir solicitações de interrupção de um dispositivo periférico no barramento para o controlador de barramento. Em vez disso, o caminho de hardware para interrupções é separado do controlador de barramento.

O fornecedor da plataforma de hardware armazena as informações de configuração de um dispositivo periférico conectado ao SPB no firmware ACPI da plataforma. Durante a inicialização do sistema, o driver ACPI enumera os dispositivos no barramento para o gerenciador PnP. Para cada dispositivo enumerado, a ACPI fornece informações sobre o barramento do dispositivo e as conexões de interrupção. O gerenciador PnP armazena essas informações em um armazenamento de dados chamado hub de recursos.

Quando o dispositivo é iniciado, o gerenciador PnP fornece ao driver do dispositivo um conjunto de recursos de hardware que encapsulam as informações de configuração que o hub de recursos armazena para o dispositivo. Esses recursos incluem um ID de conexão e um número de interrupção. O ID de conexão encapsula informações de conexão do autocarro, como o controlador SPB, o endereço do autocarro e a frequência do relógio do autocarro. Antes que as solicitações de E/S possam ser enviadas para o dispositivo, o driver deve primeiro usar o ID de conexão para abrir uma conexão lógica com o dispositivo. O número de interrupção é um recurso de interrupção do Windows ao qual o driver pode conectar sua rotina de serviço de interrupção (ISR). O controlador pode ser facilmente transferido de uma plataforma de hardware para outra porque o ID de conexão e o número de interrupção são abstrações de alto nível que ocultam informações sobre o barramento físico e as conexões de interrupção específicas da plataforma.

Camadas de software e hardware

O diagrama de blocos a seguir mostra as camadas de software e hardware que conectam um dispositivo periférico em um SPB a um programa de aplicativo que usa o dispositivo. O driver de dispositivo periférico SPB neste exemplo é um driver UMDF. O dispositivo periférico (na parte inferior do diagrama) é um dispositivo de sensor (por exemplo, um acelerômetro). Como no diagrama anterior, o dispositivo periférico está ligado a um barramento I²C e sinaliza pedidos de interrupção através de um pino em um controlador GPIO.

Os três blocos mostrados em cinza são módulos fornecidos pelo sistema. A partir do Windows 7, a extensão de classe de sensor está disponível como uma extensão específica do sensor para o UMDF. A partir do Windows 8, a extensão de estrutura SPB (SpbCx) e a extensão de estrutura GPIO (GpioClx) estão disponíveis como extensões para KMDF que executam funções específicas para controladores SPB e controladores GPIO, respectivamente.

Na parte superior do diagrama anterior, o aplicativo chama os métodos na API do sensor ou na API de localização para se comunicar com o dispositivo do sensor. Por meio dessas chamadas, o aplicativo pode enviar solicitações de E/S para o dispositivo e receber notificações de eventos do dispositivo. Para obter mais informações sobre essas APIs, consulte Introdução à plataforma de sensor e localização no Windows.

Quando o aplicativo chama um método que requer comunicação com o driver de dispositivo periférico SPB, a API do sensor ou a API de localização cria uma solicitação de E/S e a envia para o driver de dispositivo periférico SPB. O módulo de extensão de classe do sensor auxilia o driver a lidar com essas solicitações de E/S. Quando o driver recebe uma nova solicitação de E/S, o driver imediatamente entrega a solicitação à extensão de classe do sensor, que enfileira a solicitação até que o driver esteja pronto para lidar com ela. Se uma solicitação de E/S do aplicativo exigir a transferência de dados de ou para o dispositivo periférico, o driver de dispositivo periférico SPB criará uma solicitação de E/S para essa transferência e enviará a solicitação para o controlador I²C. Tais solicitações são tratadas conjuntamente pela SpbCx e pelo driver do controlador I²C.

SpbCx é um componente fornecido pelo sistema que gerencia as filas de solicitações de E/S para um controlador SPB, como o controlador I²C neste exemplo. O driver do controlador I²C, que é fornecido pelo fornecedor de hardware para o controlador, gerencia todas as operações específicas de hardware no controlador I²C. Por exemplo, o driver do controlador acessa os registros de hardware mapeados na memória do controlador para iniciar transferências de dados de e para o dispositivo periférico através do barramento I²C.

O dispositivo periférico sinaliza uma solicitação de interrupção quando ocorre um evento de hardware que requer atenção do driver de dispositivo periférico SPB ou do aplicativo de modo de usuário. A linha de interrupção do dispositivo periférico está conectada a um pino GPIO configurado para receber solicitações de interrupção. Quando o dispositivo sinaliza uma interrupção para o pino GPIO, o controlador GPIO sinaliza uma interrupção para o processador. Em resposta a essa interrupção, o manipulador de armadilha de interrupções do kernel chama o Serviço de Interrupção (ISR) do GpioClx. Este ISR consulta o driver do controlador GPIO, que acessa os registos de hardware mapeados na memória do controlador GPIO para identificar o pino GPIO que causou a interrupção. Para silenciar a interrupção, o driver do controlador GPIO limpa (se a interrupção for acionada por borda) ou mascara (se for acionada por nível) o pedido de interrupção no pino GPIO. A interrupção deve ser silenciada para evitar que o processador faça a mesma interrupção novamente quando o manipulador de trap retornar. Para uma interrupção acionada por nível, o ISR no driver do dispositivo periférico SPB deve acessar os registos de hardware do dispositivo periférico para limpar a interrupção antes que o pino GPIO possa ser desbloqueado.

Antes que o manipulador de intercetação de interrupção do kernel retorne, ele agenda o ISR no driver de dispositivo periférico SPB para ser executado em IRQL = PASSIVE_LEVEL. A partir do Windows 8, um driver UMDF pode conectar seu ISR a uma interrupção que o driver recebe como um recurso abstrato de interrupção do Windows; para obter mais informações, consulte Tratamento de interrupções. Para determinar qual ISR chamar, o sistema operacional procura a interrupção virtual que está atribuída ao pino de interrupção GPIO e localiza o ISR conectado à interrupção. Esta interrupção virtual é rotulada como uma interrupção secundária no diagrama anterior. Em contraste, a interrupção de hardware do controlador GPIO é rotulada como uma interrupção primária .

Como o ISR no driver de dispositivo periférico SPB é executado em nível passivo, o ISR pode usar solicitações de E/S síncronas para acessar os registros de hardware no dispositivo periférico. O ISR pode bloquear até que essas solicitações sejam concluídas. O ISR, que é executado com uma prioridade relativamente alta, deve retornar o mais rápido possível e adiar todo o processamento em segundo plano para uma interrupção para uma rotina de trabalho que é executada em uma prioridade mais baixa.

Em resposta à interrupção secundária, o driver de dispositivo periférico SPB posta um evento na extensão de classe do sensor, que notifica o aplicativo de modo de usuário do evento por meio da API do sensor ou da API de localização.