Voici les questions, scénarios et problèmes courants qu’un développeur de pilotes peut rencontrer lors du développement d’un pilote de bus pour prendre en charge les fonctionnalités Bluetooth.
Mon pilote de bus série a rencontré une erreur. Qu’est-ce que cela signifie ?
Code 10-49 : explication des codes d’erreur générés par Gestionnaire de périphériques.
Code 51 : lorsqu’un pilote de bus série a des pilotes de contrôleur dépendants (comme défini dans le tableau ACPI), le système charge le pilote de bus série, mais il ne démarre pas tant que tous ses pilotes dépendants n’ont pas démarré correctement. Lorsque le pilote du contrôleur est absent ou n’est pas chargé correctement, une erreur de code 51 est déclenchée.
Code 52 = Pilote non signé.
La signature du pilote est décrite plus en détail dans ces rubriques :
Pourquoi mon pilote de bus série n’obtient-il pas d’IOCTL de la pile principale Bluetooth ?
Un pilote de bus série peut avoir activé les fonctionnalités inactives, mais n’a pas implémenté les mécanismes de gestion du contrôle d’alimentation décrits dans la section et ses sous-rubriques. Dans ce cas, un appareil Bluetooth HID (souris ou clavier) ne pourra pas sortir la pile (de D2 à D0). Il est recommandé de désactiver cette fonctionnalité inactive jusqu’à ce que les fonctions Bluetooth de base et les mécanismes de gestion du contrôle de l’alimentation aient été implémentés.
Existe-t-il des tests de logo Windows Bluetooth ?
Windows HCK (Hardware Certification Kit) contient un ensemble de tests spécifiques à Bluetooth qui doivent être passés pour recevoir la certification. Les développeurs de pilotes Bluetooth doivent exécuter ces tests pendant le développement pour s’assurer que leur pilote les réussit afin de recevoir la certification et de bénéficier d’un support approprié.
Les paramètres UART doivent-ils être conservés et restaurés entre les différentes transitions d’état d’alimentation ?
Étant donné que le pilote de transport Bluetooth connaît et contrôle les paramètres du contrôleur UART distant (y compris ses paramètres après la mise sous tension), le pilote de transport Bluetooth doit réinitialiser les contrôleurs UART distants et locaux avant d’entrer dans un état dans lequel l’alimentation peut être perdue. Ainsi, lorsque l’alimentation est restaurée, les paramètres des contrôleurs UART distant (côté Bluetooth) et UART local (côté hôte) peuvent être synchronisés. Le pilote UART contrôle uniquement le contrôleur UART local et est responsable de la restauration de ses paramètres avant la mise hors tension. Le pilote de transport Bluetooth peut également interroger le pilote UART sur ses paramètres de mise sous tension (étant donné que le pilote UART les a définis initialement à l’aide de la table ACPI), mettre en cache et les définir lors de l’entrée d’un état Dx.
Que se passe-t-il si le pilote de bus reçoit une notification de sortie de veille alors que la pile est en train d’entrer dans D2 ?
Dans ce cas, le pilote de bus doit effectuer la transition D2, puis passer au mécanisme de veille. Le pilote de bus série est censé effectuer cette synchronisation (par exemple, il peut mettre en file d’attente la demande de sortie de veille et démarrer le processus de sortie de veille uniquement une fois la transition D2 terminée).
Comment un pilote de bus doit-il identifier sa ressource ACPI de plusieurs occurrences, telles que plusieurs GPIOs ?
Il n’existe aucun moyen d’étiqueter une ressource, GPIO ou autre. C’est pourquoi l’ordre des ressources est important. Le pilote de périphérique doit établir une convention (par exemple, la première ressource GPIO qui apparaît dans la liste est pour BT_WAKE et la deuxième pour HOST_WAKE).