Gestion de l’alimentation du récepteur AUTHENTIFICATION pour les plateformes de secours modernes

Article
06/19/2023

Cette rubrique traite de la gestion de l’alimentation du système VIG (Global Navigation Satellite System) pour les plateformes modernes compatibles avec le mode de secours.

Un PC Windows qui implémente le modèle d’alimentation de secours moderne peut également contenir un appareil VIG (Global Navigation Satellite System). Un appareil VIG permet à l’utilisateur d’obtenir des informations de positionnement de haute précision à partir d’un système de navigation par satellite, tel que le système GPS (Global Positioning Systems) ou le système GLONASS (Global Positioning Navigation Satellite System). Une fois que la plateforme matérielle entre en veille moderne, l’appareil WU doit passer à un mode de fonctionnement à faible consommation d’énergie dans lequel il ne consomme pas plus d'1 mW d’alimentation. L’appareil RECOM doit ensuite rester dans ce mode jusqu’à ce que la plateforme quitte la veille moderne.

Les appareils SYNC qui prennent en charge le GPS et le système gloNASS (Global Orbiting Navigation Satellite System) sont disponibles depuis un certain temps, mais les nouveaux appareilsnaires prennent en charge les systèmes de navigation par satellite tels que Le système de navigation par satellite BeiDou (BDS) et Galileo.

Une plateforme de secours moderne est généralement construite autour d’un circuit intégré Système sur puce (SoC). Windows prend en charge les options suivantes pour l’ajout d’un appareil PAA à une telle plateforme :

Incorporez un module haut débit mobile (MBB) qui contient un appareil CONTI intégré. Cette méthode est courante dans les téléphones cellulaires.
Sélectionnez un SoC qui contient un appareil POC intégré.
Utilisez un bus à faible consommation, tel que I2C, SPI ou UART, pour connecter un appareil BOUT AUTONOME au SoC.

Si possible, l’intégrateur système doit sélectionner un appareil WU qui implémente un mode veille à faible consommation d’énergie dans lequel l’appareil ne consomme pas plus d'1 mW d’alimentation. Le fournisseur de l’appareil JDBC doit fournir un pilote de capteur d’emplacement qui traduit les données d’emplacement de l’appareil BOUT en forme requise par les applications clientes. Ces applications se connectent à l’appareil SYNC via l’API d’emplacement Windows. Le pilote de capteur d’emplacement pour l’appareil 8000 assure le suivi des informations suivantes :

Nombre de clients actuellement connectés à l’appareil ACCESS via l’API d’emplacement.
État du commutateur d’activation/désactivation de la radio pour l’appareil HERTZ. L’utilisateur contrôle ce commutateur via l’application Paramètres Windows. Pour plus d’informations, consultez Intégration de la gestion des radios.

Le pilote du capteur d’emplacement utilise ces informations pour déterminer quand le périphérique est inactif afin qu’il puisse être placé en mode basse consommation. Un appareil ACCESS est activement utilisé uniquement si un ou plusieurs clients sont connectés à l’appareil. Sinon, l’appareil est inactif.

Pour prolonger l’autonomie de la batterie du système, l’accès à l’appareil ACCUMULATE est limité pendant la veille moderne. Les applications d’écran de verrouillage peuvent accéder aux informations de géofencing et de position pendant la veille moderne. Toutefois, les applications sans écran de verrouillage peuvent utiliser l’API Emplacement pour obtenir des données d’emplacement à partir de l’appareil SYNC uniquement lorsque l’affichage est activé et que la plateforme interagit avec l’utilisateur. Peu de temps après que l’affichage s’est éteint et que la plateforme entre en veille moderne, toutes les applications sans écran de verrouillage qui ont des connexions à l’appareil sont automatiquement déconnectées par Windows, et les applications sont suspendues.

Modes de gestion de l’alimentation

Le récepteur GPS est censé avoir 4 modes de gestion de l’alimentation, comme décrit ci-dessous.

Modes d’alimentation du récepteur ADMINISTRATEUR

Mode d’alimentation de l’appareil	Description	État d’alimentation de l’appareil (Dx)	État radio (tel qu’indiqué à l’utilisateur)	Nombre de clients connectés	Consommation électrique moyenne (mW)	Mécanisme de transition
Actif (acquisition)	Le récepteur SAT acquiert un correctif satellite.	D0	Activé	> = 1	~200 mW	N/A
Actif (suivi 1 Hz)	Le récepteur SAT a acquis un correctif satellite et fournit régulièrement des données à une ou plusieurs applications.	D0	Activé	> = 1	~100 mW (spécifique à l’appareil)	N/A
Veille	Le récepteur ACCESS n’a pas de clients connectés Le matériel du récepteur ACCESS dispose toujours de l’alimentation appliquée pour conserver le contexte sur l’appareil et réduire le temps de latence de reprise en mode Actif.	D3(D3hot)	Désactivé ou activé	0	<1 mW (spécifique à l’appareil)	Initié par un logiciel. Il s’agit de l’état de suspension sélective pour les radios RÉINITIALISATION attachées directement au bus USB (Universal Serial Bus) ou à un périphérique composite USB.
Mise sous tension	Le récepteur ACCESS n’a pas de clients connectés, la radio est hors tension et toute l’alimentation du récepteur GATOR a été supprimée par une entité externe.	D3(D3cold)	Désactivé ou activé	0	0 mW	Lancé par le logiciel et nécessite une coordination matérielle pour supprimer l’alimentation.

Le pilote logiciel pour le récepteur HERTZ doit également gérer la gestion radio, comme décrit ci-dessous.

Conditions requises pour l’implémentation de la plateforme

Une plateforme de secours moderne offre plusieurs options d’intégration physique d’un récepteur BOUTA. Le récepteur GPS peut faire partie d’un appareil autonome qui est connecté au SoC par un bus de communication basse consommation. Le récepteur HERTZ peut également être intégré à une radio haut débit mobile (MBB), car les récepteurs HERTZ sont courants dans les téléphones cellulaires. Enfin, le récepteur GPS peut être intégré au soC lui-même.

Ces multiples options posent un défi à l’intégrateur de système lorsqu’il détermine l’implémentation à sélectionner pour une plateforme qui nécessite des fonctionnalités PAA. Pour les plateformes de secours modernes Windows, il est recommandé aux intégrateurs système d’intégrer BOUTA dans l’ordre de priorité suivant :

Si le système est équipé d’une radio MBB, utilisez le récepteur HERTZ intégré au module MBB.
Si le système est équipé d’un soC qui a un récepteur BOUTO intégré, utilisez le récepteur BOUTA intégré au soC.
Intégrez un récepteur MODEM autonome attaché au SoC sur un bus de communication basse consommation (par exemple, UART, SPI ou I2C).

L’intégrateur système ne doit pas exposer de récepteurs BOUTA superflus à Windows. En présence de plusieurs récepteurs SYNC exposés au système d’exploitation, Windows n’agrège PAS les informations d’emplacement de tous les appareils SYNC.

Mécanisme de gestion de l’alimentation logicielle

Les appareils ACCESS dans les plateformes Windows sont censés être gérés par un pilote UMDF (User-Mode Driver Framework) qui utilise le modèle d’extension de classe de capteur Windows et implémente l’interface ISensorDriver. Ce pilote GPS est appelé pilote de capteur d’emplacement et est censé gérer le récepteur JDBC sous-jacent et fournir des données aux demandes d’application pour obtenir des informations d’emplacement.

Vue d’ensemble et modèle d’application

Les pilotes de capteur d’emplacement utilisent le nombre de clients d’application connectés comme mécanisme principal pour déterminer quand le périphérique ACCESS peut passer en mode veille ou hors tension. Le pilote de capteur d’emplacement est également responsable de la communication avec une bibliothèque de gestionnaires de radios fournie par le fournisseur PANEL qui permet à l’utilisateur de contrôler si la radio PANEL est activée ou désactivée. Le pilote du capteur d’emplacement peut utiliser à la fois le nombre de clients connectés et la préférence de l’utilisateur pour l’état radio pour s’assurer que l’appareil HERTZ est en mode veille à faible consommation ou hors tension dans la mesure du possible.

Les applications du Microsoft Store gèrent la durée de vie des applications au premier plan et en arrière-plan et ont donc une influence significative sur le nombre de clients d’application connectés au pilote de capteur d’emplacement. Une application de premier plan demande des informations d’emplacement via l’API d’emplacement Windows. Lorsque l’application au premier plan est basculée en arrière-plan par l’utilisateur, le modèle d’application du Microsoft Store garantit que l’application cliente est déconnectée du récepteur RECONFIGUR.

Ce mécanisme de modèle d’application permet au pilote de capteur d’emplacement de suivre facilement le nombre de clients d’application connectés. Chaque fois qu’il n’y a aucun client d’application connecté, le pilote du capteur d’emplacement peut faire passer l’appareil ACCESS en mode veille ou en mode de mise sous tension.

Lorsque le système entre en veille moderne, Windows suspend automatiquement toutes les applications de premier plan, ce qui entraîne l’observation du nombre de clients connectés par le pilote du capteur d’emplacement vers zéro.

Intégration de la gestion radio

Le pilote de capteur d’emplacement doit également implémenter une interface pour communiquer avec la bibliothèque de gestionnaire de radio fournie par le fournisseur. La bibliothèque de gestionnaire de radios permet à Windows d’exposer un contrôle « activé/désactivé » de l’appareil HERTZ dans l’application Paramètres Windows.

Exigences d’implémentation du pilote de capteur d’emplacement

Le pilote du capteur d’emplacement doit placer le périphérique JDBC dans un état D3 basse consommation lorsque le périphérique BOUT N’est pas utilisé. L’appareil ACCESS n’est pas utilisé lorsqu’il n’y a pas de clients connectés ou que le ACCESS a été désactivé via le gestionnaire de radio.

Le pilote du capteur d’emplacement doit conserver l’appareil HERTZ dans l’état D3 à tout moment lorsque le périphérique HERTZ a été désactivé via le gestionnaire de radio. Cette exigence empêche le pilote d’utiliser une file d’attente gérée par l’alimentation et de simplement transférer les demandes des clients connectés. Le pilote du capteur d’emplacement doit utiliser une file d’attente non gérée par l’alimentation pour les E/S et gérer l’inactivité directement à l’aide des méthodes StopIdle et ResumeIdle . Le capteur d’emplacement doit continuer à être le propriétaire de la stratégie d’alimentation pour la pile de pilotes de l’appareil GPS. Le pilote doit définir la valeur de bPowerManaged sur FALSE lors de l’appel de IWDFDevice::CreateIoQueue pour créer la file d’attente d’E/S.

Comme mentionné ci-dessus, le pilote utilise le nombre de clients connectés et l’état de la radio à partir du gestionnaire de radio pour déterminer si le périphérique HERTZ est inactif. Lorsque l’appareil RTC est inactif, le pilote appelle la méthode ResumeIdle, ce qui entraîne le lancement d’une transition D3 par l’infrastructure du pilote. L’infrastructure de pilote exécute l’implémentation du pilote de la méthode OnD0Exit .

Lorsque le périphérique RÉINITIALISATION doit être réactivé en raison d’un nouveau client connecté ou de la mise sous tension de la radio, le pilote appelle la méthode StopIdle . L’infrastructure de pilote exécute l’implémentation du pilote de la méthode OnD0Entry . Notez que le pilote doit exécuter la méthode StopIdle avec le paramètre WaitForD0 défini sur FALSE.

Le diagramme d’état fourni ci-dessous illustre cette relation et sert de guide au développeur de pilotes pour connaître quand appeler les méthodes StopIdle et ResumeIdle .

Étant donné que le pilote est chargé de suivre si l’appareil est inactif, il doit gérer directement la file d’attente d’E/S et les accès aux périphériques matériels qui en résultent.

Le pilote du capteur d’emplacement doit implémenter les méthodes IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend et IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Notez que l’infrastructure du pilote appelle IPnpCallbackSelfManagedIo::OnSelfManagedIoInit au démarrage de l’appareil, y compris au démarrage du système. Les appels suivants sont vers le rappel IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Ces interfaces doivent être inscrites lorsque l’infrastructure de pilote appelle la méthode CreateDevice.

L’IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart indique au pilote de capteur d’emplacement que les requêtes dans le pilote peuvent interagir directement avec le matériel du périphérique MESSAGE, y compris les requêtes des rappels ISensorDriver:: . Notez que l’infrastructure de pilote garantit que le matériel du périphérique est accessible à la fois dans les méthodes OnD0Exit et OnD0Entry .

De même, lorsque la méthode IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend est appelée par le framework, le pilote doit effectuer toutes les demandes ISensorDriver immédiatement avant de revenir de OnSelfManagedIoSuspend. Le pilote ne peut pas accéder au matériel de l’appareil si cela peut empêcher l’exécution de ces demandes en moins d’une seconde. Si le pilote du capteur d’emplacement a une demande en attente pour le matériel du périphérique BOUTA, la demande doit être annulée si elle ne peut pas être effectuée d’une autre manière sans violer cette contrainte de temps.

Si le pilote n’interagit pas directement avec un périphérique matériel ou si toutes les demandes de matériel en attente se terminent en une seconde, le pilote doit implémenter la méthode OnSelfManagedIoSuspend à l’aide de la procédure suivante :

Définissez un indicateur global indiquant que l’appareil est inactif.
Appelez la méthode StopSynchronously dans la file d’attente WDF (Windows Driver Frameworks).
Arrêtez tout autre travail asynchrone qui accède au matériel de l’appareil TRUI.
Appelez la méthode Start sur la file d’attente WDF.
Effacez l’indicateur global défini à l’étape 1.

Pour obtenir un exemple de code qui effectue ces opérations, consultez l’implémentation OnSelfManagedIoSuspend dans Sensors Geolocation Sample Driver (UMDF Version 1).

Si le pilote interagit directement avec un périphérique matériel, toutes les demandes en attente adressées au matériel doivent être annulées avant de vider la file d’attente d’E/S. Le pilote doit implémenter la méthode OnSelfManagedIoSuspend à l’aide de la procédure suivante :

Définissez un indicateur global indiquant que l’appareil est inactif.
Appelez la méthode Stop sur la file d’attente WDF.
Annulez toutes les demandes matérielles en attente pour permettre à tous les threads de rappel ISensorDriver de se terminer.
Appelez la méthode StopSynchronously sur la file d’attente WDF.
Arrêtez tout autre travail asynchrone qui accède au matériel de l’appareil TRUI.
Appelez la méthode Start sur la file d’attente WDF.
Effacez l’indicateur global défini à l’étape 1.

Tous les pilotes de capteur d’emplacement doivent vider de façon synchrone la file d’attente d’E/S dans leur implémentation de la méthode OnSelfManagedIoFlush .

Mode veille et mode de mise sous tension

Les appareils DOR peuvent prendre en charge à la fois le mode veille et le mode de mise hors tension lorsque le contexte local de l’appareil est conservé et peut toujours répondre aux demandes via le bus de communications sans signalisation externe. (En règle générale, un appareil en mode de mise sous tension ne peut pas répondre aux demandes de bus.) Le pilote du capteur d’emplacement doit être écrit pour comprendre si l’appareil sous-jacent est capable d’utiliser le mode hors tension. Le pilote de capteur d’emplacement doit activer D3cold uniquement si l’appareil sous-jacent est capable de fonctionner en mode hors tension et s’il est capable d’enregistrer/restaurer le contexte et de réin initialiser l’appareil. Sinon, le capteur d’emplacement doit continuer à utiliser D3 comme état inactif, mais pas activer D3cold. Cela permet aux pilotes de bus et de filtre sous-jacents de mettre l’appareil en mode veille à faible consommation et non en mode hors tension.

Lorsque le pilote du capteur d’emplacement indique qu’il prend en charge D3cold et commence une transition D3, les pilotes de bus et de filtre sous-jacents sont chargés de supprimer l’alimentation de l’appareil. Le mécanisme peut être mis en œuvre par l’ACPI dans le cas d’appareils UU connectés à UART. Ou bien, le mécanisme peut être activé par une combinaison du pilote de hub USB et du pilote ACPI dans le cas de périphériques SYNC énumérés par USB.

Si l’appareil SCALABILIT se trouve sur le SoC, le pilote et le microprogramme propriétaires du fournisseur soC implémentés dans le ou les pilotes sous-jacents sont chargés de retirer l’alimentation du périphérique JDBC. Si l’appareil WU consomme plus de 1 mW dans son mode d’alimentation veille, le pilote, le microprogramme de plateforme et le matériel WU doivent être conçus pour placer l’appareil en mode hors tension lorsque tous les clients sont déconnectés.

Détection des inactifs

Le pilote de capteur d’emplacement d’un appareil JDBC doit faire passer l’appareil en mode veille dans la mesure du possible. Si une application demande un long intervalle de rapport, le pilote du capteur d’emplacement doit faire passer le périphérique JDBC en mode veille jusqu’à ce que le correctif suivant soit demandé. Le pilote du capteur d’emplacement doit faire passer l’appareil GPS au mode d’alimentation actif avec suffisamment de temps pour trianguler un correctif et fournir à l’application des données d’emplacement.

Par exemple, supposons que l’intervalle de rapport demandé le plus court soit de 30 minutes et que l’appareil nécessite une minute pour se réchauffer et obtenir un correctif d’emplacement. Dans ce scénario, le pilote du capteur d’emplacement doit :

Immédiatement après avoir fourni des informations d’emplacement, appelez ResumeIdle qui fera passer l’appareil BOUTA en mode veille (D3).
Armez un minuteur pour qu’il expire 28 minutes dans le futur. (TimerExpiration = ReportInterval – WarmUpTime).
Lorsque le minuteur expire, appelez StopIdle qui fera passer l’appareil MESSAGE vers D0.
Lorsque l’appareil a acquis un correctif, fournissez des informations d’emplacement à l’application. Note Le pilote du capteur d’emplacement doit configurer soigneusement D3cold.

Si l’appareil a besoin d’une alimentation continue afin d’obtenir la latence de reprise de l’intervalle warmuptime, D3cold ne doit pas être activé. D3cold peut être activé dynamiquement au moment de l’exécution en modifiant la valeur de ExcludeD3Cold dans la structure WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS.

Lorsqu’un appareil RFID attaché à USB passe en mode veille (D3) avec D3cold désactivé, l’appareil passe à l’état de suspension USB, ce qui permet d’économiser une puissance importante du processeur et du processeur. Si le pilote du capteur d’emplacement active D3cold et passe en mode veille (D3), la plateforme sous-jacente peut retirer l’alimentation de l’appareil même lorsqu’il est attaché via le bus USB.

Configurations matérielles prises en charge

Windows prend en charge quatre configurations matérielles physiques pour l’appareil NCA. Le bus de connectivité différencie chaque configuration matérielle.

UU connecté au SoC sur UART

Dans cette configuration, la radio HERTZ est un appareil autonome connecté à un UART sur le SoC. La radio RDA peut avoir un ou plusieurs GPIO entre la radio et le SoC à des fins de transition entre les modes d’alimentation actif et veille ou pour gérer les conditions de séquencement de réinitialisation et de mise sous tension.

Si la radio WU consomme moins de 1 mW en mode veille, elle peut être connectée à n’importe quel rail d’alimentation du système qui répond aux spécifications de l’appareil.

L’appareil RDA doit être déclaré dans l’espace de noms ACPI et les GPIO pour la gestion de l’alimentation doivent être contrôlés par les méthodes de contrôle _PS3 et _PS0 sous l’appareil dans l’espace de noms ACPI. Les méthodes _PS3 et _PS0 sont exécutées par le pilote ACPI en réponse aux transitions D3 et D0 initiées par le pilote de capteur d’emplacement. L’intégrateur système doit déclarer les GPIOs dans le cadre d’une région d’opération GPIO dans l’espace de noms ACPI.

Si le récepteur WU consomme plus de 1 mW dans son mode d’alimentation veille, il doit être connecté à un rail d’alimentation qui peut être allumé et désactivé à l’aide d’un GPIO contrôlé par le microprogramme ACPI sur le SoC. Dans cette configuration, le pilote du capteur d’emplacement doit activer D3cold. Le GPIO pour le contrôle du rail d’alimentation commutable doit être exposé dans une région d’opération ACPI GPIO. L’intégrateur de système doit décrire une ressource d’alimentation pour le rail d’alimentation commutable, y compris les méthodes de _OFF et de _ON, ainsi que les références à la ressource d’alimentation sous l’appareil INACCESSIBLE dans l’espace de noms.

Le pilote Windows ACPI évalue la méthode _OFF lorsque le pilote du capteur d’emplacement passe à D3. Lorsque le pilote du capteur d’emplacement passe à D0, le pilote Windows ACPI évalue la méthode _ON sous la ressource d’alimentation. L’implémentation des méthodes _OFF et _ON doit activer le GPIO qui contrôle le rail d’alimentation commutable et implémenter tous les retards de séquencement d’alimentation requis.

AUTHENTIFICATION intégrée au SoC

Si l’appareil GPS est physiquement intégré au soC, l’implémentation des communications et de la gestion de l’alimentation est spécifique au soC lui-même.

L’appareil KADHAFI doit toujours être énuméré via ACPI, bien que les communications avec le récepteur BOUTA sous-jacent puissent se produire par le biais d’un pilote de transport fourni par le fournisseur soC. Dans cette configuration, le pilote du capteur d’emplacement doit toujours implémenter une transition D3 pour passer en mode veille ou hors tension lorsque tous les clients sont déconnectés. La transition D3 garantit que les outils et les diagnostics de gestion de l’alimentation du système d’exploitation Windows peuvent facilement observer l’état d’alimentation de l’appareilnaire.

Les intégrateurs de systèmes qui prévoient de tirer parti d’une radio RTC intégrée au système SoC doivent consulter étroitement le fournisseur de soC pour la prise en charge du microprogramme, du pilote et de la gestion de l’alimentation.

TIL intégré à une radio MBB attachée par USB en tant que périphérique composite USB

Le concepteur de système peut choisir d’intégrer un module MBB attaché par USB qui contient un récepteur MODEM incorporé. Dans cette configuration matérielle, le pilote de capteur d’emplacement communique avec le récepteur TOUTA incorporé directement sur le bus USB en tant que fonction unique dans un périphérique composite USB.

Note Les systèmes avec des appareils SYNC sur le module MBB nécessitent une attention particulière en matière d’intégration. Contactez votre représentant Microsoft pour passer en revue la conception du matériel, des logiciels et du microprogramme pour ces solutions.

Dans cette configuration, l’appareil est une partie intégrée du module MBB. La radio HERTZ peut partager des composants de traitement, d’alimentation et d’antenne RF avec la radio MBB. La radio HERTZ est exposée directement au logiciel en tant qu’interface unique sur un périphérique composite USB. Le pilote du capteur d’emplacement communique avec la radio HERTZ directement sur le bus USB à l’aide d’interfaces de pilote USB implémentées à l’intérieur du pilote de capteur de localisation.

La gestion de l’alimentation du matériel GPS est pilotée par les communications in-band vers le module BOUTA. Le module HERTZ et le pilote du capteur d’emplacement doivent prendre en charge un mécanisme en bande pour activer et désactiver la radio HERTZ. Ce mécanisme ne doit pas reposer sur l’utilisation d’un GPIO du SoC vers le module MBB+RDA.

De même, le module RÉINITIALISATION et le pilote du capteur d’emplacement doivent prendre en charge la transition du périphérique vers l’état D3 afin que le périphérique composite USB puisse passer à l’état de suspension (suspension sélective) USB. Toutes les fonctions d’un périphérique composite USB doivent être suspendues pour que l’appareil composite soit suspendu. L’appareil SSD doit être en mode Veille (D3) pour que la fonction BOUTA et l’ensemble du périphérique composite USB soient à l’état de suspension.

Note Le périphérique RÉINITIALISATION et le pilote doivent prendre en charge la suspension sélective, sinon le contrôleur hôte USB sur le SoC ne peut pas passer en mode basse consommation et empêchera les économies d’énergie pendant la veille moderne.

Dans cette configuration, le périphérique TIL est énuméré via USB et le pilote composite USB, mais est décrit dans l’espace de noms ACPI. Dans cette configuration, il n’existe aucune prise en charge des communications GPIO entre l’appareilnaire sur le module MBB et le SoC. L’appareil KADHAFI doit rester énuméré sur Windows via ACPI pendant toute la durée pendant laquelle la plateforme reste dans l’état d’alimentation du système S0, même si la radio est désactivée par l’utilisateur. L’appareil GPS ne doit jamais disparaître du bus USB pendant n’importe quelle partie du système à temps.

TIL intégré à une radio MBB attachée par USB à l’aide de services d’appareil

Le concepteur de système peut choisir d’intégrer un module MBB attaché par USB qui contient un récepteur MODEM incorporé. Dans cette configuration matérielle, le pilote de capteur d’emplacement communique avec le récepteur CONFORMÉMENT À l’interface des services d’appareil haut débit mobile, par opposition à l’exposition de l’appareil BOUT EN tant que fonction USB autonome dans le cadre du périphérique composite qui représente l’ensemble du module MBB.

Note Cette configuration n’est pas recommandée. Les intégrateurs de système qui choisissent cette méthode d’intégration d’appareil BOUT DOIVENT contacter leur représentant Microsoft pour valider l’implémentation correcte. Il est préférable d’exposer l’appareil TIL dans le cadre d’un périphérique composite USB représentant le module MBB.

Dans cette configuration, l’appareil est une partie intégrée du module MBB. La radio HERTZ peut partager des composants de traitement, d’alimentation et d’antenne RF avec la radio MBB. La radio DIAG est exposée indirectement au logiciel via l’interface des services d’appareil, accessible à l’aide de l’interface COM WindowsIMbnDeviceServices. Le pilote du capteur d’emplacement communique avec la radio HERTZ par le biais de l’interface IMbnDeviceServices.

La gestion de l’alimentation du matériel GPS est pilotée par des communications in-band sur l’interface des services d’appareil vers le module MBB. Le matériel HERTZ doit prendre en charge un mécanisme in-band sur l’interface des services d’appareil pour désactiver la radio et placer l’appareil HERTZ en mode basse consommation. Ces mécanismes doivent être accessibles par le pilote du capteur d’emplacement via l’interface des services d’appareil.

Dans cette configuration, l’appareil CLIENT doit être énuméré par ACPI et décrit dans l’espace de noms ACPI en tant qu’enfant du module haut débit mobile. L’appareil KADHAFI n’aura aucune ressource matérielle décrite sous l’appareil dans l’espace de noms ACPI.

Le pilote de capteur d’emplacement doit toujours exécuter le même ensemble d’instructions d’implémentation de la gestion de l’alimentation que celles décrites dans la section précédente sur les exigences d’implémentation des pilotes.

Dans cette configuration, il n’existe aucune prise en charge des communications GPIO entre l’appareilnaire sur le module MBB et le SoC. Toutes les communications radio et de gestion de l’alimentation sont effectuées physiquement sur le bus USB et exposées au pilote du capteur d’emplacement via l’interface des services d’appareil. L’appareil KADHAFI doit rester énuméré sur Windows via ACPI pour tout le système à temps, même si la radio est désactivée par l’utilisateur.

Lors de l’implémentation de cette configuration matérielle, l’intégrateur système est encouragé à travailler en étroite collaboration avec le fournisseur du module MBB pour s’assurer que l’appareil CLIENT est exposé correctement dans l’espace de noms ACPI.

Problèmes de veille

Il n’y a aucun problème de veille pour les appareils SYNC. Les appareils GPS ne sont pas censés prendre en charge la veille du SoC à partir d’un état de faible consommation.

Test et validation

Les fournisseurs d’appareils GPS, les fournisseurs de modules MBB et les intégrateurs système doivent suivre ces recommandations pour tester et valider l’implémentation de la gestion de l’alimentation de l’appareil BOUTA et de ses composants logiciels associés. Pour plus d’informations, consultez Guide de test du système global de navigation par satellite (ATLAS).

Gestion de l’alimentation du capteur d’emplacement

L’intégrateur système doit vérifier que le pilote de capteur d’emplacement pour l’appareil HERTZ effectue des transitions de gestion de l’alimentation et passe à l’état D3 lorsque tous les clients sont déconnectés ou que la radio a été désactivée.

Les cas de test de base sont les suivants :

Observez la transition du pilote du capteur d’emplacement vers D3 dans les 10 secondes suivant la désactivation de l’écran pour la veille moderne.
Observez la transition du pilote du capteur d’emplacement vers D3 dans les 10 secondes qui suivent la désactivation de la radio dans l’application Paramètres Windows.
Observez la transition du pilote de capteur d’emplacement vers D0 immédiatement après avoir quitté la veille moderne et lancé une application qui utilise l’API d’emplacement.

Le moyen le plus simple d’observer les transitions d’état Dx du pilote de capteur d’emplacement consiste à utiliser Windows Performance Toolkit pour effectuer une comparaison avec d’autres appareils de capteur Windows. Cette méthode utilise l’instrumentation Windows pour vérifier que l’IRP D3 est en cours de transition via la pile de pilotes de périphérique qui comprend l’appareil GPS. Le gestionnaire d’alimentation Windows inclut un suivi d’événements intégré pour l’instrumentation ETW (Event Tracing for Windows), y compris l’instrumentation pour les irps d’alimentation des appareils (Dx). Pour afficher ces informations en mode manuel, obtenez et installez windows Performance Toolkit (WPT) sur le système en cours de test.

Commencez une trace XPerf en mode utilisateur à l’aide des commandes suivantes :

Ouvrez une invite de commandes Administrateur.
Accédez au dossier \%ProgramFiles%\Windows Kits\8.0\Windows Performance Toolkit\ .
Démarrer Xperf : xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power
Faites passer le système à la veille moderne à l’aide du bouton Marche/Arrêt.
Attendez 120 secondes.
Faites sortir le système de la veille moderne à l’aide du bouton Marche/Arrêt.
Attendez 60 secondes.
Exécutez la commande suivante pour arrêter la journalisation des événements : xperf.exe -stop power_session
Convertissez le fichier de trace binaire dans un format .csv et lisible par l’utilisateur : xperf.exe –i \user.etl > power.txt
Ouvrez le fichier power.txt dans un éditeur de texte et recherchez l’ID matériel de l’appareil BOUT. L’ID matériel de l’appareil BOUTA peut être déterminé à partir de l’onglet Détails des propriétés de l’appareil dans Gestionnaire de périphériques sous Chemin d’accès de l’instance de l’appareil. Dans l’exemple ci-dessous, le chemin d’accès instance de l’appareil KADHAFI est ACPI\MST0731\2&daba3ff&0.
L’IRP D3 pour l’appareil SSD est indiqué par un événement de type Microsoft-Windows-Kernel-Power/IRP/Stop avec le chemin d’accès instance de l’appareil SSD et la dernière valeur d’événement de 3 pour l’état D3. La sortie de l’événement ci-dessous du fichier power.txt indique le début de l’IRP D3.

Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3
Cet événement doit être enregistré près du début du fichier de sortie power.txt. Le paramètre 0x868e2728 dans l’exemple ci-dessus est un pointeur vers la structure IRP D3. En recherchant les événements suivants avec ce même pointeur IRP, vous pouvez découvrir une vue de l’IRP D3 circulant à travers la pile de pilotes qui comprend le périphérique JDBC. Notez que le pointeur IRP sera spécifique au système et à la durée de vie de démarrage.
Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3
Microsoft-Windows-Kernel-Power/Driver/Start , 7605416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\gpsdrv"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7605515, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0
Microsoft-Windows-Kernel-Power/Driver/Start , 7608351, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90, "\Driver\ACPI"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7608416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90
Microsoft-Windows-Kernel-Power/Driver/Start , 7608424, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

La validation du retour de l’appareil à D0 lorsque l’écran est allumé est un processus similaire. Un événement Microsoft-Windows-Kernel-Power/IRP/Start pour l’appareil est enregistré avec un état cible 0 (D0). L’IRP D0 transite par le ou les pilotes qui composent la pile de périphériques JDBC d’une manière similaire à l’IRP D3.

Liste de contrôle de la gestion de l’alimentation BOUT

Les intégrateurs de systèmes, les fournisseurs de radios HERTZ et les fournisseurs de 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 versions ultérieures.

Intégrez un appareil PAA à la plateforme moderne compatible avec le mode de secours dans l’ordre de préférence de configuration suivant :
1. Intégré à un module MBB (pour les systèmes équipés de MBB), connecté via USB.
2. Intégré au SoC (pour les systèmes qui ont BOUTA sur le SoC).
3. Autonome en dehors du SoC connecté à UART, I2C ou à un autre bus à faible consommation.
Sélectionnez un appareil WU dont la consommation d’énergie moyenne en veille (radio désactivée) est inférieure à 1 mW, y compris toutes les interfaces de connexion de bus.
Si la consommation d’énergie moyenne de l’appareil WU est supérieure à 1 mW en veille (radio désactivée), l’intégrateur système et le fournisseur de l’appareil WU doivent prendre en charge la suppression complète de l’alimentation de l’appareil WU lorsqu’il n’y a pas de clients d’application connectés ou que la radio est désactivée par l’utilisateur.
Vérifiez que le fournisseur de l’appareil ACCESS fournit un pilote de capteur d’emplacement qui implémente la gestion de l’alimentation au runtime en fonction du nombre de clients connectés et de l’état de la radio HERTZ.
Vérifiez que le fournisseur de l’appareil HERTZ fournit une bibliothèque de gestionnaires de radios qui expose la radio HERTZ dans l’application Paramètres Windows.

Le pilote de capteur d’emplacement doit implémenter une interface privée pour communiquer l’état de la radio activée/désactivée entre la bibliothèque de gestionnaire de radio fournie par le fournisseur et le pilote de capteur d’emplacement fourni par le fournisseur.
Si l’UU est un appareil autonome en dehors du soC connecté via UART, I2C ou tout autre bus à faible consommation d’énergie, l’intégrateur système et le fournisseur d’appareils UU doivent :
1. Documentez tous les GPIO entre l’appareil RDA et le SoC lui-même.
2. Exposez tous les GPIO pour la gestion de l’alimentation dans le cadre d’une région d’opération GPIO dans l’espace de noms ACPI.
Si le WU est un appareil autonome en dehors du SoC connecté via UART, I2C ou tout autre bus à faible consommation d’alimentation et que la consommation d’énergie moyenne de l’appareil UU en mode veille est supérieure à 1 mW, l’intégrateur système et le fournisseur de l’appareil BOUT DOIVENT :
1. Fournissez une ressource d’alimentation ACPI et des méthodes de contrôle _ON/_OFF pour décrire le domaine d’alimentation PANEL.
2. Fournissez les méthodes _PR0 et _PR3 sous l’appareil SYNC dans l’espace de noms ACPI qui font référence à la ressource d’alimentation ACPI décrite.
3. Vérifiez que le pilote du capteur d’emplacement effectue une transition D3 et active D3cold dans le pilote.
Si l’élément INTEGRATOR fait partie d’un module MBB, l’intégrateur système et le fournisseur d’appareils BOUT DOIVENT :
1. Exposez l’appareil GPS dans le cadre d’un périphérique composite USB.
2. Fournissez un pilote de capteur d’emplacement qui communique directement avec le périphérique TIL par le biais du bus USB.
3. Assurez-vous que l’activation/la désactivation de la radio et toute la gestion de l’alimentation de l’appareil HERTZ peuvent être effectuées en bande sur le bus USB. Aucun GPIO ne peut être utilisé pour modifier l’état de l’alimentation ou de la radio RDA dans cette configuration matérielle.
4. Vérifiez que le périphérique USB décrivant le module MBB ou le périphérique composite USB décrivant à la fois la radio MBB et la radio TIL entre dans l’état de suspension USB pendant la veille moderne.
5. Le pilote du capteur d’emplacement DOIT passer en mode D3 (veille) lorsque tous les clients sont déconnectés ou que la radio a été désactivée, même si elle communique avec l’appareil via l’interface des services d’appareil.
6. Si l’appareil CLIENT est contrôlé via l’interface des services d’appareil haut débit mobile (ce qui n’est pas recommandé), l’appareil CLIENT doit être décrit dans l’espace de noms ACPI système sans ressources matérielles. L’appareil CLIENT doit être décrit comme un enfant du module haut débit mobile dans l’espace de noms ACPI.
Testez et vérifiez que l’appareil JDBC et le pilote du capteur d’emplacement effectuent correctement la gestion de l’alimentation. Validez au minimum les cas de test suivants :
- Observez la transition du pilote du capteur d’emplacement vers D3 dans les 10 secondes suivant la désactivation de l’écran pour la veille moderne.
- Observez la transition du pilote du capteur d’emplacement vers D3 dans les 10 secondes qui suivent la désactivation de la radio dans l’application Paramètres Windows.
- Observez la transition du pilote de capteur d’emplacement vers D0 immédiatement après avoir quitté la veille moderne et lancé une application qui utilise l’API d’emplacement.
Validez la consommation électrique de l’appareil RTC dans l’état veille (D3) et assurez-vous qu’elle est inférieure à 1 mW en moyenne.

Partager via