Freigeben über

Abrufen der Ausgabe des Azure Sphere-Gerätedebugs

  • Artikel

Beim Entwickeln einer IoT-Lösung benötigen Sie häufig Zugriff auf die Debugausgabe von Geräten. Dies kann zwar über eine Debugverbindung mit Visual Studio/Code erreicht werden (kann aber auch über die Befehlszeile erreicht werden), sie müssen jedoch 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 ausführen oder sogar in der Produktion bereitgestellt werden. Es gibt mehrere Optionen, um Zugriff auf Debugdaten zu erhalten:

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

Abrufen der Debugausgabe von einem Gerät, das mit einem Entwicklungs-PC verbunden ist

Problem: Wie kann beim Debuggen mit Visual Studio/Visual Code eine Debugausgabe abgerufen werden?

Optionen:

  • Allgemeine Anwendung

    Eine allgemeine Azure Sphere-Anwendung kann die Log_Debug-API verwenden, um während des Debuggens Debugausgaben mit printf-Formatierung an einen angefügten PC zu senden. Diese Ausgabe kann über das Debugfenster von Visual Studio oder Visual Studio Code oder über die Befehlszeile angezeigt werden.

    Möglicherweise sollten Sie in Betracht ziehen, ausführliche Debugflags in Ihrer Anwendung einzurichten und CMake-Kompilierungsdefinitionen zu verwenden, um zu steuern, wie viel Debugausgabe angezeigt wird, wenn Ihre Anwendung ausgeführt wird. In Ihrer CMakeLists.txt-Datei können Sie eine Kompilierzeitdefinition erstellen:

    add_compile_definitions(DEBUG_FLAG)

    In Ihrem allgemeinen Anwendungscode können Sie dann die Von Ihrer Anwendung angezeigte Debugausgabe erhöhen oder verringern, z #ifdef. B.:

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

  • Echtzeitfähige Anwendung

    Eine Azure Sphere-Echtzeitanwendung (die auf einem der M4-Kerne ausgeführt wird) kann Debug-/Protokollinformationen in einen dedizierten, nur übertragenen M4-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 der M4-Debug-UART drucken.

    Es gibt auch Beispielanwendungen von CodeThink und MediaTek:

    Debugflag-Kompilierzeitdefinitionen können auch in echtzeitfähigen (M4)-Anwendungen verwendet werden.

  • Verwenden der Kernkommunikation zum Senden des Zustands von einer Echtzeitanwendung an eine allgemeine Anwendung

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

    Dieses Azure Sphere-Lernmodul veranschaulicht die Verwendung von Azure Sphere und Azure RTOS in Kombination mit einem Kernmessagingmodell, 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 protokolliert man die Debugausgabe, wenn Ihr Gerät nicht mit einem Entwicklungs-PC verbunden ist?

Optionen:

  • Senden der Debugausgabe über das Netzwerk oder einen UART

    Das Abrufen von Debugprotokollinformationen, wenn ein Gerät mit einem Entwicklungs-PC verbunden ist, ist ziemlich einfach. Sie können 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, die Langzeittests ausführen.

    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-Kataloganwendung veranschaulicht, wie das Standardverhalten Log_Debug zum Senden und Empfangen dieser Ausgabe über einen UDP-Socket überschrieben wird.

    Beachten Sie, dass der Mechanismus, der verwendet wird, um die Standardanwendung für hohe Entwicklung Log_Debug Verhalten zu überschreiben, auch verwendet werden kann, um die Debugprotokollinformationen an andere Orte zu senden, z. B. um die Daten auf einem der Azure Sphere-UARTs auszugeben. Sie können dieses UART-Beispiel als Referenz für die Kombination mit der UDPDebugLog-Kataloganwendung verwenden, um Ihre Nachrichten in einem UART zu protokollieren.

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

    Während das Debuggen der Ausgabe nützlich sein kann, um Probleme zu diagnostizieren, wenn sie auftreten, kann es auch nützlich sein, Telemetrie-/Protokollinformationen von einem Gerät für die Nachbearbeitung zu speichern.

    Wenn Sie eine instance 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. Sie können auch Gerätestatus-/Protokollinformationen senden, die getrennt von den Telemetrie-/Geschäftsdaten behandelt werden können.

    • Azure IoT Hub

      Ihre Azure IoT Hub instance so konfiguriert werden, dass Daten zur Speicherung/Analyse an eine Azure-Datenbank gesendet werden. Möglicherweise möchten Sie auch die Nachrichten filtern, was über EventHub und eine Azure-Funktion erreicht werden kann.

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

    • Azure IoT Central

      Azure IoT Central bietet die Möglichkeit, Ihre Daten kontinuierlich an verschiedene Endpunkte zu exportieren, einschließlich:

      • 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 möglicherweise basierend auf der Geräte-ID filtern möchten, die die Daten sendet. Sie können die Geräte-ID mithilfe des folgenden Codes 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 Gerätezwillinge, einschließlich des gewünschten Zustands (festgelegt in der IoT Hub/Central-Anwendung) und des gemeldeten Zustands (Zustand vom Gerät). Sie können Azure IoT Hub/Zentraler Gerätezwilling 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). Im Azure IoT-Beispiel wird veranschaulicht, wie Änderungen an Gerätezwillys Desired State behandelt werden.

Protokollieren von Daten im Speicher

Azure Sphere unterstützt bis zu 64 KB änderbaren Speicher für eine allgemeine Anwendung. Dies kann zum Beibehalten von Einstellungen, Anwendungsstatus oder anderen Daten verwendet werden. Anwendungsentwickler sind für die Serialisierung/Deserialisierung von Daten in veränderlichen Speicher verantwortlich. Der Azure Sphere-Katalog enthält ein Projekt , das zeigt, wie ein Schlüssel-Wert-Paar (Wörterbuch) zum Schreiben/Lesen des Zustands im veränderlichen Speicher verwendet wird (je nach Konfiguration des Anwendungsmanifests bis zu 64 KB).

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

Eine Möglichkeit besteht darin, externen Speicher hinzuzufügen, z. B. die Verwendung von SPI-Flash zum Speichern der Daten. Dieses Projekt verwendet SPI-Flash, um ein Over-the-Air-Update für ein nachgeschaltetes Gerät zu speichern. Es kann geändert werden, um die Protokollierung von Telemetrie-/Zustandsdaten aus einer Azure Sphere-Anwendung zu unterstützen.