OpenThread ist Betriebssystem und Plattform-unabhängig und hat eine schmale Plattform-Abstraktionsebene (PAL). Diese PAL definiert:
- Weckeroberfläche für den aktiven Timer mit Wecker
- Busschnittstellen (UART, SPI) zur Kommunikation von CLI- und Spinel-Nachrichten
- Funkschnittstelle für Kommunikation nach IEEE 802.15.4-2006
- GCC-spezifische Initialisierungsroutinen
- Entropie zur Generierung von Zufallszahlen
- Einstellungsdienst für nichtflüchtigen Konfigurationsspeicher
- Logging-Oberfläche zum Senden von OpenThread-Lognachrichten
- Systemspezifische Initialisierungsroutinen
Alle APIs sollten auf der Grundlage des zugrunde liegenden Supportpakets für Hardware-Abstraktionsschicht (Hardware Abstraktion Layer, BSP) implementiert werden.
API-Dateien sollten sich in den folgenden Verzeichnissen befinden:
| Typ | Verzeichnis |
|---|---|
| Plattformspezifische PAL-Implementierung | /openthread/examples/platforms/platform-name |
| Header-Dateien – Persistent Storage API | /openthread/examples/platforms/utils |
| Alle anderen Header-Dateien | /openthread/include/openthread/platform |
| HAL-BSP | /openthread/third_party/platform-name |
Alarm
API-Deklaration:
/openthread/include/openthread/platform/alarm-milli.h
Die Alarm API bietet grundlegende Timing- und Alarmdienste für die Implementierung der Timerfunktion auf der oberen Ebene.
Es gibt zwei Arten von Weckerdiensten: Millisekunden und Mikrosekunden. Bei einer neuen Hardwareplattform ist Millisekunde erforderlich. Mikrosekunde ist optional.
UART
API-Deklaration:
/openthread/examples/platforms/utils/uart.h
Die UART API implementiert die grundlegende Kommunikation mit seriellen Ports über die UART-Schnittstelle.
Die CLI und NCP-Add-ons für OpenThread hängen von der UART-Schnittstelle ab, um mit der Hostseite zu interagieren. Die UART API-Unterstützung ist jedoch optional. Aber auch wenn Sie diese Add-ons nicht in Ihrem neuen Hardwareplattform-Beispiel verwenden möchten, empfehlen wir Ihnen dringend, die Unterstützung aus verschiedenen Gründen hinzuzufügen:
- Mit der Befehlszeile können Sie prüfen, ob der Port korrekt funktioniert
- Das Harness-Automatisierungstool nutzt die UART-Schnittstelle, um OpenThread für Test- und Zertifizierungszwecke zu steuern.
Wenn die Zielhardwareplattform ein USB-CDC-Modul anstelle von UART unterstützt, müssen Sie Folgendes tun:
- Den richtigen USB-CDC-Treiber auf der Hostseite installieren
- Ersetzen Sie die UART API-Implementierung mit dem USB-CDC-Treiber (zusammen mit BSP) auf der OpenThread-Seite und verwenden Sie dabei dieselben Funktionsprototypen.
Radio
API-Deklaration:
/openthread/include/openthread/platform/radio.h
Die Radio API definiert alle erforderlichen Funktionen, die in der oberen IEEE 802.15.4-MAC-Ebene aufgerufen werden. Der Funkchip muss vollständig mit der Spezifikation 2.4 GHz IEEE 802.15.4-2006 kompatibel sein.
Aufgrund der erweiterten Funktion mit geringem Stromverbrauch müssen alle Plattformen den automatischen Frame standardmäßig implementieren (indirekte Übertragung). Die Match-Table der Quelladresse sollte außerdem in der Quelldatei radio.h implementiert sein.
Wenn das neue Beispiel für eine Hardwareplattform Ressourcen hat, kann die Quelladresstabelle jedoch als Nulllänge definiert werden. Weitere Informationen finden Sie unter Automatischer Frame ausstehend.
Verschiedenes/zurücksetzen
API-Deklaration:
/openthread/include/openthread/platform/misc.h
Mit der Misc/Reset API können Sie die Software auf dem Chip zurücksetzen und den Grund für das letzte Zurücksetzen abfragen.
Entropie
API-Deklaration:
/openthread/include/openthread/platform/entropy.h
Die Entropy API bietet einen echten Zufallszahlengenerator (TRNG) für die obere Ebene, mit dem Sicherheits-Assets für das gesamte OpenThread-Netzwerk verwaltet werden. Die API sollte garantieren, dass für jeden Funktionsaufruf eine neue Zufallszahl generiert wird. Zu den von der TRNG betroffenen Sicherheits-Assets gehören:
- AES-CCM-Nonce
- Zufälliger Jitter
- Erweiterte Adresse des Geräts
- Anfänglicher zufälliger Zeitraum im Trick-Timer
- CoAP-Token-/Nachrichten-IDs
Beachten Sie, dass viele Plattformen bereits einen Zufallszahlengenerator integriert haben, der die API in ihrem BSP-Paket verfügbar macht. Wenn die Zielhardwareplattform TRNG nicht unterstützt, sollten Sie die Stichprobenerhebung für ADC-Module verwenden, um eine Zufallszahl mit fester Länge zu generieren. Stichprobe über mehrere Iterationen, wenn erforderlich, um die TRNG-Anforderungen (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 Hardwareentropie in der mbedTLS-Bibliothek bereitstellen.
Nichtflüchtiger Speicher
API-Deklarationen:
/openthread/include/openthread/platform/flash.h
oder
/openthread/include/openthread/platform/settings.h
Die Anforderung an nichtflüchtigen Speicher kann erfüllt werden, indem eine der beiden oben aufgeführten APIs implementiert wird. Die Flash API implementiert einen Flash-Speichertreiber, während die Settings API Funktionen für eine zugrunde liegende Flash-Vorgangsimplementierung auf der oberen Ebene bietet.
Diese APIs sind für die obere Ebene verfügbar:
- Die verfügbare nichtflüchtige Speichergröße, die zum Speichern von Anwendungsdaten verwendet wird (z. B. aktives/ausstehendes operatives Dataset, aktuelle Netzwerkparameter und Anmeldedaten des Threadgeräts für erneutes Anhängen nach dem Zurücksetzen).
- Flash-Statusvorgänge lesen, schreiben, löschen und abfragen
Verwenden Sie OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE in der zentralen Konfigurationsdatei 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 der Datei /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h festgelegt sein.
Logging
API-Deklaration:
/openthread/include/openthread/platform/logging.h
Die Logging API implementiert die Logging- und Debugging-Funktionen von OpenThread mit mehreren Fehlerbehebungsstufen. Diese API ist optional, wenn Sie nicht planen, das Logging von OpenThread auf Ihrer neuen Hardwareplattform zu verwenden.
Die höchste und detaillierteste Ebene ist OPENTHREAD_LOG_LEVEL_DEBG. Damit werden alle Rohpaketinformationen sowie alle Logzeilen über den seriellen Port oder das Terminal gedruckt. Wählen Sie eine Fehlerbehebungsstufe aus, die Ihren Anforderungen am besten entspricht.
Systemspezifisch
API-Deklaration:
/openthread/examples/platforms/openthread-system.h
Die systemspezifische API bietet in erster Linie Initialisierungs- und Deinitialisierungsvorgänge für die ausgewählte Hardwareplattform. Diese API wird nicht von der OpenThread-Bibliothek selbst aufgerufen, kann jedoch für Ihr System oder Ihre RTOS hilfreich sein. Sie können auch die Initialisierung anderer Module (z. B. UART, Radio, Random, Missc/Reset) in dieser Quelldatei implementieren.
Die Implementierung dieser API hängt von Ihrem Anwendungsfall ab. Wenn Sie die generierten CLI- 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 zu integrieren.