Teilen über

Abrufen der Debugausgabe des Azure Sphere-Geräts

  • 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.

Beim Entwickeln einer IoT-Lösung benötigen Sie häufig Zugriff auf das Debuggen der Ausgabe von Geräten. Dies kann zwar über eine Debugverbindung mit Visual Studio/Code erreicht werden (aber auch über die Befehlszeile erreicht werden), sie müssen möglicherweise auch die Debugausgabe für Geräte anzeigen, die nicht mit Visual Studio/Code verbunden sind. Solche Geräte können langfristige Tests durchführen oder sogar in der Produktion bereitgestellt werden. Es gibt mehrere Optionen für den Zugriff auf das Debuggen von Daten:

  • Abrufen der Debugausgabe eines Geräts, das mit einem Entwicklungs-PC verbunden ist
  • Abrufen der Debugausgabe für ein Gerät, das nicht mit einem Entwicklungs-PC verbunden ist
  • Protokollierung beim externen Speicher
  • Protokollierung bei Azure

Abrufen der Debugausgabe eines Geräts, das mit einem Entwicklungs-PC verbunden ist

Problem: Wie erhalte ich beim Debuggen mit Visual Studio/Visual Code Debugausgabe?

Optionen:

  • Allgemeine Anwendung

    Eine allgemeine Azure Sphere-Anwendung kann die Log_Debug-API verwenden, um die Debugausgabe mit der Formatierung des Printf-Stils während des Debuggings an einen angefügten PC zu senden. Diese Ausgabe kann mit Visual Studio oder Visual Studio Code-Debugfenster oder über die Befehlszeile angezeigt werden.

    Möglicherweise möchten Sie das Einrichten von Debug-Ausführlichkeitskennzeichnungen in Ihrer Anwendung und die Verwendung von CMake-Kompilierungsdefinitionen in Betracht ziehen, um zu steuern, wie viel Debugausgabe angezeigt wird, wenn die Anwendung ausgeführt wird. In Ihrer CMakeLists.txt Datei können Sie eine Kompilierungszeitdefinition erstellen:

    add_compile_definitions(DEBUG_FLAG)

    In Ihrem allgemeinen Anwendungscode können Sie dann die von Der Anwendung #ifdefangezeigte Debugausgabe erhöhen oder verkleinern, z. B.:

    #ifdef DEBUG_FLAG
        Log_Debug("My Message\n");
    #endif

  • Echtzeitfähige Anwendung

    Eine Echtzeit-fähige Azure Sphere-Anwendung (ausgeführt auf einem der M4-Kerne) kann Debug-/Protokollinformationen in eine dedizierte M4-Übertragungs-UART schreiben. Dies erfordert einen USB-/seriellen Adapter wie einen FTDI Friend und einen Terminalemulator.

    Das Azure Sphere Hallo Welt-Beispiel veranschaulicht, wie sie in das M4-Debug-UART-Objekt gedruckt werden.

    Es gibt auch Beispielanwendungen, die über CodeThink und MediaTek verfügbar sind:

    Debugkennzeichnungskompilierungszeitdefinitionen können auch in Echtzeitfähigen (M4)-Anwendungen verwendet werden.

  • Verwenden von Inter-Core-Kommunikation zum Senden des Zustands von einer Echtzeit-fähigen Anwendung an eine high-level-Anwendung

    Wenn Sie ein System erstellen, das eine high-level- und echtzeitfähige Anwendung kombiniert, sollten Sie die allgemeine Anwendung verwenden, um den Systemstatus für beide Anwendungen zu protokollieren. Die Inter-Core-Kommunikation kann dazu verwendet werden – das Azure Sphere Inter-Core Communication-Beispiel implementiert eine einfache Schnittstelle zum Übergeben einer Nachricht zwischen einer high-level- und Echtzeit-fähigen Anwendung.

    Dieses Azure Sphere-Lernmodul veranschaulicht, wie Sie Azure Sphere und Azure RTOS verwenden, kombiniert mit einem Inter-Core-Messaging-Modell, um benutzerdefinierte Nachrichten zwischen den Kernen zu übergeben.

Abrufen der Debugausgabe für ein Gerät, das nicht mit einem Entwicklungs-PC verbunden ist

Problem: Wie protokollieren Sie die Debugausgabe, wenn Ihr Gerät nicht mit einem Entwicklungs-PC verbunden ist?

Optionen:

  • Senden der Debugausgabe über das Netzwerk oder eine UART

    Das Abrufen von Debugprotokollinformationen, wenn ein Gerät mit einem Entwicklungs-PC verbunden ist, ist ziemlich einfach. Möglicherweise möchten Sie jedoch auch Debug-/Protokollinformationen sammeln, wenn ein Gerät nicht mit einem PC verbunden ist. Beispielsweise können Sie über eine Reihe von Geräten verfügen, auf denen langfristige Tests ausgeführt werden.

    Wenn Ihre Geräte mit einem Netzwerk verbunden sind, sollten Sie die Debugausgabe über das Netzwerk an eine Anwendung senden, die die Informationen sammeln und analysieren kann. Diese Azure Sphere Gallery-Anwendung veranschaulicht, wie sie das standardverhalten Log_Debug zum Senden und Empfangen dieser Ausgabe über einen UDP-Socket außer Kraft setzen.

    Beachten Sie, dass der Mechanismus, der zum Überschreiben der Standardanwendung mit hoher Abgeschrägung Log_Debug Verhalten verwendet wird, auch verwendet werden kann, um die Debugprotokollinformationen an andere Stellen zu senden, z. B. zum Ausgeben der Daten in einem der Azure Sphere-UARTs. Sie können dieses UART-Beispiel als Verweis verwenden, um mit der UDPDebugLog Gallery-Anwendung zu kombinieren, um Ihre Nachrichten bei einer UART zu protokollieren.

  • Senden der Debugausgabe an Azure IoT Hub/Azure IoT Central

    Während das Debuggen der Ausgabe hilfreich sein kann, um Probleme während der Nachbearbeitung zu diagnostizieren, kann es auch hilfreich sein, Telemetrie-/Protokollinformationen von einem Gerät zur Nachbearbeitung zu speichern.

    Wenn Sie eine Instanz von Azure IoT Hub oder Azure IoT Central einrichten, erhalten Sie einen Endpunkt zum Senden von Gerätetelemetriedaten, die als Teil Ihrer Geschäftslogik verwendet werden können, können Sie auch Gerätestatus-/Protokollinformationen senden, die separat von den Telemetrie-/Geschäftsdaten behandelt werden können.

    • Azure IoT Hub

      Ihre Azure IoT Hub-Instanz könnte so konfiguriert werden, dass Daten zur Speicher-/Analyse an eine Azure-Datenbank gesendet werden, Sie können auch die Nachrichten filtern, die über EventHub und eine Azure-Funktion erreicht werden können.

      Für Azure IoT Hub können Sie Daten an eine Azure-Funktion senden, die dann die Nachrichten verarbeiten kann. Der Azure IoT Hub-Trigger für Azure Functions erläutert, wie Sie eine Azure-Funktion mit einer Azure IoT Hub-Instanz verknüpfen.

    • Azure IoT Central

      Azure IoT Central umfasst die Möglichkeit, Ihre Daten kontinuierlich in verschiedene Endpunkte zu exportieren, darunter:

      • Azure Event Hubs
      • Azure Service Bus-Warteschlange
      • Azure Service Bus-Thema
      • Azure Blob Storage
      • Webhook

      Der WebHook ist ein von Ihnen erstellter REST-API-Endpunkt, dies kann eine Azure-Funktion sein.

    Beachten Sie, dass Sie Nachrichten in Ihrer Azure-Funktion basierend auf der Geräte-ID, die die Daten sendet, filtern möchten, können Sie die Geräte-ID mit dem folgenden Code in der Azure-Funktion abrufen:

    public static async Task Run(EventData message, ILogger log)
    {
        var deviceId=message.SystemProperties["iothub-connection-device-id"];

        // Code to filter the messages goes here...
    }

Azure IoT Hub und Azure IoT Central unterstützen Device Twins, die den gewünschten Zustand (in der IoT Hub/Central-Anwendung festgelegt) und den gemeldeten Zustand (Zustand vom Gerät) umfassen. Sie können Azure IoT Hub/Central Device Twin verwenden, um einen gewünschten Zustand für die Ausführlichkeit von Protokolldaten festzulegen (Protokollierungshäufigkeit erhöhen/verringern oder die Fülle der Protokollierungsdaten). Das Azure IoT-Beispiel veranschaulicht, wie Device Twin-Änderungen Desired State behandelt werden.

Protokollieren von Zu speichernden Daten

Azure Sphere unterstützt bis zu 64 KB veränderbaren Speicher für eine anwendung auf hoher Ebene, dies kann verwendet werden, um Einstellungen, Anwendungsstatus oder andere Daten zu speichern, Anwendungsentwickler sind für die Serialisierung/Deserialisierung von Daten zum veränderbaren Speicher verantwortlich – Der Azure Sphere-Katalog enthält ein Projekt , das zeigt, wie sie ein Schlüssel-Wert-Paar (Wörterbuch) zum Schreiben/Lesen des Zustands zum stummschaltbaren Speicher verwenden (bis zu 64 KB, je nachdem, wie das Anwendungsmanifest konfiguriert ist).

Möglicherweise möchten Sie mehr als 64 KB Protokoll-/Zustandsdaten in eine Form von externem Speicher schreiben, dies kann für Geräte mit zeitweiliger Konnektivität nützlich sein oder mehr als 64 KB Daten speichern/abrufen müssen.

Eine Möglichkeit besteht darin, externen Speicher hinzuzufügen, z. B. mithilfe von SPI Flash zum Speichern der Daten – dieses Projekt verwendet SPI Flash zum Speichern eines Over-the-Air-Updates für ein nachgeschaltetes Gerät und könnte geändert werden, um die Protokollierung von Telemetrie-/Zustandsdaten aus einer Azure Sphere-Anwendung zu unterstützen.