APIs zur Abstraktionsplattform implementieren

Quelle auf GitHub ansehen

OpenThread ist betriebssystem- und plattformunabhängig mit einer engen Plattform-Abstraktionsschicht (PAL). Diese PAL definiert:

Portierungsarchitektur
  • Alarmoberfläche für kostenlosen Timer mit Wecker
  • Busschnittstellen (UART, SPI) für die Kommunikation von Befehlszeilen- und Spinel-Nachrichten
  • Funkschnittstelle für die Kommunikation gemäß IEEE 802.15.4-2006
  • GCC-spezifische Initialisierungsroutinen
  • Entropie für die Erzeugung zufälliger Zahlen
  • Einstellungsdienst für nichtflüchtigen Konfigurationsspeicher
  • Logging-Oberfläche zum Senden von OpenThread-Lognachrichten
  • Systemspezifische Initialisierungsroutinen

Alle APIs sollten auf Basis des zugrunde liegenden Hardware-Abstraktionsschicht-Builds (HAL – Build Support Package, BSP) erstellt 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-Deklaration:

/openthread/include/openthread/platform/alarm-milli.h

Die Alarm API bietet grundlegende Zeit- und Alarmdienste für die Timerimplementierung auf der oberen Ebene.

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

UART

API-Deklaration:

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

Die UART API implementiert die grundlegende Kommunikation mit dem seriellen Port über die UART-Schnittstelle.

Während die Add-ons für OpenThread CLI und NCP von der UART-Schnittstelle abhängen, um mit der Hostseite zu interagieren, unterstützt die UART API ist optional. Selbst wenn Sie diese Add-ons nicht in Ihrem neuen Beispiel für Ihre Hardwareplattform verwenden möchten, empfehlen wir Ihnen dringend, die folgenden Gründe zu verwenden:

  • Mit der Befehlszeile können Sie prüfen, ob der Port ordnungsgemäß funktioniert.
  • Das Harness Automation Tool verwendet die UART-Schnittstelle, um OpenThread für Test- und Zertifizierungszwecke zu steuern

Wenn die Zielhardwareplattform ein USB-CDC-Modul anstelle von UART unterstützt, achten Sie auf Folgendes:

  • Den richtigen USB-CDC-Treiber auf der Hostseite installieren
  • Ersetzen Sie die UART API-Implementierung durch den 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 von 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 Energieversorgung erfordert OpenThread, dass auf allen Plattformen standardmäßig automatische Frames (indirekte Übertragung) implementiert werden. Außerdem muss die Match-Table der Quelladresse ebenfalls in der Quelldatei radio.h implementiert sein.

Wenn Ihr neues Hardwareplattformbeispiel jedoch ressourcenbeschränkt ist, kann die Quelladresstabelle mit null Länge definiert werden. Weitere Informationen finden Sie unter Automatischer Frame ausstehend.

Sonstiges/Zurücksetzen

API-Deklaration:

/openthread/include/openthread/platform/misc.h

Die Misc/Reset API bietet eine Methode, um die Software auf dem Chip zurückzusetzen und den Grund für das letzte Zurücksetzen abzufragen.

Entropie

API-Deklaration:

/openthread/include/openthread/platform/entropy.h

Die Entropy API bietet einen True-Number-Generator (TRNG) für die obere Ebene, 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 vom TRNG betroffenen Sicherheitsassets gehören:

  • AES-CCM-Nonce
  • Zufälliger verzögerter Jitter
  • Erweiterte Adresse des Geräts
  • Anfänglicher Zufallszeitraum im Trickle-Timer
  • CoAP-Token/Nachrichten-IDs

Beachten Sie, dass viele Plattformen bereits einen Zufallszahlengenerator eingebunden haben, um die API in ihrem BSP-Paket verfügbar zu machen. Falls die Zielhardwareplattform TRNG nicht unterstützt, können Sie ADC-Modulproben verwenden, um eine Zufallszahl mit fester Länge zu generieren. Verwenden Sie bei Bedarf mehrere Stichproben, 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 zur Generierung der Hardwareentropie bereitstellen, die in der mbedTLS-Bibliothek verwendet wird.

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 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 die zugrunde liegende Flash-Vorgangsimplementierung auf der oberen Ebene bietet.

Diese APIs bieten der obersten Ebene:

  • Die verfügbare, nichtflüchtige Speichergröße, die zum Speichern von Anwendungsdaten verwendet wird (z. B. aktives/ausstehendes Betriebs-Dataset, aktuelle Netzwerkparameter und Anmeldedaten von Thread-Geräten zum erneuten Anhängen nach dem Zurücksetzen)
  • Vorgänge zum Lesen, Schreiben, Löschen und Abfragen von Flash-Status

Geben Sie in der Kernkonfigurationsdatei Ihres Plattformbeispiels OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE an, um festzulegen, 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 Fehlerbehebungsfunktionen von OpenThread mit mehreren Ebenen zur Fehlerbehebung. Diese API ist optional, wenn Sie das Logging von OpenThread auf Ihrem neuen Hardwareplattformbeispiel nicht verwenden möchten.

Die höchste und detaillierteste Ebene ist OPENTHREAD_LOG_LEVEL_DEBG, die alle Rohpaketinformationen und Protokollzeilen über den seriellen Port oder auf dem Terminal ausgibt. Wählen Sie eine Debug-Ebene 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 aber für Ihr System bzw. Ihre RTOS nützlich sein. Sie können auch die Initialisierung anderer Module (z. B. UART, Radio, Zufall, Sonstiges/Zurücksetzen) 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 eine beliebige API implementiert werden, um die Beispielplattformtreiber in Ihr System/Ihre RTOS zu integrieren.