Teilen über

Lernprogramm: Erstellen und Debuggen von Partneranwendungen

  • Artikel

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

In diesem Lernprogramm wird gezeigt, wie Sie ein Beispielprojekt erstellen und debuggen, das sowohl eine high-level-Anwendung als auch eine Echtzeit-fähige Anwendung enthält, in der die beiden Apps zwischen dem high-level A7-Core und echtzeitbasiertem M4-Kern kommunizieren. Siehe Übersicht über Azure Sphere-Anwendungen für grundlegende Informationen zu high-level-Anwendungen und Echtzeit-fähigen Anwendungen.

In diesem Tutorial lernen Sie Folgendes:

  • Installieren der GNU Arm-Toolkette
  • Einrichten der Hardware zum Anzeigen der Ausgabe
  • Aktivieren der Entwicklung und des Debuggens
  • Klonen des Azure Sphere-Beispiel-Repositorys
  • Starten eines Terminalemulators zum Anzeigen der Ausgabe
  • Erstellen, Ausführen und Debuggen eines Paars von Partneranwendungen

Wichtig

Diese Anweisungen setzen voraus, dass Sie dem MT3620-Referenzboard-Design (RDB) entsprechende Hardware verwenden, z.B. das MT3620 Development Kit von Seeed Studios. Lesen Sie bei Verwendung einer anderen Azure Sphere-Hardware in der Dokumentation des Herstellers nach, ob diese den UART verfügbar macht und wie Sie darauf zugreifen können. Unter Umständen müssen Sie beim Einrichten der Hardware zum Anzeigen der Ausgabe anders vorgehen und den Beispielcode sowie das Feld „Uarts“ in der Datei „app_manifest.json“ aktualisieren, um einen anderen UART zu verwenden.

Voraussetzungen

Installieren Sie die in ARM eingebettete GNU-Toolkette.

  • Visual Studio 2022: Wenn Sie Visual Studio 2022 verwenden, installieren Sie die GNU Arm Embedded Toolchain (arm-none-eabi) von der Arm-Entwicklerwebsite.
  • Visual Studio 2019: Die Toolkette wird automatisch mit der Azure Sphere-Erweiterung für Visual Studio in Visual Studio 2019 installiert. Wenn Sie Visual Studio 2019 verwenden, fahren Sie mit der Einrichtung der Hardware fort, um die Ausgabe anzuzeigen. Wenn Sie jedoch die GNU Arm Embedded Toolchain manuell installiert haben, verwendet Visual Studio die version, die Sie installiert haben.

Um die Toolkette zu installieren, finden Sie auf der Arm-Entwicklerwebsite die GNU Arm Embedded Toolchain (arm-none-eabi), die den Compiler für den ARM Cortex-M4-Prozessor enthält. Befolgen Sie dort die Anweisungen, um den Compiler für Ihre Betriebssystemplattform herunterzuladen und zu installieren.

Standardmäßig sucht Visual Studio Code nach der Toolkette und sollte die installierte Version finden. Wenn Buildprobleme im Zusammenhang mit der Toolkette auftreten, überprüfen Sie Die Einstellungseinstellungen-Erweiterungen>>>AzureSphere, um sicherzustellen, dass "Azure Sphere: Arm Gnu Path" das Installationsverzeichnis der GNU Arm Embedded Toolchain identifiziert.

Einrichten der Hardware zum Anzeigen der Ausgabe

Aktuell unterstützt jeder Echtzeitkern einen reinen TX-UART. RTApps können über diesen UART die Protokollausgabe vom Gerät senden. Während der Anwendungsentwicklung und des Debuggens benötigen Sie normalerweise eine Möglichkeit zum Lesen und Anzeigen der Ausgabe. Das Beispiel „HelloWorld_RTApp_MT3620_BareMetal“ zeigt, wie eine Anwendung in den UART schreiben kann.

Verwenden Sie einen USB/Seriell-Adapter (z.B. FTDI Friend), um den UART des Echtzeitkerns mit einem USB-Anschluss Ihres Computers zu verbinden. Außerdem benötigen Sie einen Terminalemulator , um eine serielle Verbindung mit 115200-8-N-1-Terminaleinstellungen (115200 bps, 8 Bit, keine Paritätsbits, ein Stoppbit) herzustellen, um die Ausgabe anzuzeigen.

Führen Sie diese Schritte aus, um die Hardware zum Anzeigen der Ausgabe einer Echtzeitanwendung einzurichten. Informationen dazu, wo sich die Pins befinden, finden Sie in der Dokumentation des Herstellers Ihrer Hardware. Wenn Sie Hardware verwenden, die sich an dem MT3620-Referenzentwicklungsboard (RDB, Reference Development Board) orientiert (z. B. das MT3620-DevKit von Seeed Studio), finden Sie die Pins möglicherweise mithilfe der RDB-Schnittstellensockel.

  1. Verbinden Sie die GND-Schnittstelle des USB-Seriell-Adapters mit der GND-Schnittstelle Ihres DevKits. Bei MT3620-RDB-Hardware befindet sich die GND-Schnittstelle bei Pin 2 von Sockel 3.

  2. Verbinden Sie die RX-Schnittstelle des USB-Seriell-Adapters mit der IOM4-0 TX-Schnittstelle Ihres DevKits. Bei MT3620-RDB-Hardware befindet sich die IOM4-0 TX-Schnittstelle bei Pin 6 von Sockel 3.

  3. Schließen Sie den USB-zu-seriellen Adapter an einen kostenlosen USB-Anschluss auf Ihrem Entwicklungscomputer an, und bestimmen Sie, mit welchem Anschluss das serielle Gerät verbunden ist.

    • Starten Sie unter Windows Geräte-Manager, wählen Sie "Geräte nach Container anzeigen>" aus, und suchen Sie nach "USB UART". Beispielsweise gibt FT232R USB UART den FTDI Friend-Adapter an.

    • Geben Sie unter Linux den folgenden Befehl ein:

      dmesg | grep ttyUSB

      Der Port sollte den Namen „ttyUSBn“ haben. n steht dabei für die Portnummer. Wenn der dmesg Befehl mehrere USB-Anschlüsse auflistet, ist der mit dem in der Regel letzten angeschlossenen Anschluss verbunden. In den folgenden Beispielen würden Sie "ttyUSB4" verwenden:

    ~$ dmesg | grep ttyUSB
[  144.564350] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[  144.564768] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB1
[  144.565118] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB2
[  144.565593] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB3
[  144.570429] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB4
[  254.171871] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1

  4. Starten Sie ein Terminalemulatorprogramm, und öffnen Sie ein Terminal 115200-8-N-1 an den COM-Port, der vom Adapter verwendet wird. In der Dokumentation für den Terminal-Emulator erfahren Sie, wie Sie den Port und die Geschwindigkeit angeben.

Aktivieren der Entwicklung und des Debuggens

Bevor Sie eine Beispielanwendung auf Ihrem Azure Sphere-Gerät erstellen oder neue Anwendungen dafür entwickeln können, müssen Sie die Entwicklung und das Debuggen aktivieren. Standardmäßig sind Azure Sphere-Geräte „gesperrt“, d. h. sie erlauben nicht, dass Anwendungen, die sich in der Entwicklung befinden, von einem PC geladen werden, und sie erlauben kein Debuggen von Anwendungen. Durch die Vorbereitung des Geräts für das Debuggen wird diese Einschränkung aufgehoben und für das Debuggen erforderliche Software geladen, und die Gerätefunktionen werden wie unter Gerätefunktionen und Kommunikation beschrieben entsperrt.

Verwenden Sie zum Debuggen auf den Echtzeitkernen den Befehl "azsphere device enable-development ". Mit diesem Befehl wird das Gerät so konfiguriert, dass Anwendungen von einem PC zum Debuggen akzeptiert werden, und das Gerät der Gerätegruppe "Entwicklung" zugewiesen wird, die keine Cloudanwendungsupdates zulässt. Während der Anwendungsentwicklung und des Debuggens sollten Sie das Gerät in dieser Gruppe belassen, damit Cloudanwendungsupdates die Anwendung in der Entwicklungsphase nicht überschreiben.

Unter Windows müssen Sie den --enable-rt-core-debugging Parameter hinzufügen, der die Debugserver lädt und erforderliche Treiber für jeden Kerntyp auf dem Gerät benötigt.

  1. Melden Sie sich bei Azure Sphere an, wenn Sie dies noch nicht getan haben:

    azsphere login

  2. Öffnen Sie eine Befehlszeilenschnittstelle mit PowerShell oder Windows-Eingabeaufforderung mit Administratorrechten. Der --enable-rt-core-debugging Parameter erfordert Administratorrechte, da er USB-Treiber für den Debugger installiert.

  3. Geben Sie den folgenden Befehl ein:

    azsphere device enable-development --enable-rt-core-debugging

  4. Warten Sie, bis der Befehl ausgeführt wurde, und schließen Sie dann das Fenster, da die Administratorrechte nicht mehr benötigt werden. Es empfiehlt sich grundsätzlich, immer nur die niedrigsten Rechte zu verwenden, die zum Ausführen einer Aufgabe erforderlich sind.

Wenn der Azsphere-Gerätebefehl zur Aktivierung der Entwicklung fehlschlägt, lesen Sie die Problembehandlung von Azure Sphere-Problemen, um Hilfe zu erhalten.

Herunterladen der Beispielanwendung

Sie können die InterCore Communications-Anwendungen wie folgt herunterladen:

  1. Verweisen Sie Ihren Browser auf den Microsoft Samples-Browser.
  2. Geben Sie "Azure Sphere" in das Suchfeld ein.
  3. Wählen Sie Azure Sphere – Inter-core Communications aus den Suchergebnissen aus.
  4. Wählen Sie "ZIP herunterladen" aus.
  5. Öffnen Sie die heruntergeladene Datei, und extrahieren Sie sie in ein lokales Verzeichnis.

Erstellen und Ausführen der Partneranwendungen

  1. Starten Sie Visual Studio. Wählen Sie "Lokalen Ordner öffnen" aus, und navigieren Sie zu dem Ordner, in dem Sie die IntercoreComms-Anwendungen extrahiert haben.

    Wichtig

    Wenn Sie Visual Studio 2022, Version 17.1 oder höher, verwenden und das IntercoreComms-Beispiel vor der 22.02 Azure Sphere-Version extrahiert haben, müssen Sie ihrem Projektordner auf oberster Ebene eine CMakeWorkspaceSettings.json Datei hinzufügen.

  2. Wenn Sie kein MT3620 RDB verwenden, aktualisieren Sie die app_manifest.json Dateien sowohl für Anwendungen als auch für die Hardwaredefinitionsdatei und CMakeLists.txt Datei für die High-Level-Anwendung so, dass sie ihrer Hardware entsprechen.

  3. Sollte die CMake-Generierung nicht automatisch gestartet werden, wählen Sie die Datei „CMakeLists.txt“ aus.

  4. In Visual Studio sollte die Ausgabe "Ausgabe>anzeigen>von: CMake"-Ausgabe die Nachrichten CMake generation started und .CMake generation finished

  5. Wählen Sie "Build alle erstellen>" aus. Wenn das Menü nicht vorhanden ist, öffnen Sie Projektmappen-Explorer, klicken Sie mit der rechten Maustaste auf die CMakeLists.txt Datei, und wählen Sie "Erstellen" aus. Die Ausgabeposition der IntercoreComms_HL & IntercoreComms RT-Anwendungen werden im Ausgabefenster angezeigt.

  6. Wählen Sie "IntercoreComms für Startelement>auswählen" (Alle Kerne) aus.

  7. Wählen Sie "Debuggen debuggen"> aus, oder drücken Sie F5, um die Anwendungen bereitzustellen und zu debuggen.

  8. Wählen Sie im Ausgabefenster im Menü "Ausgabe auswählen" die Option "Geräteausgabe" aus. Das Ausgabefenster sollte die allgemeine Anwendungsausgabe anzeigen:

    Remote debugging from host 192.168.35.1, port 58817
High-level intercore comms application
Sends data to, and receives data from a real-time capable application.
Received 19 bytes: rt-app-to-hl-app-07
Sending: hl-app-to-rt-app-00
Sending: hl-app-to-rt-app-01

  9. Der verbundene Terminalemulator sollte die Ausgabe des Echtzeit-fähigen Programms anzeigen:

    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
Text: hl-app-to-rt-app-00
Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:31
Text: hl-app-to-rt-app-01

  10. Verwenden Sie den Debugger zum Festlegen von Breakpoints, Überprüfen von Variablen und Ausführen anderer Debugaufgaben.

  1. Öffnen Sie in Visual Studio Code den Ordner, in dem Sie die IntercoreComms-Anwendungen extrahiert haben. Visual Studio Code erkennt die Datei "intercore.code-workspace" und fragt, ob Sie den Arbeitsbereich öffnen möchten. Wählen Sie "Arbeitsbereich öffnen", um die Anwendung in Echtzeit und die allgemeine Anwendung gleichzeitig zu öffnen.

  2. Wenn Sie kein MT3620 RDB verwenden, aktualisieren Sie die app_manifest.json Dateien sowohl für Anwendungen als auch für die Hardwaredefinitionsdatei und CMakeLists.txt Datei für die High-Level-Anwendung so, dass sie ihrer Hardware entsprechen.

  3. Drücken Sie F5, um den Debugger zu starten. Wenn das Projekt vorher noch nicht erstellt wurde oder sich Dateien geändert haben und eine erneute Erstellung erforderlich ist, wird das Projekt von Visual Studio Code vor Beginn des Debugvorgangs erstellt.

  4. Im Fenster für die Azure Sphere-Ausgabe sollte „Deploying image...“ (Bild wird bereitgestellt...) gefolgt von den Pfaden zum SDK und Compiler angezeigt werden.

  5. Das Ausgabefenster sollte die allgemeine Anwendungsausgabe anzeigen:

    Remote debugging from host 192.168.35.1, port 58817
High-level intercore comms application
Sends data to, and receives data from a real-time capable application.
Received 19 bytes: rt-app-to-hl-app-07
Sending: hl-app-to-rt-app-00
Sending: hl-app-to-rt-app-01

  6. Der verbundene Terminalemulator sollte die Ausgabe des Echtzeit-fähigen Programms anzeigen:

    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
Text: hl-app-to-rt-app-00
Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:31
Text: hl-app-to-rt-app-01

  7. Verwenden Sie die Debugfeatures von Visual Studio Code zum Festlegen von Breakpoints, Überprüfen von Variablen und Ausführen anderer Debugaufgaben.

Problembehandlung

Die Ausführung der Anwendung beginnt möglicherweise, bevor von OpenOCD eine Verbindung hergestellt wurde. Dies kann dazu führen, dass Breakpoints am Anfang des Codes nicht beachtet werden. Dieses Problem lässt sich ganz einfach umgehen, indem der Start der App so lange verzögert wird, bis von OpenOCD eine Verbindung hergestellt wird.

  1. Fügen Sie am Anfang des Anwendungseinstiegspunkts „RTCoreMain“ den folgenden Code ein. Dadurch wird die Anwendung in eine while-Schleife versetzt, bis die Variable f den Wert true hat.

    static _Noreturn void RTCoreMain(void)
{
  .
  .
  .
 volatile bool f = false;
 while (!f) {
    // empty.
 }
  .
  .
  .
}

  2. Drücken Sie F5, um die App mit dem Debuggen zu starten und dann in die Ausführung einzubrechen.

  3. Ändern Sie im Debugbereich "Lokal" den Wert von f Null in 1.

  4. Durchlaufen Sie den Code wie gewohnt.

Beim Erstellen mit der CLI erstellen Und bereitstellen Sie zuerst die Echtzeitfähige Anwendung, erstellen und bereitstellen dann die high-level-Anwendung.

Erstellen und Bereitstellen der echtzeitfähigen Anwendung

  1. Navigieren Sie zu dem Ordner, in dem Sie die IntercoreComms-Anwendungen extrahiert haben, und wählen Sie dann den Ordner "IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal" aus.

  2. Öffnen Sie die datei app_manifest.json, und stellen Sie sicher, dass die Komponenten-ID der allgemeinen App in der AllowedApplicationConnections-Funktion angezeigt wird.

  3. Öffnen Sie eine Befehlszeilenschnittstelle mit PowerShell, Windows-Eingabeaufforderung oder Linux-Befehlsshell. Navigieren Sie zu Ihrem Projektbuildverzeichnis.

  4. Führen Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung CMake mit den folgenden Parametern aus:

    cmake --preset <preset-name> <source-path>

    • --preset <preset-name>

      Der voreingestellte Buildkonfigurationsname gemäß der Definition in CMakePresets.json.

    • --build <cmake-path>

      Das Binärverzeichnis, das den CMake-Cache enthält. Wenn Sie beispielsweise CMake in einem Azure Sphere-Beispiel ausführen, lautet cmake --build out/ARM-Debugder Buildbefehl .

    • <source-path>

      Der Pfad des Verzeichnisses, das die Quelldateien für die Beispielanwendung enthält. Im Beispiel wurde das Azure Sphere-Beispielrepository in ein Verzeichnis namens AzSphere heruntergeladen.

      CMake-Parameter werden mit Leerzeichen voneinander getrennt. Das Zeilenfortsetzungszeichen (^ für windows-Befehlszeile, \ für Linux-Befehlszeile oder ' für PowerShell) kann zur Lesbarkeit verwendet werden, ist jedoch nicht erforderlich.

    Die folgenden Beispiele zeigen die CMake-Befehle für die IntercoreComms RTApp:

    Windows-Eingabeaufforderung

     cmake ^
--preset "ARM-Debug" ^
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"

    Windows PowerShell

     cmake `
--preset "ARM-Debug" `
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"

  5. Führen Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung Ninja aus, um die Anwendung zu erstellen und die Bildpaketdatei zu erstellen.

    ninja -C out/ARM-Debug

    Ninja platziert die resultierenden Anwendungs- und IMAGEpackage-Dateien im angegebenen Verzeichnis.

    Sie können Ninja auch über CMake mit dem folgenden Befehl aufrufen:

    cmake --build out/<binary-dir>

    Legen Sie diesen Wert <binary-dir> auf das Binärverzeichnis fest, das den CMake-Cache enthält. Wenn Sie beispielsweise CMake in einem Azure Sphere-Beispiel ausführen, lautet cmake --build out/ARM-Debugder Buildbefehl .

    Löschen Sie bei der Problembehandlung Ihren gesamten Build, und wiederholen Sie den Vorgang – vor allem nach dem Vornehmen von Änderungen an Ihren CMake-Befehlen.

  6. Löschen Sie alle Anwendungen, die auf dem Gerät schon bereitgestellt wurden:

    azsphere device sideload delete

  7. Laden Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung das von Ninja erstellte Bildpaket:

    azsphere device sideload deploy --image-package <path-to-imagepackage>

    Die Anwendung wird bald nach dem Laden ausgeführt.

  8. Rufen Sie die Komponenten-ID für das Image ab:

    azsphere image-package show --image-package <path-to-imagepackage>

    Der Befehl gibt alle Metadaten für das Imagepaket zurück. Die Komponenten-ID für die Anwendung wird im Abschnitt „Identität“ für den Anwendungsimagetyp angezeigt. Zum Beispiel:

    Image package metadata:
Section: Identity
Image Type:           Application
Component ID:         <component id>
Image ID:             <image id>

Erstellen und Bereitstellen der allgemeinen Anwendung

  1. Navigieren Sie zu dem Ordner, in dem Sie die IntercoreComms-Anwendungen extrahiert haben, und wählen Sie dann den Ordner "IntercoreComms/IntercoreComms_HighLevelApp" aus.

  2. Öffnen Sie die app_manifest.json Datei, und stellen Sie sicher, dass die Komponenten-ID der RTApp in der AllowedApplicationConnections-Funktion angezeigt wird.

  3. Öffnen Sie eine Befehlszeilenschnittstelle mit PowerShell, Windows-Eingabeaufforderung oder Linux-Befehlsshell. Navigieren Sie zu Ihrem Projektbuildverzeichnis.

  4. Führen Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung CMake mit den folgenden Parametern aus:

    cmake --preset <preset-name> <source-path>

    • --preset <preset-name>

      Der voreingestellte Buildkonfigurationsname gemäß der Definition in CMakePresets.json.

    • --build <cmake-path>

      Das Binärverzeichnis, das den CMake-Cache enthält. Wenn Sie beispielsweise CMake in einem Azure Sphere-Beispiel ausführen, lautet cmake --build out/ARM-Debugder Buildbefehl .

    • <source-path>

      Der Pfad des Verzeichnisses, das die Quelldateien für die Beispielanwendung enthält. Im Beispiel wurde das Azure Sphere-Beispielrepository in ein Verzeichnis namens AzSphere heruntergeladen.

      CMake-Parameter werden mit Leerzeichen voneinander getrennt. Das Zeilenfortsetzungszeichen (^ für windows-Befehlszeile, \ für Linux-Befehlszeile oder ' für PowerShell) kann zur Lesbarkeit verwendet werden, ist jedoch nicht erforderlich.

    Die folgenden Beispiele zeigen die CMake-Befehle für die High-Level-Anwendung intercoreComms.

    Windows-Eingabeaufforderung

     cmake ^
 --preset "ARM-Debug" ^
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"

    Windows PowerShell

     cmake `
 --preset "ARM-Debug" `
 "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"

  5. Führen Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung Ninja aus, um die Anwendung zu erstellen und die Bildpaketdatei zu erstellen.

    ninja -C out/ARM-Debug

    Ninja platziert die resultierenden Anwendungs- und IMAGEpackage-Dateien im angegebenen Verzeichnis.

    Sie können Ninja auch über CMake mit dem folgenden Befehl aufrufen:

    cmake --build out/<binary-dir>

    Legen Sie diesen Wert <binary-dir> auf das Binärverzeichnis fest, das den CMake-Cache enthält. Wenn Sie beispielsweise CMake in einem Azure Sphere-Beispiel ausführen, lautet cmake --build out/ARM-Debugder Buildbefehl .

    Löschen Sie bei der Problembehandlung Ihren gesamten Build, und wiederholen Sie den Vorgang – vor allem nach dem Vornehmen von Änderungen an Ihren CMake-Befehlen.

  6. Laden Sie in Ihrem Projektbuildverzeichnis an der Eingabeaufforderung das von Ninja erstellte Bildpaket:

    azsphere device sideload deploy --image-package <package-name>

    Die Anwendung wird bald nach dem Laden ausgeführt.

  7. Rufen Sie die Komponenten-ID für das Image ab:

    azsphere image-package show --image-package <path-to-imagepackage>

    Der Befehl gibt alle Metadaten für das Imagepaket zurück. Die Komponenten-ID für die Anwendung wird im Abschnitt „Identität“ für den Anwendungsimagetyp angezeigt. Zum Beispiel:

    Image package metadata:
  Section: Identity
    Image Type:           Application
    Component ID:         <component id>
    Image ID:             <image id>

Ausführen der Partneranwendungen mit aktivierter Debugging

  1. Beenden Sie die Echtzeitanwendung, wenn sie ausgeführt wird.

    azsphere device app stop --component-id <component id>

  2. Starten Sie die Anwendung für das Debuggen erneut.

    azsphere device app start --component-id <component id>

    Mit diesem Befehl wird der Kern zurückgegeben, in dem die Anwendung ausgeführt wird.

      <component id>
  App state: running
  Core        : Real-time 0

  3. Navigieren Sie zum Ordner „Openocd“ für den Systemstamm (sysroot), mit dem die Anwendung erstellt wurde. Die sysroot-Verzeichnisse werden im Azure Sphere SDK-Installationsordner installiert. Für Windows wird der Ordner beispielsweise standardmäßig unter C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd und für Linux unter /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux installiert.

  4. Führen Sie openocd wie im folgenden Beispiel gezeigt aus. Im Beispiel wird davon ausgegangen, dass die App auf Kern 0 ausgeführt wird. Wenn die App auf Kern 1 ausgeführt wird, ersetzen Sie „targets io0“ durch „targets io1“.

       openocd -f mt3620-rdb-ftdi.cfg -f mt3620-io0.cfg -c "gdb_memory_map disable" -c "gdb_breakpoint_override hard" -c init -c "targets io0" -c halt -c "targets"

  5. Öffnen Sie eine neue Azure Sphere-Eingabeaufforderung (Windows Azure Sphere Classic CLI), eine Standard-Eingabeaufforderung oder eine PowerShell (Windows Azure Sphere CLI) oder ein Terminalfenster (Linux).

  6. Navigieren Sie zu dem Ordner, der die Echtzeit-fähige Anwendungs-OUT-Datei enthält, und starten arm-none-eabi-gdbSie sie, die Teil der GNU Arm Embedded Toolchain ist:

    Windows-Eingabeaufforderung

    "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out

    Windows PowerShell

     & "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out

  7. Der OpenOCD-Server stellt unter „:4444“ eine GDB-Serverschnittstelle bereit. Legen Sie das Debugziel fest.

    target remote :4444

  8. Sie können jetzt gdb-Befehle für die Echtzeit-fähige Anwendung ausführen. Fügen Sie einen Haltepunkt an der Funktion HandleSendTimerDeferred hinzu:

    break HandleSendTimerDeferred

  9. Der verbundene Terminalemulator sollte die Ausgabe der Echtzeit-fähigen Anwendung anzeigen.

  10. Öffnen Sie eine neue Azure Sphere-Eingabeaufforderung (Windows Azure Sphere Classic CLI), eine Standard-Eingabeaufforderung oder eine PowerShell (Windows Azure Sphere CLI) oder ein Terminalfenster (Linux).

  11. Navigieren Sie zu dem Ordner, der die Imagepackage-Datei auf oberster Ebene enthält.

  12. Beenden Sie die allgemeine Anwendung, wenn sie ausgeführt wird.

    azsphere device app stop --component-id <component id>

  13. Starten Sie die allgemeine Anwendung mit dem Debuggen erneut.

    azsphere device app start --component-id <component id> --debug-mode

  14. Öffnen Sie einen Terminalemulator , und richten Sie eine Telnet- oder TCP-Verbindung mit 192.168.35.2 am Port 2342 ein, um die Ausgabe der App auf hoher Ebene anzuzeigen.

  15. Starten Sie gdb mit dem folgenden Befehl:

    Windows-Eingabeaufforderung

    "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out

    Windows PowerShell

    & "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out

    Hinweis

    Das Azure Sphere SDK wird mit mehreren Sysroots ausgeliefert, sodass Anwendungen auf unterschiedliche API-Sätze abzielen können, wie in der Anwendungslaufzeitversion, sysroots und Beta-APIs beschrieben. Die sysroot-Verzeichnisse werden im Azure Sphere SDK-Installationsordner unter Sysroots installiert.

  16. Legen Sie das Remotedebuggingziel auf IP-Adresse 192.168.35.2 für Port 2345 fest:

    target remote 192.168.35.2:2345

  17. Fügen Sie einen Haltepunkt an der Funktion SendMessageToRTApp hinzu:

    break SendMessageToRTApp

  18. Geben Sie c den Vorgang ein, beobachten Sie die Ausgabe in Ihrem Telnet/TCP-Terminal, und wechseln Sie dann zum Eingabeaufforderungs- oder Terminalfenster, das Ihre Echtzeitanwendungsdebuggingsitzung enthält.

  19. Geben Sie c die Eingabe ein, um die Ausgabe in Ihrer verbundenen seriellen Sitzung fortzusetzen und zu beobachten.

Sie können zwischen Debugsitzungen hin und her arbeiten und zwischen der Echtzeit-fähigen Anwendung und der allgemeinen Anwendung wechseln. In den beiden Ausgabefenstern sollte die Ausgabe ähnlich wie folgt angezeigt werden:

Starting debugger....
                     Process /mnt/apps/25025d2c-66da-4448-bae1-ac26fcdd3627/bin/app created; pid = 40
                     Listening on port 2345
                                           Remote debugging from host 192.168.35.1, port 56522
              High-level intercore comms application
                                                    Sends data to, and receives data from a real-time capable application.
                                          Sending: hl-app-to-rt-app-00
                                                                      Sending: hl-app-to-rt-app-01

IntercoreComms_RTApp_MT3620_BareMetal
App built on: Nov 17 2020, 09:25:19
Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
Text: hl-app-to-rt-app-00

Geben Sie an der GDB-Eingabeaufforderung ein, q um jede Debugsitzung zu beenden.

Nächste Schritte