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.