Afficher le code 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:
- Interface d'alarme pour minuteur avec exécution libre 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 d'un nombre aléatoire réel
- 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 pour la compilation matérielle avec couche d'abstraction matérielle (HAL).
Les fichiers d'API doivent être placés dans les répertoires suivants:
| Type | Annuaire |
|---|---|
| Implémentation d'une 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 |
| 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 durée et d'alarme intermédiaire pour la mise en œuvre du retardateur de 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 met en œuvre la communication de base sur le port série via l'interface UART.
Alors que les modules complémentaires CLI et NCP d'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 sur votre nouvel exemple de plate-forme matérielle, nous vous recommandons vivement d'ajouter cette 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 que UART, veillez à:
- Installer 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) 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 supérieure de la norme IEEE 802.15.4. Elle doit être entièrement conforme à la spécification 2,4 GHz IEEE 802.15.4-2006.
En raison de sa fonctionnalité basse consommation améliorée, OpenThread oblige toutes les plates-formes à implémenter le cadre 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.
Toutefois, si votre nouvel exemple de plate-forme matérielle est limité en ressources, la table d'adresses source peut être définie sur 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 pour réinitialiser le logiciel de 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, 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. Voici les assets de sécurité affectés par le TRNG:
- Nonce CCM AES
- Gigue retardée aléatoire
- Adresse étendue des appareils
- Période aléatoire initiale dans le délai d'attente
- 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. 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 l'échantillonnage 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
L'une des deux API répertoriées ci-dessus peut répondre aux besoins de stockage non volatiles. L'API Flash implémente 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 dans la couche supérieure:
- Taille de l'espace 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 la réassociation après la réinitialisation)
- Lire, écrire, effacer et interroger des 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. Si elle est définie sur 1, l'API Flash doit être implémentée. Sinon, l'API Settings doit être implémentée.
Cette option doit être définie dans le 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 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. Il affiche toutes les informations sur les paquets bruts et consigne les lignes dans le port série ou sur le terminal. Choisissez le niveau de débogage qui correspond 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 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 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.
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 mise en œuvre pour intégrer les exemples de pilotes de plate-forme à votre système/vos RTOS.