Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Mettre en œuvre des API de couche d'abstraction de plate-forme

OpenThread est indépendant du système d'exploitation et de la plate-forme, avec une couche d'abstraction de plate-forme étroite (PAL). Ce PAL définit:

Architecture de portage

Toutes les API doivent être implémentées en fonction du package de support de construction (BSP) de la couche d'abstraction matérielle (HAL) sous-jacent.

Les fichiers API doivent être placés dans les répertoires suivants:

Type Annuaire
Implémentation PAL spécifique à la plateforme /openthread/examples/platforms/ platform-name
Fichiers d'en-tête - API de stockage non volatile /openthread/examples/platforms/utils
Tous les autres fichiers d'en-tête /openthread/include/openthread/platform
HAL BSP /openthread/third_party/ platform-name

Alarme

Déclaration API:

/openthread/include/openthread/platform/alarm-milli.h

L'API d'alarme fournit des services de synchronisation et d'alarme fondamentaux pour la mise en œuvre du temporisateur de couche supérieure.

Il existe deux types de service d'alarme, milliseconde et microseconde . Une milliseconde est requise pour une nouvelle plate-forme matérielle. La microseconde est facultative.

UART

Déclaration API:

/openthread/include/openthread/platform/uart.h

L'API UART implémente la communication fondamentale du port série via l'interface UART.

Alors que les modules complémentaires OpenThread CLI et [NCP] / (https://github.com/openthread/openthread/tree/masterexamples/apps/ncp) dépendent de l'interface UART pour interagir avec le côté hôte, la prise en charge de l'API UART est facultative . Cependant, même si vous ne prévoyez pas d'utiliser ces modules complémentaires sur votre nouvel exemple de plate-forme matérielle, nous vous recommandons vivement d'ajouter la prise en charge pour plusieurs raisons:

  • La CLI est utile pour valider que le port fonctionne correctement
  • L'outil d'automatisation de harnais utilise l'interface UART pour contrôler OpenThread à des fins de test et de certification

Si la plate-forme matérielle cible prend en charge un module USB CDC plutôt que UART, assurez-vous de:

  • Installez le pilote USB CDC correct du côté hôte
  • Remplacez l'implémentation de l'API UART par le pilote USB CDC (avec BSP) du côté OpenThread, en utilisant les mêmes prototypes de fonction

Radio

Déclaration API:

/openthread/include/openthread/platform/radio.h

L'API Radio définit toutes les fonctions nécessaires appelées par la couche MAC IEEE 802.15.4 supérieure. La puce radio doit être entièrement conforme à la spécification 2.4 GHz IEEE 802.15.4-2006.

En raison de sa fonction de faible consommation améliorée, OpenThread exige que toutes les plates-formes implémentent par défaut la mise en attente de trame automatique (transmission indirecte), et la table de correspondance des adresses source doit également être implémentée dans le fichier source radio.h .

Cependant, si votre nouvel exemple de plate-forme matérielle est limité en ressources, la table d'adresses source peut être définie comme une longueur nulle. Voir Auto Frame Pending pour plus d'informations.

Divers / Réinitialiser

Déclaration API:

/openthread/include/openthread/platform/misc.h

L'API Misc / Reset fournit une méthode pour réinitialiser le logiciel sur la puce et interroger la raison de la dernière réinitialisation.

Entropie

Déclaration API:

/openthread/include/openthread/platform/entropy.h

L'API Entropy fournit un véritable générateur de nombres aléatoires (TRNG) pour la couche supérieure, qui est utilisé pour maintenir les actifs de sécurité pour l'ensemble du réseau OpenThread. L'API doit garantir qu'un nouveau nombre aléatoire est généré pour chaque appel de fonction. Les actifs de sécurité concernés par le TRNG comprennent:

  • AES CCM nonce
  • Gigue retardée aléatoire
  • Adresse étendue des appareils
  • La période aléatoire initiale dans le minuteur de maintien
  • ID de jeton / message CoAP

Notez que de nombreuses plates-formes ont déjà intégré un générateur de nombres aléatoires, exposant l'API dans son package BSP. Dans le cas où la plate-forme matérielle cible ne prend pas en charge TRNG, envisagez de tirer parti de l'échantillonnage du module ADC pour générer un nombre aléatoire de longueur fixe. Échantillonnez sur plusieurs itérations si nécessaire pour répondre aux exigences TRNG (uint32_t).

Lorsque la macro MBEDTLS_ENTROPY_HARDWARE_ALT est définie sur 1 , cette API doit également fournir une méthode pour générer l'entropie matérielle utilisée dans la bibliothèque mbedTLS.

Stockage non volatile

Déclarations API:

/openthread/include/openthread/platform/flash.h

ou

/openthread/include/openthread/platform/settings.h

L'exigence de stockage non volatile peut être satisfaite en implémentant l'une des deux API répertoriées ci-dessus. L'API Flash implémente un pilote de stockage flash, tandis que l'API Settings fournit des fonctions pour une implémentation d'opération flash sous-jacente à la couche supérieure.

Ces API exposent à la couche supérieure:

  • La taille de stockage non volatile disponible utilisée pour stocker les données d'application (par exemple, l'ensemble de données opérationnelles actif / en attente, les paramètres réseau actuels et les informations d'identification des périphériques de thread pour le rattachement après la réinitialisation)
  • Lire, écrire, effacer et interroger les opérations sur l'état du flash

Utilisez OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE dans le fichier de configuration de base de votre exemple de plate-forme pour indiquer l'API que la plate-forme doit utiliser. S'il est défini sur 1 , l'API Flash doit être implémentée. Sinon, l'API Settings doit être implémentée.

Cet indicateur doit être défini dans votre /openthread/examples/platforms/ platform-name /openthread-core- platform-name -config.h .

Enregistrement

Déclaration API:

/openthread/include/openthread/platform/logging.h

L'API de journalisation implémente la fonctionnalité de journalisation et de débogage d'OpenThread, avec plusieurs niveaux de sortie de débogage disponibles. Cette API est facultative si vous ne prévoyez pas d'utiliser la journalisation d'OpenThread sur votre nouvel exemple de plate-forme matérielle.

Le niveau le plus élevé et le plus détaillé est OPENTHREAD_LOG_LEVEL_DEBG , qui imprime toutes les informations brutes sur les paquets et enregistre les lignes via le port série ou sur le terminal. Choisissez un niveau de débogage qui répond le mieux à vos besoins.

Spécifique au système

Déclaration API:

/openthread/examples/platforms/openthread-system.h

L'API spécifique au système fournit principalement des opérations d'initialisation et de déinitialisation pour la plate-forme matérielle sélectionnée. Cette API n'est pas appelée par la bibliothèque OpenThread elle-même, mais peut être utile pour votre système / RTOS. Vous pouvez également implémenter l'initialisation d'autres modules (par exemple, UART, Radio, Random, Misc / Reset) dans ce fichier source.

La mise en œuvre de cette API dépend de votre cas d'utilisation. Si vous souhaitez utiliser les applications CLI et NCP générées pour un exemple de plate - forme , vous devez implémenter cette API. Sinon, n'importe quelle API peut être implémentée pour intégrer les exemples de pilotes de plate-forme dans votre système / RTOS.