OpenThread ist ein Betriebssystem- und plattformunabhängiges Protokoll mit einer schmalen Plattformabstraktionsschicht (PAL). Diese PAL definiert:
- Weckerschnittstelle für einen laufzeitabhängigen Timer mit Wecker
- Busschnittstellen (UART, SPI) für die Kommunikation von Befehlszeilen- und Spinel-Nachrichten
- Funkschnittstelle für die Kommunikation nach IEEE 802.15.4-2006
- GCC-spezifische Initialisierungsroutinen
- Entropie für die Generierung echter Zufallszahlen
- Einstellungsdienst für nichtflüchtigen Konfigurationsspeicher
- Logging-Oberfläche für die Übermittlung von OpenThread-Lognachrichten
- Systemspezifische Initialisierungsroutinen
Alle APIs sollten basierend auf dem zugrunde liegenden Build-Supportpaket (BSP) der Hardware Abstraction Layer (HAL) implementiert werden.
API-Dateien sollten in den folgenden Verzeichnissen abgelegt werden:
| Typ | Verzeichnis |
|---|---|
| Plattformspezifische PAL-Implementierung | /openthread/examples/platforms/platform-name |
| Headerdateien – API für nichtflüchtigen Speicher | /openthread/examples/platforms/utils |
| Alle anderen Headerdateien | /openthread/include/openthread/platform |
| HAL BSP | /openthread/third_party/platform-name |
Wecker
API-Erklärung:
/openthread/include/openthread/platform/alarm-milli.h
Die Alarm API bietet grundlegende Zeit- und Weckerdienste für die Timerimplementierung der oberen Schicht.
Es gibt zwei Arten von Weckerdiensten: Millisekunden und Mikrosekunden. Millisekunden sind für eine neue Hardwareplattform erforderlich. Mikrosekunden sind optional.
UART
API-Erklärung:
/openthread/examples/platforms/utils/uart.h
Die UART API implementiert die grundlegende serielle Portkommunikation über die UART-Schnittstelle.
Während die OpenThread-CLI und die NCP-Add-ons für die Interaktion mit der Hostseite auf die UART-Schnittstelle angewiesen sind, ist die Unterstützung der UART API optional. Auch wenn Sie diese Add-ons in Ihrem Beispiel für die neue Hardwareplattform nicht verwenden möchten, empfehlen wir Ihnen aus folgenden Gründen dringend, die Unterstützung hinzuzufügen:
- Mit der Befehlszeile können Sie prüfen, ob der Anschluss richtig funktioniert.
- Das Harness Automation Tool verwendet die UART-Schnittstelle, um OpenThread zu Test- und Zertifizierungszwecken zu steuern.
Wenn die Zielhardwareplattform kein UART, sondern ein USB-CDC-Modul unterstützt, müssen Sie Folgendes beachten:
- Den richtigen USB-CDC-Treiber auf der Hostseite installieren
- Ersetzen Sie die UART API-Implementierung durch den USB CDC-Treiber (zusammen mit dem BSP) auf der OpenThread-Seite und verwenden Sie dabei dieselben Funktionsprototypen.
Radio
API-Erklärung:
/openthread/include/openthread/platform/radio.h
Die Radio API definiert alle erforderlichen Funktionen, die von der oberen MAC-Schicht (IEEE 802.15.4) aufgerufen werden. Der Funkchip muss vollständig der 2,4‑GHz-Spezifikation IEEE 802.15.4-2006 entsprechen.
Aufgrund der erweiterten Energiesparfunktion von OpenThread müssen alle Plattformen standardmäßig die Funktion „Auto Frame Pending“ (indirekte Übertragung) implementieren. Außerdem sollte die Tabelle für die Übereinstimmung der Quelladresse in der radio.h-Quelldatei implementiert werden.
Wenn Ihre neue Hardwareplattform jedoch ressourcenbeschränkt ist, kann die Quelladresstabelle mit einer Länge von null definiert werden. Weitere Informationen finden Sie unter Auto Frame Pending.
Sonstiges/Zurücksetzen
API-Erklärung:
/openthread/include/openthread/platform/misc.h
Die Misc/Reset API bietet eine Methode zum Zurücksetzen der Software auf dem Chip und zum Abfragen des Grundes für das letzte Zurücksetzen.
Entropie
API-Erklärung:
/openthread/include/openthread/platform/entropy.h
Die Entropy API bietet einen echten Zufallszahlengenerator (TRNG) für die obere Schicht, mit dem Sicherheits-Assets für das gesamte OpenThread-Netzwerk verwaltet werden. Die API sollte dafür sorgen, dass für jeden Funktionsaufruf eine neue Zufallszahl generiert wird. Zu den Sicherheits-Assets, die vom TRNG betroffen sind, gehören:
- AES CCM-Nonce
- Zufällig verzögerter Jitter
- Erweiterte Adresse der Geräte
- Die anfängliche zufällige Zeitspanne im Timer für die schrittweise Auslieferung
- CoAP-Token-/Nachrichten-IDs
Viele Plattformen haben bereits einen Zufallszahlengenerator integriert und stellen die API in ihrem BSP-Paket bereit. Wenn die Zielhardwareplattform TRNG nicht unterstützt, können Sie die ADC-Modul-Stichprobenerhebung verwenden, um eine Zufallszahl mit fester Länge zu generieren. Wenn erforderlich, mehrere Iterationen erfassen, um die Anforderungen an die TRNG (uint32_t) zu erfüllen.
Wenn das Makro MBEDTLS_ENTROPY_HARDWARE_ALT auf 1 gesetzt ist, sollte diese API auch eine Methode zum Generieren der Hardware-Entropie bereitstellen, die in der mbedTLS-Bibliothek verwendet wird.
Nichtflüchtiger Speicher
API-Erklärungen:
/openthread/include/openthread/platform/flash.h
oder
/openthread/include/openthread/platform/settings.h
Die Anforderung an nichtflüchtigen Speicher kann durch Implementierung einer der beiden oben aufgeführten APIs erfüllt werden. Die Flash API implementiert einen Flash-Speichertreiber, während die Settings API Funktionen für eine zugrunde liegende Flash-Bedienungsimplementierung für die obere Schicht bereitstellt.
Diese APIs stellen der oberen Schicht Folgendes zur Verfügung:
- Die verfügbare Größe des nichtflüchtigen Speichers, die zum Speichern von Anwendungsdaten verwendet wird (z. B. aktiver/ausstehender Betriebsdatensatz, aktuelle Netzwerkparameter und Anmeldedaten von Thread-Geräten für die erneute Verknüpfung nach dem Zurücksetzen)
- Lese-, Schreib-, Lösch- und Abfragevorgänge für den Flash-Status
Verwenden Sie OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE in der Hauptkonfigurationsdatei Ihres Plattformbeispiels, um anzugeben, welche API die Plattform verwenden soll. Wenn 1 festgelegt ist, muss die Flash API implementiert sein. Andernfalls muss die Settings API implementiert werden.
Dieses Flag muss in Ihrer /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h-Datei festgelegt sein.
Logging
API-Erklärung:
/openthread/include/openthread/platform/logging.h
Die Logging API implementiert die Logging- und Debug-Funktionen von OpenThread. Es stehen mehrere Debug-Ausgabeebenen zur Verfügung. Diese API ist optional, wenn Sie die Protokollierung von OpenThread auf Ihrer neuen Hardwareplattform nicht verwenden möchten.
Die höchste und detaillierteste Ebene ist OPENTHREAD_LOG_LEVEL_DEBG. Hier werden alle Rohpaketinformationen ausgegeben und Zeilen über den seriellen Anschluss oder das Terminal protokolliert. Wählen Sie die Debug-Ebene aus, die Ihren Anforderungen am besten entspricht.
Systemspezifisch
API-Erklärung:
/openthread/examples/platforms/openthread-system.h
Die systemspezifische API bietet hauptsächlich Initialisierungs- und Deinitialisierungsvorgänge für die ausgewählte Hardwareplattform. Diese API wird nicht von der OpenThread-Bibliothek selbst aufgerufen, kann aber für Ihr System/RTOS nützlich sein. Sie können auch die Initialisierung anderer Module (z. B. UART, Radio, Random, Misc/Reset) in dieser Quelldatei implementieren.
Die Implementierung dieser API hängt von Ihrem Anwendungsfall ab. Wenn Sie die generierten Befehlszeilen- und NCP-Anwendungen für eine Beispielplattform verwenden möchten, müssen Sie diese API implementieren. Andernfalls kann jede API implementiert werden, um die Beispielplattformtreiber in Ihr System/RTOS einzubinden.