Partager via

Conception du pilote BOUT (Global Navigation Satellite System)

  • Article

Décrit les principes de conception à prendre en compte lors du développement d’un pilote de système global de navigation par satellite (GPS) pour Windows 10 notamment les structures de données, la création de rapports d’erreurs et le contrôle de version des pilotes.

Structures de données

Pour la compatibilité descendante et l’extensibilité future, toutes les structures de données commencent par un numéro de version et une taille pour prendre en charge les extensions futures et les problèmes de compatibilité descendante. En guise de protection supplémentaire, chaque structure dispose également d’une mémoire tampon de remplissage pour conserver la taille de la structure statique même lorsque de nouveaux champs sont ajoutés. Il s’agit d’une protection contre les pilotes COMPILE plus anciens qui utilisent par erreur la taille statique au moment de la compilation de la structure (à l’aide de sizeof) au lieu de la taille dynamique de la structure.

Sauf indication contraire, tous les paramètres suivent le Système international d’unités (SI) :

Paramètres Unités
Distance, seuil ou niveau mètre
Délai d’expiration ou intervalle second
Vitesse compteur/seconde

Rapport d’erreurs

Le système global de navigation par satellite (WU) DDI attend un NTSTATUS comme valeur de retour du pilote. Le système d’exploitation de haut niveau (HLOS) agit uniquement sur les cas de réussite et d’échec en fonction de ces messages d’erreur et n’examine pas un message d’erreur spécifique. Toutefois, il est préférable que le pilote retourne les erreurs étroitement mappées au message d’erreur NTSTATUS correspondant. Le pilote WU peut envoyer ses propres messages d’erreur NTSTATUS personnalisés qui peuvent être utiles à des fins de diagnostic.

Contrôle de version des pilotes

Chaque structure spécifiée pour le DDI du système global de navigation par satellite (ATLAS) contient un champ de version de pilote, et de nombreuses structures contiennent un champ de remplissage. Ces deux composants sont utilisés pour atténuer les nouvelles versions de la DDI LOCKER, à l’aide des stratégies suivantes :

  • Le framework et le pilote communiquent leurs versions respectives à l’aide du processus d’échange de fonctionnalités. Ces IOCTL sont considérés comme spéciaux, car ils communiquent leurs versions à l’aide du champ version. Par conséquent, les implémentations entourant la vérification des capacités de l’appareil et de la plateforme doivent case activée explicitement les versions retournées en premier et les stocker pour une utilisation ultérieure. Le membre de version de la structure GNSS_DEVICE_CAPABILITY communique le numéro de version du pilote. Le membre de version de la structure GNSS_PLATFORM_CAPABILITY communique le numéro de version de l’adaptateur GPS.

  • Chaque fois qu’un nouveau champ est ajouté, si la structure a un champ de remplissage, l’espace doit être retiré du remplissage au lieu de l’ajouter à la structure, ce qui maintient la compatibilité binaire

  • Chaque fois qu’un nouveau champ est ajouté, la version de la DDI FOSS est considérée comme incrémentée. Cela est reflété dans un commentaire dans l’en-tête DDI FOSS lui-même, mais n’est PAS exposé en tant que constante. L’adaptateur GPS et le pilote GPS utilisent des valeurs constantes privées pour indiquer leur version actuelle. Cela permet à la fois à l’adaptateur JDBC et au pilote d’être codés par rapport à une version spécifique.

  • L’adaptateur JDBC doit être à compatibilité descendante avec les versions antérieures du pilote JDBC. Si un changement de protocole est introduit dans une nouvelle version de la DDI, un adaptateur JDBC conforme au nouveau DDI FOSS doit implémenter le nouveau protocole uniquement pour la nouvelle version du pilote et utiliser l’ancien protocole pour l’ancienne version du pilote.

  • Le pilote JDBC doit être compatible avec les versions plus récentes de l’adaptateur JDBC et doit traiter les versions plus récentes de l’adaptateur TOUT COMME la version actuelle sur laquelle il est codé.

  • Une version antérieure de l’adaptateur JDBC n’est pas censée fonctionner correctement avec une version plus récente du pilote JDBC. Pour faciliter le co-développement de l’adaptateur JDBC et du pilote JDBC par rapport à une nouvelle version de la DDI, il n’existe pas de version stricte case activée dans l’adaptateur JDBC pour bloquer les nouveaux pilotes TOUTA. Toutefois, un pilote SYNC implémenté par rapport à une version plus récente de la DDI ne sera pas expédié aux appareils de vente au détail qui contiennent un adaptateur JDBC implémenté par rapport à une version antérieure de la DDI JDBC.

  • Les pilotes Windows 8.1 ou les anciens pilotes de capteur BOUTA ne sont pas pris en charge par l’adaptateur JDBC. Ces pilotes continueraient à fonctionner dans Windows 10 via la pile héritée. En présence d’un autre pilote RTC Windows 10, l’utilisation du pilote de capteur RTC hérité n’est pas définie.