Mettre en œuvre les API Platform Abstraction Layer

Afficher la source sur GitHub

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

Architecture de transfert
  • Interface d'alarme du minuteur en libre-service avec alarme
  • Interfaces de bus (UART, SPI) pour la communication de messages CLI et Spinel
  • Interface radio pour la communication IEEE 802.15.4-2006
  • Routines d'initialisation spécifiques à GCC
  • Entropie d'un nombre réel de nombres aléatoires
  • Service Paramètres pour le stockage de 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 de la formule BSP (Hardware Abstraction Layer) sous-jacente.

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

Type Annuaire
Mise en œuvre du PAL spécifique à la plate-forme /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 de l'API:

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

L'API Alarm fournit des services essentiels de minutage et d'alarme pour la mise en œuvre de minuteurs de couche supérieure.

Il existe deux types de services d'alarme : milliseconde et microseconde. Veuillez indiquer la Milliseconde 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 fondamentale 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 le côté hôte, l'API UART est compatible est facultatif. Toutefois, 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 compatibilité pour plusieurs raisons:

  • La CLI permet de 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 USB-CDC plutôt qu'avec UART, assurez-vous de procéder comme suit:

  • Installez le bon pilote USB CDC du côté hôte
  • Remplacez l'implémentation de l'API UART par le pilote USB-CDC (avec BSP) côté 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 IEEE 802.15.4 supérieure. La puce radio doit être entièrement conforme à la spécification IEEE 802.15.4-2006 2,4 GHz.

En raison de sa fonctionnalité d'amélioration de l'alimentation, OpenThread nécessite que toutes les plates-formes mettent en œuvre le cadrage automatique en attente (transmission indirecte) par défaut et le tableau de correspondance d'adresse source doit également être mis en œuvre dans le fichier source radio.h.

Toutefois, si votre nouvel exemple de plate-forme matérielle est à ressources limitées, la table d'adresses source peut être définie sur zéro longueur. Pour plus d'informations, consultez 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 de la puce et interroger le motif 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, qui permet de gérer les éléments de sécurité pour l'ensemble du réseau OpenThread. L'API doit garantir la génération d'un nouveau nombre aléatoire pour chaque appel de fonction. Les éléments de sécurité affectés par le TRNG incluent:

  • Nonce CCM AES
  • Gigue retardée
  • Adresse étendue des appareils
  • La période aléatoire initiale dans le minuteur d'analyse
  • ID des jetons/messages 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. Si la plate-forme matérielle cible n'est pas compatible avec TRNG, envisagez d'utiliser l'échantillonnage de 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 de la fonction TRNG (uint32_t).

Lorsque la macro MBEDTLS_ENTROPY_HARDWARE_ALT est définie sur 1, cette API doit également fournir une méthode permettant de 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

L'une des deux API répertoriées ci-dessus permet de satisfaire l'exigence 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 mise en œuvre d'opération Flash sous-jacente sur la couche supérieure.

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

  • Taille de stockage non volatile disponible permettant de stocker les données de l'application (par exemple, l'ensemble de données opérationnel actif/en attente, les paramètres réseau actuels et les identifiants des appareils en fils de discussion pour la réassociation après la réinitialisation).
  • Lire, écrire, effacer et interroger les opérations d'état Flash

Utilisez OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE dans le fichier de configuration principal de votre exemple de plate-forme pour indiquer l'API que la plate-forme doit utiliser. Si défini sur 1, l'API Flash doit être mise en œuvre. Sinon, l'API Settings doit être mise en œuvre.

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 met en œuvre 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 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 affiche toutes les informations brutes sur les paquets et consigne les lignes via le port série ou sur 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 désinitialisation 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/RTO. Vous pouvez également mettre en œuvre l'initialisation d'autres modules (par exemple, UART, Radio, Shuffle, 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 de CLI et NCP générées pour un exemple de plate-forme, vous devez mettre en œuvre cette API. Sinon, vous pouvez mettre en œuvre n'importe quelle API pour intégrer les exemples de pilotes de plate-forme dans votre système/RTO.