Gestion de l’alimentation Bluetooth pour les plateformes de secours modernes

Un périphérique radio Bluetooth permet une communication RF à courte portée entre un PC et un périphérique d’entrée, un périphérique audio ou un autre périphérique utilisateur connecté au Bluetooth. Dans un PC de secours moderne, le pilote d’une radio Bluetooth doit gérer les états d’alimentation de ce périphérique conformément aux instructions présentées dans cet article.

Radio Bluetooth

Dans un système Windows, la façon dont l’état d’alimentation du périphérique radio Bluetooth est géré dépend du bus auquel la radio est connectée. Sur les plateformes matérielles qui prennent en charge le modèle d’alimentation de secours moderne, Windows prend en charge les radios Bluetooth qui sont connectées à des UART ou à un bus usb (Universal Serial Bus). (En théorie, le modèle de pilote de bus de transport Bluetooth qui a été introduit dans Windows 8 doit prendre en charge tout bus de communication sous-jacent. Actuellement, Microsoft vérifie la compatibilité de secours moderne uniquement pour les radios Bluetooth qui sont connectées à des UART ou USB, ou qui sont intégrées à un Système sur puce (SoC)).

Tout comme dans les piles de pilotes Windows classiques, la stratégie d’alimentation radio Bluetooth est gérée par un seul propriétaire de stratégie d’alimentation (PPO), en particulier BthPort (bthport.sys). BthPort fonctionne conjointement avec un pilote spécifique au transport correspondant (UART ou USB) pour diriger correctement la radio dans l’état d’alimentation souhaité. Dans le cas d’USB, cette opération s’effectue via la suspension sélective USB via le contrôleur hôte USB. Dans le cas d’UART, un pilote de bus de transport supplémentaire fourni par le fournisseur coordonne les demandes de BthPort vers le périphérique radio Bluetooth via la connexion de bus spécifique au système. Pour contrôler le matériel, le pilote utilise une combinaison de communication en bus in-band, de coordination avec le plug-in du moteur d’alimentation (PEP) et/ou de signalisation hors bande via des broches GPIO.

Les périphériques radio Bluetooth prennent généralement en charge plusieurs modes de faible consommation d’énergie, dont certains peuvent être propriétaires de l’appareil lui-même. La pile de pilotes Windows Bluetooth nécessite qu’une radio Bluetooth prend en charge les trois états d’alimentation du périphérique suivants :

• Actif (D0)
• Veille (D2)
• Désactivé (D3)

La gestion de l’alimentation des appareils pour une radio Bluetooth est censée fonctionner de manière cohérente dans tous les états d’alimentation du système. La radio Bluetooth n’entre pas dans un mode de gestion de l’alimentation spécial lorsque le système entre en veille moderne. Au lieu de cela, la radio Bluetooth est transférée vers et hors de l’état veille (D2) en fonction des délais d’inactivité gérés par BthPort. Pour prendre en charge la sortie de veille moderne sur les périphériques d’entrée HID connectés par Bluetooth, la radio reste dans l’état Veille (D2) et est armée pour la veille. Seuls les appareils Bluetooth HID couplés sont autorisés à sortir du système pendant la veille moderne. La radio Bluetooth devrait avoir une consommation d’énergie très faible (moins d’un milliwatt) dans l’état Veille (D2) si aucun appareil n’est connecté via des liaisons RF. La consommation électrique peut varier en fonction du nombre d’appareils associés, des types de ces appareils et de leurs modèles d’activité.

La radio Bluetooth doit également prendre en charge la possibilité de désactiver la radio via l’interface utilisateur de gestion de la radio. Ce contrôle d’interface utilisateur est intégré à Windows. Une fois la radio Bluetooth désactivée via cette interface utilisateur, la radio passe à l’état d’alimentation Désactivé (D3), dans lequel elle est censée consommer presque zéro watts.

Les versions précédentes de Windows, notamment Windows 8 et Windows 8 RT, exigent que le fournisseur de l’appareil Bluetooth fournisse une DLL de contrôle radio. Toutefois, à compter de Windows 8.1 et Windows RT 8.1, toutes les radios Bluetooth des plateformes de secours modernes doivent prendre en charge la spécification Bluetooth Core Version 4.0. Par conséquent, les fournisseurs ne sont plus tenus de fournir une DLL logicielle pour implémenter la fonction de contrôle on/off radio. Windows gère désormais cette fonction et ignore toute DLL de ce type, même si elle est présente.

Modes de gestion de l’alimentation

D’un point de vue logiciel, la radio Bluetooth prend en charge trois modes de gestion de l’alimentation, quel que soit le bus auquel la radio est connectée. Le pilote Bluetooth Windows possède la définition des trois modes et gère les transitions vers et hors de ces modes. Le tableau suivant décrit les trois modes d’alimentation radio Bluetooth.

La radio Bluetooth prend également en charge un mode associé dans lequel l’émetteur radio peut être mis hors tension par un logiciel en réponse à une demande de l’utilisateur. Lorsque la radio est activée pour l’appareil Bluetooth, cet appareil est à l’état Actif (D0) ou Veille (D2). Lorsque la radio de l’appareil Bluetooth est désactivée par l’utilisateur, Windows arrête l’activité Bluetooth en supprimant par surprise les pilotes de protocole et leurs enfants, puis en faisant passer la pile du périphérique radio à l’état Désactivé (D3).

Mécanismes de gestion de l’alimentation logicielle

La gestion de l’alimentation d’un périphérique radio Bluetooth est pilotée par les transitions d’état Dx de l’appareil qui sont initiées par BthPort en tant que propriétaire de la stratégie d’alimentation (PPO). Le PPO détermine quand l’appareil passe entre les états Actif (D0), Veille (D2) et Désactivé (D3).

Lorsque la radio n’a pas d’appareils associés, Windows transfère l’appareil vers D2 et le conserve dans cet état jusqu’à ce que l’utilisateur commence le processus de jumelage. Lorsque la radio est associée à un ou plusieurs appareils, le pilote Bluetooth Windows utilise un délai d’inactivité pour décider quand faire passer la radio Bluetooth de D0 à D2. Cet algorithme utilise le modèle d’utilisation de Bluetooth par le système d’exploitation et les applications pour déterminer quand faire passer la radio à l’état D2. Par exemple, la radio passe à D2 plusieurs secondes après la dernière pression sur un clavier Bluetooth s’il n’y a aucune autre activité sur la radio Bluetooth.

Le pilote Windows Bluetooth effectue la transition de l’appareil vers D0 en réponse à l’une des opérations suivantes :

• L’utilisateur commence un processus de jumelage.
• Une application demande l’utilisation de la fonctionnalité Bluetooth.
• La radio Bluetooth a généré une demande de sortie de veille basée sur l’entrée d’un appareil associé.

Contrairement à d’autres appareils, la radio Bluetooth suit le même modèle de gestion de l’alimentation pendant le mode de secours moderne (affichage système désactivé) qu’il fait lorsque le système est normalement opérationnel et que l’affichage est allumé. Cela est dû au fait que la radio Bluetooth est censée être disponible pour sortir le SoC lorsque l’entrée est reçue d’un appareil associé à tout moment pendant la veille moderne. Par exemple, si un utilisateur a associé un clavier Bluetooth à un ordinateur Windows, appuyez sur n’importe quelle touche du clavier pour sortir l’ordinateur de la veille moderne et activer l’affichage.

Si aucun appareil n’est associé à la radio, la radio est censée être configurée pour consommer moins d’un milliwatt lorsqu’elle est en veille (D2).

Lorsque la radio Bluetooth est à l’état Désactivé (D3), elle est censée consommer presque zéro watts.

Notes sur l’implémentation du pilote

Si la radio Bluetooth est connectée via un UART ou intégrée au soC lui-même, le fournisseur de l’appareil Bluetooth doit implémenter et fournir un pilote de bus de transport. Le pilote de bus de transport est responsable des éléments suivants :

• Traduction des demandes de paquets Bluetooth HCI du pilote Bluetooth Windows (Bthmini.sys) en commandes envoyées via le bus de transport à la radio Bluetooth.
• Transition de l’appareil radio Bluetooth vers différents modes de gestion de l’alimentation mappés aux états d’alimentation Actif (D0), Veille (D2) et Désactivé (D3). Le pilote implémente également des routines qui gèrent les événements de gestion de l’alimentation.
• Configuration de la radio Bluetooth pour réveiller le SoC lorsqu’un appareil génère une entrée, et modification de l’état de toutes les lignes GPIO facultatives du SoC vers la radio Bluetooth qui sont utilisées pour la gestion de l’alimentation.
• Énumération et gestion de l’alimentation d’autres appareils (tels qu’un émetteur FM ou un appareil GPS) qui partagent le même bus que la radio Bluetooth. Si d’autres appareils sont physiquement connectés au bus partagé, mais ne sont pas exposés au système d’exploitation, le pilote du bus de transport doit mettre complètement hors tension ces appareils.

Pour plus d’informations sur l’implémentation d’un pilote de bus de transport, consultez Les instructions relatives à la gestion du contrôle d’alimentation Bluetooth. Les pilotes de bus de transport doivent être écrits à l’aide de Windows Driver Framework (WDF). Un exemple de pilote est disponible dans Pilote de bus série HCI Bluetooth.

Pour activer la gestion de l’alimentation radio Bluetooth, le pilote de bus de transport doit effectuer les actions suivantes :

• Activez la prise en charge de la gestion de l’alimentation inactive au moment de l’exécution et exposez la prise en charge des états d’alimentation des appareils Actifs (D0), Veille (D2) et Désactivé (D3).
• Indiquez au pilote Bluetooth Windows que le périphérique radio Bluetooth est capable de signaler les événements de veille à partir de l’état D2.
• Prise en charge de l’armage de l’appareil radio Bluetooth pour réveiller le SoC et désarmer le signal de veille de l’appareil Bluetooth au SoC. Cette prise en charge peut nécessiter la gestion d’une ou plusieurs interruptions GPIO et l’exécution de méthodes de veille dans WDF.
• Modifiez l’état de toutes les lignes GPIO facultatives du SoC vers le périphérique radio Bluetooth lorsque l’appareil passe entre les états Actif (D0), Veille (D2) et Désactivé (D3).

Si la radio Bluetooth est intégrée au SoC lui-même, le pilote de bus de transport peut s’inscrire auprès de l’infrastructure de gestion de l’alimentation Windows pour communiquer l’alimentation radio Bluetooth status à un plug-in power-engine (PEP) spécifique au SoC. Pour ce faire, définissez le membre IdleTimeoutType de la structure WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS sur la valeur SystemManagedIdleTimeout.

Si la radio Bluetooth est connectée via USB, la pile de pilotes Bluetooth USB intégrée doit être utilisée. La pile gère toutes les opérations de gestion de l’alimentation.

Gestion des radios

L’état de l’émetteur radio Bluetooth est lié directement à l’état d’alimentation de l’appareil. L’émetteur radio est censé être activé lorsque la radio est à l’état d’alimentation Actif (D0) ou Veille (D2). L’émetteur radio doit être désactivé lorsque la radio passe à l’état Désactivé (D3).

Lorsque l’utilisateur désactive la radio Bluetooth, Windows met fin à l’activité Bluetooth en annulant les opérations d’E/S en attente et en déchargeant les pilotes de protocole et leurs enfants. La pile de pilotes Bluetooth Windows envoie ensuite la commande HCI_Reset au contrôleur pour réinitialiser l’état par défaut de la radio. Dans l’état par défaut, le contrôleur ne doit pas être capable de transmettre ou de recevoir des signaux radio. Enfin, le contrôleur passe à l’état Désactivé (D3).

En réponse à la transition vers Désactivé (D3), le pilote de bus de transport doit mettre hors tension l’appareil Bluetooth à son état d’alimentation le plus bas à l’aide de méthodes spécifiques à l’appareil. Une implémentation classique consiste à changer l’état d’une ligne GPIO du SoC à la radio Bluetooth pour désactiver l’alimentation du module Bluetooth. Une autre implémentation consiste à exiger que le microprogramme ACPI supprime l’alimentation du module Bluetooth à l’aide de méthodes de contrôle _PS0 et _PS3.

Lorsque l’utilisateur active la radio Bluetooth, Windows passe la radio à l’état Actif (D0), réinitialise la radio, puis énumère à nouveau les pilotes de protocole enfant. Lorsque la radio passe à Active (D0), toutes les lignes GPIO requises doivent être désactivées dans le cadre de la séquence D0 normale pour la radio Bluetooth. Si le microprogramme ACPI a été utilisé pour mettre hors tension la radio, il doit restaurer l’alimentation à l’aide de la méthode de contrôle _PS0.

Dans le cadre de cette séquence normale, le pilote de bus de transport doit marquer l’appareil comme un appareil connecté en interne en définissant le ContainerId de la radio Bluetooth sur une valeur GUID spécifique, {0000000-0000-000-ffffffffffff}. Cela permet aux éléments d’interface utilisateur de la radio Windows de détecter que la radio Bluetooth exposée par le pilote de bus de transport est interne à l’ordinateur et non une radio attachée en externe pour laquelle le contrôle radio n’est pas approprié.

Configurations d'alimentation matérielles prises en charge

La configuration matérielle de gestion de l’alimentation pour une radio Bluetooth dépend du bus de communication. En règle générale, toutes les radios Bluetooth sont censées avoir les fonctionnalités de gestion de l’alimentation matérielle suivantes en commun :

• Prise en charge de l’état Désactivé (D3) pour désactiver la radio en réponse à une demande de l’utilisateur. L’arrêt de la radio place la radio Bluetooth dans un état de faible puissance qui est proche de zéro watts.
• Mécanisme permettant d’entrer un état de veille à faible consommation (D2) dans lequel les connexions sont persistantes vers les appareils associés, mais il n’y a pas de transferts actifs.
• Mécanisme permettant de générer une interruption de veille lorsqu’un appareil associé a des données pour le SoC et que le SoC est dans un état de faible consommation dans lequel le bus auquel l’appareil radio Bluetooth est attaché n’est actuellement pas actif.

Chacun des bus pris en charge (USB, UART et intégration au SoC) pour le périphérique radio Bluetooth prend en charge les trois fonctionnalités de base de gestion de l’alimentation matérielle dans la liste précédente. En outre, chaque radio Bluetooth peut avoir des fonctionnalités de gestion de l’alimentation spécifiques au fournisseur ou à l’appareil, mais celles-ci ne relèvent pas de la portée de cette rubrique.

Les fournisseurs de radio Bluetooth sont encouragés à implémenter des fonctionnalités de gestion de l’alimentation à valeur ajoutée d’une manière autonome dans le matériel et ne nécessitant pas de logiciel pilote fourni par le fournisseur supplémentaire sur le système Windows. Les fournisseurs de radio Bluetooth sont également encouragés à implémenter leurs pilotes et leur logiciel de gestion de l’alimentation de manière à extraire les différences propres à la plateforme dans le microprogramme ACPI système plutôt que dans le code du pilote ou le fichier .inf du pilote. Cette approche permet de réutiliser un package de pilotes pour l’appareil Bluetooth dans des plateformes supplémentaires sans nécessiter de mise à jour de la source du pilote, du fichier binaire ou du package d’installation signé.

Radio Bluetooth connectée via un UART en dehors du SoC

Si la radio Bluetooth est connectée via un UART et est physiquement située en dehors du SoC, le fournisseur d’radio Bluetooth doit fournir un pilote de bus de transport qui expose la radio Bluetooth et toute autre fonction d’appareil (par exemple, une radio FM) qui partagent le même chemin de communication via l’UART. Le pilote de bus est également responsable de la gestion des ressources GPIO qui contrôlent la consommation d’énergie et la capacité de veille de la radio Bluetooth.

Contrairement à d’autres classes d’appareils, les lignes GPIO qui contrôlent l’alimentation et l’éveil Bluetooth sont gérées directement par le pilote de bus de transport au lieu d’être abstraites par les méthodes de contrôle ACPI. Ce schéma de contrôle est le résultat de la conception du pilote de bus multifonction qui énumère la radio Bluetooth et d’autres fonctions qui partagent le même port UART. Dans cette conception, le pilote ACPI Windows, Acpi.sys, n’est pas chargé dans les piles de pilotes pour Bluetooth et la radio FM, ce qui rend impossible l’utilisation de l’exécution de la méthode de contrôle ACPI comme moyen de répondre à une transition d’état Dx d’appareil.

Lorsque la radio Bluetooth est connectée au port UART sur le SoC, l’intégrateur de système doit utiliser une broche sur le contrôleur GPIO du SoC pour contrôler l’alimentation de la radio. Dans le microprogramme ACPI, cette broche doit être affectée en tant que ressource d’E/S GPIO à l’objet d’appareil qui représente le périphérique racine du pilote de bus de transport. La broche GPIO peut être connectée directement à la radio Bluetooth si la radio prend en charge l’arrêt de l’appareil avec la mise sous tension interne.

Si la radio Bluetooth prend en charge la prise en charge de l’alimentation, la source d’alimentation de la radio Bluetooth peut être connectée à n’importe quelle barre d’alimentation du système.

Si la radio ne prend pas en charge l’alimentation interne contrôlée par une broche GPIO, l’intégrateur système doit placer la radio Bluetooth sur une barre d’alimentation qui peut être commutée. La broche GPIO du SoC est ensuite connectée au matériel de basculement d’alimentation. Dans cette conception, les méthodes de contrôle ACPI ne peuvent pas être utilisées pour suivre le nombre de références ou pour agréger l’état d’alimentation de plusieurs appareils partageant la même barre d’alimentation, de sorte que la radio Bluetooth doit être isolée sur sa propre barre d’alimentation commutable.

L’intégrateur système doit utiliser une broche supplémentaire sur le contrôleur GPIO du SoC pour recevoir les interruptions de veille de la radio Bluetooth. Les interruptions sur cette broche doivent être capables de réveiller le SoC à partir de son état d’alimentation le plus faible. Dans certaines conceptions de SoC, une telle broche est appelée broche GPIO toujours activée, car le contrôleur GPIO peut détecter des interruptions sur cette broche à tout moment, quel que soit l’état d’alimentation du SoC. La fonctionnalité always-on peut être limitée dans le matériel à un ensemble spécifique de broches GPIO sur le SoC ou peut être configurable dans le microprogramme. Il est essentiel que l’intégrateur de système examine cette conception avec le fournisseur de SoC pour s’assurer que l’interruption de veille de la radio Bluetooth entraîne la sortie du SoC de son état d’inactivité le plus profond. (En tout temps, pendant la veille moderne, le système est en S0. Les systèmes de secours modernes ne prennent pas en charge S3.)

Lorsque toutes les fonctions énumérées par le pilote de bus de transport ont été hors tension et que le périphérique de bus de transport énuméré par ACPI entre dans D3, la broche GPIO toujours allumée peut être hors tension. Cela se produit lorsque les radios de toutes les fonctions d’appareil énumérées par le pilote de bus de transport ont été désactivées par l’utilisateur.

Radio Bluetooth sur USB

Si la radio Bluetooth est attachée au SoC ou au silicium de cœur via le bus USB, la radio doit être alimentée à partir d’une source autre que le bus USB. Dans la spécification USB, une telle radio est décrite comme auto-alimentée, et cette fonctionnalité doit être signalée dans les descripteurs USB de l’appareil Bluetooth.

De même, le matériel de périphérique USB doit annoncer la prise en charge de la veille à distance, qui est la possibilité pour la radio Bluetooth de générer une signalisation de reprise USB in-band pour réveiller le contrôleur hôte USB. La fonctionnalité de veille à distance doit également être annoncée dans les descripteurs USB de la radio Bluetooth.

La radio Bluetooth doit prendre en charge les fonctionnalités auto-alimentées et de veille à distance afin qu’elle puisse entrer dans l’état Veille (D2) et activer la suspension sélective.

Si la radio Bluetooth est à l’état Veille (D2) et que les données d’un appareil associé sont disponibles pour l’hôte, la radio Bluetooth doit générer la signalisation de reprise de veille à distance pour réveiller l’hôte. Un signal de reprise hors bande utilisant une ligne GPIO vers le silicium du cœur n’est pas pris en charge. La radio Bluetooth, y compris ses circuits de connexion USB, devrait consommer moins d’un milliwatt d’alimentation à l’état Veille (D2).

Problèmes de veille

La radio Bluetooth est censée être en mesure de générer une interruption de veille lorsqu’elle est en veille (D2). L’interruption de veille doit provoquer la mise sous tension du SoC, même si le SoC est dans son état d’alimentation le plus faible. Le tableau suivant récapitule les deux mécanismes de signalisation de veille Bluetooth.

Test et validation

Les fournisseurs d’appareils Bluetooth sont encouragés à tester et à valider le fonctionnement de gestion de l’alimentation de l’appareil radio Bluetooth.

Les transitions entre les états Actif (D0), Veille (D2) et Désactivé (D3) peuvent facilement être observées à l’aide de l’outil Xperf, comme décrit dans d’autres sections.

Les activités des pilotes Bluetooth peuvent être surveillées à l’aide d’une instrumentation ETW intégrée à Windows. Le développeur de pilotes est encouragé à utiliser l’instrumentation EtW (Event Tracing for Windows) pour exposer les changements importants d’état de gestion de l’alimentation dans le pilote et les observer à l’aide de l’outil Xperf ou de l’observateur d'événements Windows intégré.

Si la radio Bluetooth est connectée via USB, l’utilitaire de Powercfg.exe intégré peut être utilisé avec l’option de ligne de commande /energy pour vérifier que la radio entre dans l’état Veille (D2) et qu’elle est suspendue. Pour utiliser l’utilitaire Powercfg.exe :

• Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur.
• Accédez au répertoire racine du lecteur (cd \).
• Entrez la commande powercfg.exe /energy.
• Attendez les 60 secondes par défaut.
• L’utilitaire Powercfg.exe génère le nombre d’erreurs et de conditions d’avertissement sur le système, comme illustré dans la capture d’écran suivante.
• Une fois que l’outil a écrit les informations récapitulatives dans la fenêtre d’invite de commandes, il génère un fichier HTML nommé Energy-report.html. Ouvrez le fichier et recherchez les conditions d’erreur ou d’avertissement à partir du périphérique Usb Bluetooth. L’exemple de résumé suivant indique qu’un appareil Usb Bluetooth n’a pas entré l’état Veille (D2) lorsqu’il est inactif.

Les fournisseurs d’appareils Bluetooth qui fournissent d’autres pilotes et applications de profil Bluetooth tiers doivent vérifier que leur logiciel prend en charge la suppression surprise et permet à l’infrastructure de gestion radio de désactiver correctement la radio Bluetooth en temps opportun. Ces scénarios doivent être validés pendant l’utilisation du profil ou de l’application. Par exemple, pour les pilotes audio, il doit y avoir un streaming audio Bluetooth pendant que la radio est désactivée. Ensuite, la radio doit être réactivée et le flux audio redémarré pour vérifier qu’il fonctionne toujours.

Liste de contrôle de gestion de l’alimentation Bluetooth

Les intégrateurs système, les fournisseurs de radio Bluetooth et les fournisseurs soC doivent utiliser la liste de contrôle suivante pour s’assurer que leur conception de gestion de l’alimentation système est compatible avec Windows 8 et Windows 8.1 :

• Déterminez le bus de communication pour la radio Bluetooth dans la conception du système. La radio Bluetooth est connectée via UART ou connectée via USB.

• Vérifiez que la radio Bluetooth prend en charge un mode veille à faible consommation d’énergie qui consomme moins d’un milliwatt lorsqu’aucun appareil n’est associé.

  La consommation électrique de la radio Bluetooth en mode veille peut varier en fonction du nombre d’appareils associés actuellement présents, mais ne doit généralement pas dépasser cinq milliwatts à tout moment.

• Vérifiez que la radio Bluetooth prend en charge les fonctionnalités de base requises de gestion de l’alimentation suivantes :

  • Prise en charge de l’état Désactivé (D3) pour permettre à l’utilisateur de désactiver la radio.
  • Mécanisme permettant d’entrer dans un état de veille à faible consommation (D2) où les connexions sont conservées aux appareils associés, mais il n’y a aucun transfert actif.
  • Mécanisme permettant de réveiller le SoC lorsqu’un appareil associé génère des données et que le SoC est dans un état de faible consommation.

• Si la radio Bluetooth est connectée via un bus non USB (UART ou intégré au SoC), le fournisseur de radio Bluetooth doit développer un pilote de bus de transport. Le pilote de bus de transport doit effectuer les opérations suivantes :

  • Prendre en charge les fonctionnalités et les exigences détaillées dans Les instructions de gestion du contrôle d’alimentation bluetooth du pilote de bus de transport.
  • Traduisez les requêtes Bluetooth du pilote Bluetooth Windows (Bthmini.sys) en commandes vers la radio Bluetooth via le bus UART ou un bus SoC interne propriétaire.
  • Effectuez la transition de l’appareil radio Bluetooth vers différents modes de gestion de l’alimentation mappés aux états Actif (D0), Veille (D2) et Désactivé (D3). Le pilote doit également implémenter des routines qui gèrent les IRP de gestion de l’alimentation des périphériques (Dx).
  • Configurez la radio Bluetooth pour réveiller le SoC lorsqu’un appareil génère une entrée et modifiez l’état de toutes les lignes GPIO facultatives qui connectent le SoC à la radio Bluetooth à des fins de gestion de l’alimentation.
  • Énumérez d’autres appareils (par exemple, un émetteur FM) qui peuvent être partagés sur la radio Bluetooth.
  • Utilisez Windows Driver Framework (WDF) pour le développement de pilotes.
  • Être implémenté en fonction du pilote de bus HCI série Bluetooth.

• Si la radio Bluetooth est connectée via USB, le fournisseur de radio Bluetooth doit :

  • Activez la prise en charge de la suspension sélective dans la radio.
  • Vérifiez que la radio dispose des fonctionnalités de veille à distance et d’auto-alimentation définies dans le descripteur de périphérique USB.
  • Vérifiez que la radio (y compris les composants USB) consomme moins d’un milliwatt.

• Quel que soit le bus de connexion, la radio Bluetooth doit effectuer les opérations suivantes pour une radio connectée en interne :

  • Assurez-vous que tous les composants RF sont désactivés en réponse à une commande HCI_Reset envoyée à la radio en préparation de la mise sous tension de la radio. La radio ne doit pas être capable de transmettre ou de recevoir des signaux radio.
  • Entrez son mode d’alimentation le plus faible lorsque l’état est désactivé (D3).

• Si la radio Bluetooth est connectée via UART, l’intégrateur système doit connecter le signal de sortie de veille de la radio Bluetooth à une broche GPIO sur le SoC qui peut sortir le SoC de l’état d’alimentation le plus faible.

  • Le SoC peut exiger que les signaux de veille soient acheminés vers un ensemble limité de broches GPIO préconfigurées pour être toujours activées.
  • Ou bien, le SoC peut prendre en charge la configuration d’une broche GPIO sur une broche always-on dans le microprogramme système pendant le démarrage.

• L’intégrateur système doit tester et vérifier que la radio Bluetooth passe à l’état Veille (D2) quand aucun appareil n’est associé.

• L’intégrateur système doit tester et vérifier que la radio Bluetooth passe à l’état Veille (D2) lorsque tous les appareils associés n’ont aucun transfert actif.

• L’intégrateur système doit tester et vérifier que la radio Bluetooth peut sortir le SoC de son état d’alimentation le plus faible lorsque la radio est en veille (D2).

• L’intégrateur système doit tester et vérifier que la radio Bluetooth ne génère pas de signaux de veille faux pendant l’état Veille (D2).

• L’intégrateur système doit tester et vérifier que les logiciels tiers de module complémentaire, tels que les pilotes et les applications de profil, fonctionnent correctement avec la gestion radio Bluetooth. La radio doit être désactivée et activée pendant que le logiciel tiers est activement utilisé (par exemple, lecture audio ou transfert d’un fichier).