Implémenter des API de couche d'abstraction de plate-forme

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Voir la source sur GitHub

OpenThread est indépendant de l'OS et de la plate-forme, avec une couche d'abstraction de plate-forme (PAL) étroite. Cette PAL définit:

Architecture de transfert
  • Interface d'alarme pour le minuteur avec alarme
  • Interfaces de bus (UART, SPI) pour la communication des messages CLI et Spinel
  • Interface radio pour la communication IEEE 802.15.4-2006
  • Routines d'initialisation spécifiques à GCC
  • Entropie pour la génération de nombres aléatoires réels
  • Service des paramètres pour le stockage de la configuration non volatile
  • Interface de journalisation pour la distribution des messages de journal OpenThread
  • Routines d'initialisation spécifiques au système

Toutes les API doivent être mises en œuvre sur la base du package d'assistance HAL (Hardware Abstraction Layer) sous-jacente.

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

Type Répertoire
Implémentation d'une PAL sur une plate-forme spécifique /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
BAL HAL /openthread/third_party/platform-name

Alarme

Déclaration de l'API:

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

L'API Alarm fournit des services de base et d'alarme pour l'implémentation du minuteur de couche supérieure.

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

UART

Déclaration de l'API:

/openthread/examples/platforms/utils/uart.h

L'API UART met en œuvre la communication de base du port série via l'interface UART.

Bien que les modules complémentaires CLI et NCP d'OpenThread dépendent de l'interface UART pour interagir avec l'hôte, la prise en charge de l'API UART est facultative. Toutefois, même si vous ne prévoyez pas d'utiliser ces modules complémentaires dans votre nouvel exemple de plate-forme matérielle, nous vous recommandons vivement d'en ajouter pour quelques raisons:

  • La CLI sert à vérifier que le port fonctionne correctement.
  • L'outil Harness Automation utilise l'interface UART pour contrôler OpenThread à des fins de test et de certification

Si la plate-forme matérielle cible est compatible avec un module CDC USB plutôt qu'UART, vérifiez les points suivants:

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

Radio

Déclaration de l'API:

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

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

En raison de sa fonctionnalité basse consommation améliorée, OpenThread nécessite que toutes les plates-formes implémentent le frame automatique en attente (transmission indirecte) par défaut, et la table de correspondance d'adresse source doit également être implémentée dans le fichier source radio.h.

Cependant, si le nouvel exemple de plate-forme matérielle est limité en ressources, la table d'adresse source peut être définie sur une longueur de zéro. Pour en savoir plus, consultez la section Auto Frame Pending.

Divers/Réinitialiser

Déclaration de l'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 de l'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, utilisé pour gérer les éléments de sécurité de 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 éléments de sécurité concernés par le TRNG sont les suivants:

  • Nonce AES CCM
  • Gigue retardée
  • Appareils, adresse étendue
  • La période aléatoire initiale dans le minuteur
  • Identifiants/jeton CoAP

Notez que de nombreuses plates-formes ont déjà intégré un générateur de nombres aléatoires, qui exposent l'API dans son package BSP. Si la plate-forme matérielle cible n'est pas compatible avec TRNG, envisagez d'utiliser l'échantillonnage du module ADC pour générer un nombre aléatoire de longueur fixe. Effectuez un échantillon 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 de l'API:

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

ou

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

Il suffit de mettre en œuvre l'une des deux API répertoriées ci-dessus pour répondre aux exigences de stockage non volatile. L'API Flash met en œuvre un pilote de stockage Flash, tandis que l'API Settings fournit des fonctions pour une implémentation Flash sous-jacente à la couche supérieure.

Ces API sont exposées sur la couche supérieure:

  • Taille de stockage non volatile disponible utilisée pour stocker les données d'application (par exemple, ensemble de données opérationnel actif/en attente, paramètres réseau actuels et appareils de thread, identifiants pour le réassociation après réinitialisation)
  • Lire, écrire, effacer et interroger les opérations relatives à l'état de la mémoire Flash

Utilisez OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE dans le fichier de configuration principale de votre exemple de plate-forme pour indiquer l'API qu'elle doit utiliser. Si la valeur est 1, l'API Flash doit être mise en œuvre. Sinon, elle doit être implémentée.

Cette option doit être définie dans votre fichier /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.

Logging

Déclaration de l'API:

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

L'API Logging 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 n'avez pas l'intention d'utiliser la journalisation d'OpenThread's 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 de paquets brutes et consigne les lignes via le port série ou le terminal. Choisissez le niveau de débogage qui répond le mieux à vos besoins.

Spécifique au système

Déclaration de l'API:

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

L'API spécifique au système fournit principalement des opérations d'initialisation et de réinitialisation pour la plate-forme matérielle sélectionnée. Cette API n'est pas appelée par la bibliothèque OpenThread, mais peut être utile pour votre système/RTOS. Vous pouvez également intégrer l'initialisation d'autres modules (par exemple, UART, Radio, Random, Dix/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 mettre en œuvre cette API. Sinon, n'importe quelle API peut être implémentée pour intégrer les exemples de pilotes de plate-forme à votre système/conditions d'utilisation.