Condividi tramite


Recupero dell'output di debug del dispositivo Azure Sphere

Quando si sviluppa una soluzione IoT, spesso è necessario avere accesso per eseguire il debug dell'output dai dispositivi. Anche se questo può essere ottenuto tramite una connessione di debug a Visual Studio/Code (ma può essere ottenuto anche dalla riga di comando), potrebbe essere necessario visualizzare l'output di debug per i dispositivi non connessi a Visual Studio/Code. Tali dispositivi possono eseguire test a lungo termine o eventualmente anche distribuiti in produzione. Sono disponibili diverse opzioni per accedere ai dati di debug:

  • Recupero dell'output di debug da un dispositivo connesso a un PC di sviluppo
  • Recupero dell'output di debug per un dispositivo non connesso a un PC di sviluppo
  • Registrazione all'archiviazione esterna
  • Registrazione ad Azure

Recupero dell'output di debug da un dispositivo connesso a un PC di sviluppo

Problema: Come ottenere output di debug durante il debug con Visual Studio/Visual Code?

Opzioni:

  • Applicazione di alto livello

    Un'applicazione di alto livello Azure Sphere può usare l'API Log_Debug per inviare output di debug con la formattazione dello stile printf a un PC collegato durante il debug. Questo output può essere visualizzato tramite la finestra di debug di Visual Studio o Visual Studio Code oppure dalla riga di comando.

    È consigliabile impostare i flag di dettaglio di debug nell'applicazione e usare CMake compile definitions per controllare la quantità di output di debug visualizzata durante l'esecuzione dell'applicazione. Nel file CMakeLists.txt è possibile creare una definizione in fase di compilazione:

    add_compile_definitions(DEBUG_FLAG)

    Nel codice dell'applicazione di alto livello è quindi possibile aumentare o ridurre la quantità di output di debug visualizzata dall'applicazione utilizzando #ifdef, ad esempio:

    #ifdef DEBUG_FLAG
        Log_Debug("My Message\n");
    #endif
  • Applicazione in tempo reale

    Un'applicazione in tempo reale Azure Sphere (in esecuzione su uno dei core M4) può scrivere informazioni di debug/log in un UART dedicato solo alla trasmissione M4. Ciò richiede un adattatore USB/seriale, ad esempio FTDI Friend, e un emulatore di terminale.

    L'esempio di Hello World Azure Sphere illustra come stampare sull'oggetto UART di debug M4.

    Sono disponibili anche applicazioni di esempio da CodeThink e MediaTek:

    Le definizioni del flag di debug in fase di compilazione possono essere usate anche in applicazioni che supportno il tempo reale (M4).

  • Uso delle comunicazioni inter core per inviare lo stato da un'applicazione in tempo reale a un'applicazione di alto livello

    Se si crea un sistema che combina un'applicazione in grado di supportare l'alto livello e in tempo reale, è consigliabile usare l'applicazione di livello elevato per registrare lo stato del sistema per entrambe le applicazioni. A questo scopo è possibile usare comunicazioni inter core: l'esempio di comunicazione inter core Azure Sphere implementa una semplice interfaccia per il passaggio di un messaggio tra un'applicazione che supporta il livello elevato e in tempo reale.

    Questo modulo di apprendimento Azure Sphere illustra come usare Azure Sphere e Azure RTOS, combinati con un modello di messaggistica inter-core per passare messaggi personalizzati tra i core.

Recupero dell'output di debug per un dispositivo non connesso a un PC di sviluppo

Problema: Come registrare l'output di debug quando il dispositivo non è connesso a un PC di sviluppo?

Opzioni:

  • Inviare output di debug in rete o un oggetto UART

    Ottenere informazioni del log di debug quando un dispositivo è connesso a un PC di sviluppo è piuttosto semplice. Tuttavia, potresti voler raccogliere informazioni di debug/log anche quando un dispositivo non è connesso a un PC. Ad esempio, potresti avere un set di dispositivi che eseguono test a lungo termine.

    Se i dispositivi sono connessi a una rete, è consigliabile inviare l'output di debug tramite la rete a un'applicazione in grado di raccogliere e analizzare le informazioni. Questa applicazione Azure Sphere Gallery illustra come eseguire l'override del comportamento di Log_Debug predefinito per inviare e ricevere l'output su un socket UDP.

    Si noti che il meccanismo utilizzato per ignorare il comportamento predefinito high-evel applicazione Log_Debug può essere utilizzato anche per inviare le informazioni del log di debug ad altri luoghi, ad esempio, per l'output dei dati su uno degli UART Azure Sphere. È possibile usare questo esempio UART come riferimento da combinare con l'applicazione Raccolta UDPDebugLog per registrare i messaggi in un oggetto UART.

  • Invia output di debug a hub IoT di Azure/Azure IoT Central

    Anche se l'output di debug può essere utile per la diagnosi dei problemi in tempo reale, può anche essere utile archiviare informazioni di telemetria/log da un dispositivo per la post-elaborazione.

    La configurazione di un'istanza di hub IoT di Azure o Azure IoT Central fornisce un endpoint per l'invio di dati di telemetria dei dispositivi che possono essere usati come parte della logica di business, è anche possibile inviare informazioni sullo stato/log del dispositivo che possono essere trattate separatamente dalla telemetria/dati business.

    Nell'esempio Registrazione in Azure viene illustrato come inoltrare i messaggi di log come hub IoT telemetria e archiviarli in un cluster di azure Esplora dati per le query avanzate.

    • hub IoT di Azure

      L'istanza di hub IoT di Azure potrebbe essere configurata per l'invio di dati a un database di Azure per l'archiviazione/analisi, è anche possibile filtrare i messaggi, che possono essere ottenuti tramite EventHub e una funzione di Azure.

      Per hub IoT di Azure è possibile inviare dati a una funzione di Azure che può quindi elaborare i messaggi. Il trigger hub IoT di Azure per Funzioni di Azure articolo spiega come collegare una funzione di Azure a un'istanza di hub IoT di Azure.

    • Azure IoT Central

      Azure IoT Central include la possibilità di esportare continuamente i dati in vari endpoint, tra cui:

      • Hub eventi di Azure
      • Coda bus di servizio di Azure
      • bus di servizio di Azure argomento
      • Archiviazione BLOB di Azure
      • Webhook

      WebHook è un endpoint dell'API REST creato dall'utente, che potrebbe essere una funzione di Azure.

    Si noti che è possibile filtrare i messaggi nella funzione di Azure in base all'ID dispositivo che sta inviando i dati, è possibile ottenere l'ID dispositivo usando il codice seguente nella funzione di Azure:

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

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

hub IoT di Azure e Azure IoT Central supportano dispositivi gemelli, che includono lo stato desiderato (impostato nell'applicazione hub IoT/centrale) e lo stato segnalato (stato dal dispositivo). È possibile usare hub IoT di Azure/Central Device Twin per impostare lo stato desiderato per il livello di dettaglio dei dati di log (aumento/riduzione della frequenza di registrazione o ricchezza dei dati di registrazione). Nell'esempio IoT di Azure viene illustrato come gestire le modifiche device twinDesired State.

Registrazione dei dati nell'archiviazione

Azure Sphere supporta fino a 64 KB di memoria mutable per un'applicazione di alto livello, che può essere usata per mantenere impostazioni, stato dell'applicazione o altri dati, gli sviluppatori di applicazioni sono responsabili della serializzazione/deserializzazione dei dati in un archivio modificabile- La raccolta Azure Sphere include un progetto che illustra come usare una coppia chiave/valore (dizionario) per scrivere/leggere lo stato in una memoria mutable (fino a 64 KB a seconda di come è configurato il manifesto dell'applicazione).

È consigliabile scrivere più di 64 KB di dati di log/stato in una qualche forma di archiviazione esterna, questo può essere utile per i dispositivi con connettività intermittente o che devono archiviare/recuperare più di 64 KB di dati.

Un'opzione consiste nell'aggiungere spazio di archiviazione esterno, ad esempio usando SPI Flash per archiviare i dati: questo progetto usa SPI flash per archiviare un aggiornamento over-the-air per un dispositivo a valle e potrebbe essere modificato per supportare la telemetria di registrazione/dati di stato da un'applicazione Azure Sphere.