APIs für die Abstraktionsschicht implementieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Quelle auf GitHub ansehen

OpenThread ist plattform- und plattformunabhängig und hat eine enge Plattform-Abstraktionsebene (PAL). Diese PAL definiert Folgendes:

Portierungsarchitektur
  • Weckeroberfläche für den Kostenlos-Timer mit Wecker
  • Busschnittstellen (UART, SPI) für die Kommunikation von CLI- und Spinel-Nachrichten
  • Funkschnittstelle für Kommunikation nach IEEE 802.15.4-2006
  • GCC-spezifische Initialisierungsroutinen
  • Entropie für die Generierung von zufälligen Zahlen
  • Einstellungsdienst für nichtflüchtigen Konfigurationsspeicher
  • Logging-Oberfläche für die Zustellung von OpenThread-Lognachrichten
  • Systemspezifische Routinen zur Initialisierung

Alle APIs sollten auf der Grundlage des zugrunde liegenden Build-Support-Pakets (BSP) für Hardware-Abstraktionsschicht (HAL) implementiert werden.

API-Dateien sollten sich in den folgenden Verzeichnissen befinden:

Typ Verzeichnis
Plattformspezifische PAL-Implementierung /openthread/examples/platforms/platform-name
Headerdateien – API für nichtflüchtige Speicher /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 Weckerdienste für den Timer mit der höheren Ebene.

Es gibt zwei Arten von Weckerdiensten: Millisekunden und Mikrosekunden. Für eine neue Hardwareplattform ist eine Millisekunde erforderlich. Mikrosekunden ist optional.

UART

API-Deklaration:

/openthread/examples/platforms/utils/uart.h

Die UART API implementiert eine grundlegende Kommunikation mit dem seriellen Port ü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. Selbst wenn Sie diese Add-ons nicht für das neue Beispiel der Hardwareplattform verwenden möchten, empfehlen wir Ihnen dringend, den Support aus folgenden Gründen zu unterstützen:

  • Über die Befehlszeile können Sie prüfen, ob der Port richtig funktioniert
  • Das Haring Automation Tool nutzt die UART-Schnittstelle, um OpenThread zu Testzwecken und zur Zertifizierung zu steuern.

Wenn die Zielhardwareplattform ein USB-CDC-Modul anstelle von UART unterstützt, müssen Sie Folgendes tun:

  • Installieren Sie den korrekten USB-CDC-Treiber auf der Hostseite.
  • Ersetzen Sie die UART API-Implementierung durch den USB-CDC-Treiber (zusammen mit dem BSP) auf der OpenThread-Seite, indem Sie dieselben Funktionsprototypen verwenden.

Radio

API-Deklaration:

/openthread/include/openthread/platform/radio.h

Die Radio API definiert alle erforderlichen Funktionen, die von der oberen IEEE 802.15.4-MAC-Ebene aufgerufen werden. Der Radiochip muss der Spezifikation 2,4 GHz IEEE 802.15.4–2006 vollständig entsprechen.

Aufgrund der verbesserten Niedrig-Leistungs-Funktion muss OpenThread standardmäßig alle automatischen Frames (indirekte Übertragung) mit einem automatischen Frame implementieren und die Match-Table der Quelladresse sollte auch in der Quelldatei radio.h implementiert werden.

Wenn jedoch das neue Beispiel der Hardwareplattform auf Ressourcen beschränkt ist, kann die Quelladresstabelle 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 Zufallsgenerator (TRNG) für die obere Ebene, mit dem Sicherheits-Assets für das gesamte OpenThread-Netzwerk verwaltet werden. Die API sollte sicherstellen, dass für jeden Funktionsaufruf eine neue Zufallszahl generiert wird. Vom TRNG betroffene Sicherheits-Assets:

  • AES-CCM-Nonce
  • Zufällig verzögerter Jitter
  • Geräte & erweiterte Adresse
  • Der anfängliche Zufallszeitraum im Trickzeit-Timer
  • CoAP-Token/Nachrichten-IDs

Viele Plattformen haben einen Zufallszahlengenerator bereits integriert, sodass die API im BSP-Paket verfügbar ist. Wenn die Zielhardwareplattform TRNG nicht unterstützt, solltest du ADC-Modul-Sampling verwenden, um eine Zufallszahl mit fester Länge zu generieren. Stichproben über mehrere Iterationen nach Bedarf, 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 zur Verfügung stellen.

Nichtflüchtiger Speicher

API-Deklarationen:

/openthread/include/openthread/platform/flash.h

oder

/openthread/include/openthread/platform/settings.h

Der nichtflüchtige Speicher muss erfüllt sein, indem eine der beiden oben aufgeführten APIs implementiert wird. Die Flash API implementiert einen Flash Storage-Treiber, während die Settings API Funktionen für eine zugrunde liegende Flash-Vorgangs-Implementierung auf der oberen Ebene bietet.

Diese APIs werden für die oberste Ebene bereitgestellt:

  • Die verfügbare nichtflüchtige Speichergröße, die zum Speichern von Anwendungsdaten verwendet wird (z. B. aktive/ausstehendes operatives Dataset, aktuelle Netzwerkparameter und Thread-Geräte; Anmeldedaten für das erneute Hinzufügen nach dem Zurücksetzen)
  • Flash-Statusvorgänge lesen, schreiben, löschen und abfragen

Verwenden Sie OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE in Ihrer zentrale Konfigurationsdatei für die Plattform, 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 werden.

Logging

API-Deklaration:

/openthread/include/openthread/platform/logging.h

Die Logging API implementiert die Logging- und Debug-Funktionen von OpenThread mit mehreren Ebenen der Debugging-Ausgabe. Diese API ist optional, wenn Sie nicht planen, OpenLogging-Logging auf Ihrem neuen Beispiel für Hardwareplattform zu verwenden.

Die höchste und detaillierteste Ebene ist OPENTHREAD_LOG_LEVEL_DEBG. Dabei werden alle Rohpaketinformationen und -zeilen über den seriellen Port oder am 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 vor allem Initialisierung- und Deaktivierungsvorgänge für die ausgewählte Hardwareplattform an. Diese API wird nicht von der OpenThread-Bibliothek selbst aufgerufen, kann aber für Ihr System oder Ihre RTOS hilfreich sein. In dieser Quelldatei können Sie außerdem die Initialisierung anderer Module implementieren (z. B. UART, Radio, Zufallsmix, Sonstiges/Zurücksetzen).

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 bzw. Ihre RTOS zu integrieren.