IDs de conexão para dispositivos periféricos SPB-Connected

Antes que um driver possa enviar solicitações de E/S para um dispositivo periférico em um barramento periférico simples (SPB), o driver deve abrir uma conexão lógica com o dispositivo. Através desta ligação, o condutor pode enviar pedidos de leitura e escrita para transferir dados de e para o dispositivo. Além disso, o driver pode enviar solicitações de controle de E/S (IOCTL) para o dispositivo para executar operações específicas do SPB.

Na inicialização do sistema, o gerenciador Plug and Play (PnP) enumera dispositivos PnP e dispositivos não-PnP. Para um dispositivo periférico não-PnP que tenha uma conexão fixa com um SPB, o gerenciador PnP consulta o firmware ACPI da plataforma de hardware para obter um conjunto de parâmetros de conexão que descrevem como acessar o dispositivo. Esses parâmetros de conexão identificam o controlador SPB para o barramento ao qual o dispositivo está conectado e incluem outras informações, como o endereço do barramento e a frequência do relógio do barramento, que o controlador requer para se comunicar com o dispositivo.

O gerenciador PnP atribui um identificador — chamado ID de conexão — aos parâmetros de conexão para o dispositivo periférico conectado ao SPB. O gerenciador PnP armazena essa ID e os parâmetros de conexão juntos em um armazenamento de dados do sistema chamado hub de recursos. (O hub de recursos é um armazenamento de dados interno no qual o gerenciador PnP armazena informações de configuração sobre um dispositivo periférico conectado ao SPB.) O ID de conexão encapsula esses parâmetros para que o driver não precise fornecê-los explicitamente.

O driver de um dispositivo periférico conectado ao SPB recebe a ID de conexão do dispositivo como parte dos recursos de hardware atribuídos ao driver. Quando o driver do dispositivo periférico chama uma função do sistema para abrir uma conexão com o dispositivo, o driver fornece o ID de conexão, que a função usa para recuperar os parâmetros de conexão do dispositivo do hub de recursos.

O desenvolvedor do driver pode usar o User-Mode Driver Framework (UMDF) ou o Kernel-Mode Driver Framework (KMDF) para criar o driver para o dispositivo periférico conectado ao SPB. Um driver UMDF recebe os seus recursos (que incluem o ID de ligação) quando o sistema chama o método IPnpCallbackHardware2::OnPrepareHardware do driver. Um driver KMDF recebe os seus recursos de hardware durante um callback EvtDevicePrepareHardware.

Para habilitar um driver periférico UMDF para receber IDs de conexão em sua lista de recursos, o arquivo INF que instala o driver deve incluir a seguinte diretiva em sua seção DDInstall específica do WDF:

UmdfDirectHardwareAccess = AllowDirectHardwareAccess Para obter mais informações sobre essa diretiva, consulte Especificando diretivas WDF em arquivos INF. Para obter um exemplo de um arquivo INX (usado para criar o arquivo INF correspondente) que usa essa diretiva, consulte o exemplo de driver SpbAccelerometer .

A ID de conexão que o driver recebe como um recurso é um inteiro de 64 bits, mas o driver deve incorporar essa ID em um nome de caminho de dispositivo que possa ser usado para recuperar os parâmetros de conexão do hub de recursos. Para criar o nome do caminho do dispositivo, o driver chama a função RESOURCE_HUB_CREATE_PATH_FROM_ID , que é declarada no arquivo de cabeçalho Reshub.h.

Para abrir uma conexão lógica com o dispositivo periférico conectado ao SPB, um driver UMDF chama o método IWDFRemoteTarget::OpenFileByName e um driver KMDF chama o método WdfIoTargetOpen . Qualquer um dos métodos requer o nome do caminho do dispositivo como um parâmetro de entrada.

Para obter exemplos de código UMDF e KMDF que usam IDs de conexão para abrir conexões lógicas com dispositivos periféricos conectados ao SPB, consulte os seguintes tópicos:

Recursos de hardware para drivers periféricos SPB User-ModeRecursos de hardware para drivers periféricos SPB Kernel-Mode Os aplicativos de modo de usuário não podem abrir conexões lógicas para dispositivos periféricos conectados ao SPB e não podem enviar solicitações de E/S diretamente para esses dispositivos.

Apenas um driver pode manter uma conexão lógica aberta com um dispositivo periférico conectado ao SPB de cada vez. Uma tentativa de outro driver para abrir uma segunda conexão com o mesmo dispositivo falha.