Build-Umgebung einrichten

<ph type="x-smartling-placeholder"></ph> Quelle auf GitHub ansehen

Von <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder"></ph> Mason Tran

Beitragender von SiLabs

Um die kostenlose und offene Entwicklung zu fördern, nutzt OpenThread CMake in der Build-Toolchain. Derzeit ist diese Toolchain für die Portierung erforderlich OpenThread zu einer neuen Hardwareplattform.

Andere Build-Toolchains werden möglicherweise in Zukunft unterstützt, befinden sich jedoch nicht im den Umfang dieses Leitfadens für die Rufnummernmitnahme.

Hinweis :Ersetzen Sie bei allen Pfaden und Codebeispielen in diesem Leitfaden zur Rufnummernmitnahme immer platform-name durch den Namen des neuen Plattformbeispiels. Die meisten in den Beispielen im Leitfaden wird ein efr32-Plattformname verwendet.

Neues Repository erstellen

Der erste Schritt besteht darin, ein neues Zuhause für Ihre Hardwareplattform einzurichten. In dieser Anleitung erstellen wir ein neues Repository mit dem Namen ot-efr32, das die Plattformabstraktionsebene, das SDK der Hardwareplattform und einige nützliche Skripts enthält.

Hinweis: Wenn Sie Ihr Repository in der OpenThread-Organisation hosten möchten, können Sie ein Problem posten, um ein neues Repository für Ihre Plattform anzufordern oder anzufordern, dass die OpenThread-Organisation Ihr vorhandenes Repository verzweigt.

In diesem Beispiel haben wir das Repository SiliconLabs/ot-efr32 auf GitHub erstellt und nach ~/repos/ot-efr32 geklont.

mkdir -p ~/repos
cd ~/repos
git clone [e-mail]:SiliconLabs/ot-efr32.git
Cloning into 'ot-efr32'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (60/60), done.
remote: Total 333 (delta 65), reused 39 (delta 39), pack-reused 234
Receiving objects: 100% (333/333), 170.78 KiB | 5.69 MiB/s, done.
Resolving deltas: 100% (194/194), done.
git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Repository-Struktur

Um die Konsistenz mit vorhandenen Plattform-Repositories in der OpenThread-GitHub-Organisation zu wahren, können Sie Ihr Repository so strukturieren:

tree -F -L 1 --dirsfirst
.
├── examples/
├── openthread/
├── script/
├── src/
├── third_party/
├── CMakeLists.txt
├── LICENSE
└── README.md

Ordner	Beschreibung
examples	optional Beispielanwendungen
openthread	Das openthread-Repository als Submodul
script	Skripts zum Erstellen, Testen und Linting
src	Implementierung der Plattformabstraktionsebene
third_party	Standort von Drittanbieterquellen

Untergeordnete Module hinzufügen

Fügen Sie im nächsten Schritt openthread und alle anderen erforderlichen Repositories als untergeordnete Module hinzu

git submodule add [e-mail]:openthread/openthread.git
Cloning into '/home/user/repos/ot-efr32/openthread'...
remote: Enumerating objects: 78281, done.
remote: Counting objects: 100% (1056/1056), done.
remote: Compressing objects: 100% (488/488), done.
remote: Total 78281 (delta 639), reused 864 (delta 556), pack-reused 77225
Receiving objects: 100% (78281/78281), 76.62 MiB | 35.24 MiB/s, done.
Resolving deltas: 100% (61292/61292), done.

Hinweis: Jeglicher nicht ursprünglicher abgeleiteter Code (z. B. Linker-Skript oder Toolchain-Startcode) muss im Verzeichnis third_party enthalten sein.

Für dieses Beispiel fügen wir eine Lite-Version des Silicon Labs Gecko SDK als Untermodul in third_party hinzu.

cd third_party
git submodule add [e-mail]:SiliconLabs/sdk_support.git
Cloning into '/home/user/repos/ot-efr32/third_party/sdk_support'...
remote: Enumerating objects: 32867, done.
remote: Counting objects: 100% (8181/8181), done.
remote: Compressing objects: 100% (3098/3098), done.
remote: Total 32867 (delta 4945), reused 7469 (delta 4732), pack-reused 24686
Receiving objects: 100% (32867/32867), 128.83 MiB | 30.91 MiB/s, done.
Resolving deltas: 100% (19797/19797), done.

Skripts

Um häufige Aufgaben zu erleichtern, können Sie einige Skripts im Ordner script erstellen. Dazu können Skripts für Aufgaben wie Bootstraping, Erstellen, Ausführen eines Code-Linters und ein Testskript für GitHub-CI-Prüfungen gehören.

Nachfolgend finden Sie einige Beispiele für Skripts, die für die meisten vorhandenen Plattform-Repositories Standard sind.

bootstrap

Dieses Skript sollte alle Tools und Pakete installieren, die für Ihre Hardwareplattform erforderlich sind. Außerdem sollte das Bootstrap-Skript von openthread ausgeführt werden, um sicherzustellen, dass der Nutzer alles hat, was zum Erstellen des OpenThread-Stacks erforderlich ist.

Ein Beispiel finden Sie im Bootstrap-Script in ot-efr32.

build

Das Build-Skript CMake sollte es Nutzern ermöglichen, den OpenThread-Stack für Ihre Plattform zu erstellen. Wenn in Ihrem Repository Beispielanwendungen definiert sind, sollten diese ebenfalls von diesem Skript erstellt werden. Dieses Skript sollte die grundlegenden Systemkonfigurationsoptionen enthalten, einschließlich plattformspezifischer Makrodefinitionen.

Ein Beispiel finden Sie im Build-Skript in ot-efr32.

test

Ein Testskript kann für Nutzer hilfreich sein, um Änderungen mithilfe definierter Tests zu testen. Das kann alles so einfache wie das Ausführen von Integritätsprüfungs-Builds oder komplizierte Methoden wie das Starten einer Unittest-Suite sein.

In ot-efr32 führt das Skript einfach das build-Skript für jedes unterstützte Board auf jeder der efr32-Plattformen aus.

Ein Beispiel finden Sie im Testskript in ot-efr32.

Hinweis: Dieses Skript ist zwar optional, aber einige der vorhandenen Plattform-Repositories, einschließlich ot-efr32, verwenden es als Teil der GitHub-CI-Prüfungen. Diese können so eingerichtet werden, dass gatekeep-Pull-Anfragen an main gesendet werden. Beispiel: ot-efr32#35

make-pretty

Um einen einheitlichen Stil zu gewährleisten, sollte dieses Skript Code, Skripts und Markdown-Dateien formatieren.

Sie können dieses Skript selbst definieren. Am einfachsten ist es jedoch, das Skript make-pretty zu verwenden, das bei vorhandenen Plattform-Repositories verwendet wird. Das Skript ruft die Stilskripte von openthread auf und sorgt für einen einheitlichen Stil in allen OpenThread-Repositories.

Hinweis: Wenn Sie Ihr Repository später in der OpenThread-Organisation hosten möchten, ist es erforderlich, dass Sie dieses Skript verwenden, um Pull-Anfragen im main-Zweig zu hosten. Ein Beispiel für das Hinzufügen dieser CI-Prüfung finden Sie hier.

Konfiguration des Verknüpfungsskripts

Skript GNU-Verknüpfung beschreibt, wie alle Abschnitte in den Eingabedateien (.o "object"-Dateien) zugeordnet werden die von der GNU Compiler Collection (GCC) generiert wurden, in die endgültige Ausgabedatei (für Beispiel: .elf). Außerdem wird der Speicherort jedes Segments eines Programm sowie die Eingabeadresse an. Die plattformspezifische Verknüpfung Das Skript wird häufig mit dem BSP der Plattform bereitgestellt.

Konfigurieren Sie das ld-Tool so, dass es auf das plattformspezifische Verknüpfungsskript verweist: target_link_libraries auf Ihrem Plattform-CMake-Ziel in src/CMakeLists.txt:

set(LD_FILE "${CMAKE_CURRENT_SOURCE_DIR}/efr32mg12.ld")

target_link_libraries(openthread-efr32mg12
    PRIVATE
        ot-config
    PUBLIC
        -T${LD_FILE}
        -Wl,--gc-sections -Wl,-Map=$.map
)

Toolchain-Startcode

Der Code für Start-ups der Plattform wird häufig zusammen mit dem BSP der Plattform bereitgestellt. Dieses Code in der Regel:

1. Implementiert die Eingabefunktion (Reset_Handler) des ausführbaren Programms
2. Definiert die Unterbrechungsvektortabelle
3. Initialisiert den Heap und den Stack
4. Kopiert den Abschnitt .data aus dem nichtflüchtigen Speicher in das RAM
5. Wechselt zur Hauptfunktion der Anwendung, um die Anwendungslogik auszuführen

Der Startcode (C- oder Assembly-Quellcode) muss im openthread-platform-name-Bibliothek, andernfalls einige Schlüsselvariablen, die in der Verknüpfung verwendet werden Skript kann nicht richtig zitiert werden:

• src/CMakeLists.txt

Beispiel: startup-gcc.c in ot-cc2538 – src/CMakeLists.txt

add_library(openthread-cc2538
    alarm.c
...
    startup-gcc.c
...
    system.c
    logging.c
    uart.c
    $
)