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 les éléments suivants:
- Interface d'alarme pour un minuteur autonome avec alarme
- Interfaces de bus (UART, SPI) pour communiquer des messages CLI et Spinel
- Interface radio pour la communication IEEE 802.15.4-2006
- Routines d'initialisation spécifiques au GCC
- Entropie pour la génération de nombres aléatoires
- Service de paramètres pour le stockage de la configuration non volatile
- Interface de journalisation pour l'envoi de messages de journal OpenThread
- Routines d'initialisation spécifiques au système
Toutes les API doivent être implémentées en fonction du package de compatibilité de compilation (BSP) de la couche d'abstraction matérielle (HAL).
Les fichiers d'API doivent être placés dans les répertoires suivants:
| Type | Annuaire |
|---|---|
| Implémentation de 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 |
| BSP 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 synchronisation et d'alarme de base pour l'implémentation du minuteur de la couche supérieure.
Il existe deux types de services d'alarme : milliseconde et microseconde. La milliseconde est requise 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 implémente la communication de base du port série via l'interface UART.
Bien que les modules complémentaires CLI et NCP OpenThread dépendent de l'interface UART pour interagir avec le côté 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 exemple de plate-forme matérielle, nous vous recommandons vivement de les prendre en charge pour plusieurs raisons:
- La CLI permet de vérifier que le port fonctionne correctement.
- L'outil d'automatisation du faisceau 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 CDC USB plutôt qu'un UART, assurez-vous de:
- Installer le pilote USB CDC approprié côté hôte
- Remplacez l'implémentation de l'API UART par le pilote USB CDC (avec le 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é basse consommation améliorée, OpenThread exige que toutes les plates-formes implémentent la mise en attente automatique des trames (transmission indirecte) par défaut. La table de correspondance des adresses sources doit également être implémentée dans le fichier source radio.h.
Toutefois, si votre nouvel exemple de plate-forme matérielle est limité en ressources, la table d'adresses source peut être définie comme ayant une longueur nulle. 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 permettant de réinitialiser le logiciel sur la puce et d'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 est 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é affectés par le TRNG incluent:
- Nonce AES-CCM
- Gigue retardée aléatoire
- Adresse étendue des appareils
- Période aléatoire initiale dans le minuteur de goutte à goutte
- ID de jeton/de message CoAP
Notez que de nombreuses plates-formes ont déjà intégré un générateur de nombres aléatoires, en exposant l'API dans son package BSP. Si la plate-forme matérielle cible n'est pas compatible avec le TRNG, envisagez d'utiliser l'échantillonnage du module ADC pour générer un nombre aléatoire à longueur fixe. Effectuez des échantillons sur plusieurs itérations si nécessaire pour répondre aux exigences du 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 d'API:
/openthread/include/openthread/platform/flash.h
ou
/openthread/include/openthread/platform/settings.h
Vous pouvez répondre à l'exigence de stockage non volatile en implémentant l'une des deux API listé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érations flash sous-jacentes à la couche supérieure.
Ces API exposent à 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 identifiants des appareils de thread pour le rattachement après la réinitialisation)
- Opérations de lecture, d'écriture, d'effacement et d'interrogation de l'état de la mémoire 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 la valeur est 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 fichier /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.
Journalisation
Déclaration de l'API:
/openthread/include/openthread/platform/logging.h
L'API Logging implémente les fonctionnalités 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 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 elle-même, mais elle 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.
L'implémentation de cette API dépend de votre cas d'utilisation. Si vous souhaitez utiliser les applications CLI et NCP générées pour une plate-forme exemple, vous devez implémenter cette API. Sinon, n'importe quelle API peut être implémentée pour intégrer les pilotes d'exemple de plate-forme à votre système/RTOS.