Dela via

Hämta azure sphere-utdata för enhetsfelsökning

  • Artikel

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

När du utvecklar en IoT-lösning måste du ofta ha åtkomst till felsökning av utdata från enheter. Även om detta kan uppnås genom en felsökningsanslutning till Visual Studio/Code (men kan också uppnås från kommandoraden), kan du också behöva visa felsökningsutdata för enheter som inte är anslutna till Visual Studio/Code. Sådana enheter kan köra långsiktiga tester, eller kanske till och med distribueras till produktion. Det finns flera alternativ för att få åtkomst till felsökningsdata:

  • Hämta felsökningsutdata från en enhet som är ansluten till en utvecklingsdator
  • Hämta felsökningsutdata för en enhet som inte är ansluten till en utvecklingsdator
  • Loggning till extern lagring
  • Logga till Azure

Hämta felsökningsutdata från en enhet som är ansluten till en utvecklingsdator

Problem: Hur hämtar du felsökningsutdata vid felsökning med Hjälp av Visual Studio/Visual Code?

Alternativ:

  • Högnivåprogram

    Ett högnivåprogram i Azure Sphere kan använda Log_Debug-API:et för att skicka felsökningsutdata med formatering av utskriftsformat till en ansluten dator under felsökningen. Dessa utdata kan visas med hjälp av felsökningsfönstret i Visual Studio eller Visual Studio Code , eller från kommandoraden.

    Du kanske vill överväga att konfigurera felsökningsflaggor i ditt program och använda CMake-kompileringsdefinitioner för att styra hur mycket felsökningsutdata som visas när programmet körs. I din CMakeLists.txt-fil kan du skapa en kompileringstidsdefinition:

    add_compile_definitions(DEBUG_FLAG)

    I din programkod på hög nivå kan du sedan öka eller minska mängden felsökningsutdata som visas av ditt program med hjälp #ifdefav , till exempel:

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

  • Realtidskompatibelt program

    Ett Realtidskompatibelt Azure Sphere-program (som körs på en av M4-kärnorna) kan skriva felsöknings-/logginformation till en dedikerad UART med endast M4-överföring. Detta kräver ett USB/seriekort, till exempel en FTDI Friend och en terminalemulator.

    Azure Sphere Hello World-exemplet visar hur du skriver ut till M4-felsöknings-UART.

    Det finns också exempelprogram som är tillgängliga från CodeThink och MediaTek:

    Felsökningsflagga kompileringstidsdefinitioner kan också användas i realtidskompatibla (M4)-program.

  • Använda kommunikation mellan kärnor för att skicka tillstånd från ett realtidskompatibelt program till ett högnivåprogram

    Om du skapar ett system som kombinerar ett högpresterande och realtidskompatibelt program kanske du vill använda högnivåprogrammet för att logga systemtillståndet för båda programmen. Kommunikation mellan kärnor kan användas för detta – Azure Sphere Inter-core Communication-exemplet implementerar ett enkelt gränssnitt för att skicka ett meddelande mellan ett högnivå- och realtidskompatibelt program.

    Den här Azure Sphere-utbildningsmodulen visar hur du använder Azure Sphere och Azure RTOS, kombinerat med en meddelandemodell mellan kärnor för att skicka anpassade meddelanden mellan kärnorna.

Hämta felsökningsutdata för en enhet som inte är ansluten till en utvecklingsdator

Problem: Hur loggar du felsökningsutdata när enheten inte är ansluten till en utvecklingsdator?

Alternativ:

  • Skicka felsökningsutdata via nätverket eller en UART

    Det är ganska enkelt att hämta felsökningslogginformation när en enhet är ansluten till en utvecklingsdator. Men du kanske också vill samla in felsöknings-/logginformation när en enhet inte är ansluten till en dator. Du kan till exempel ha en uppsättning enheter som kör långsiktiga tester.

    Om dina enheter är anslutna till ett nätverk kanske du vill skicka felsökningsutdata via nätverket till ett program som kan samla in och analysera informationen. Det här Azure Sphere Gallery-programmet visar hur du åsidosätter standardbeteendet för Log_Debug för att skicka och ta emot utdata via en UDP-socket.

    Observera att den mekanism som används för att åsidosätta standardprogrammet med hög nivå Log_Debug beteende också kan användas för att skicka felsökningslogginformationen till andra platser, till exempel för att mata ut data på en av Azure Sphere-UART:erna. Du kan använda det här UART-exemplet som referens för att kombinera med UDPDebugLog Gallery-programmet för att logga dina meddelanden till en UART.

  • Skicka felsökningsutdata till Azure IoT Hub/Azure IoT Central

    Felsökning av utdata kan vara användbart för att diagnostisera problem när de inträffar, men det kan också vara användbart att lagra telemetri-/logginformation från en enhet för efterbearbetning.

    När du konfigurerar en instans av Azure IoT Hub eller Azure IoT Central får du en slutpunkt för att skicka telemetridata för enheter som kan användas som en del av din affärslogik. Du kan även skicka information om enhetstillstånd/logg som kan behandlas separat från telemetri-/affärsdata.

    • Azure IoT Hub

      Din Azure IoT Hub-instans kan konfigureras för att skicka data till en Azure Database för lagring/analys. Du kanske också vill filtrera meddelandena, som kan uppnås via EventHub och en Azure-funktion.

      För Azure IoT Hub kan du skicka data till en Azure-funktion som sedan kan bearbeta meddelandena. I artikeln Azure IoT Hub-utlösare för Azure Functions beskrivs hur du länkar en Azure-funktion till en Azure IoT Hub-instans.

    • Azure IoT Central

      Azure IoT Central innehåller möjligheten att kontinuerligt exportera dina data till olika slutpunkter, inklusive:

      • Azure Event Hubs
      • Azure Service Bus-kö
      • Azure Service Bus-ämne
      • Azure Blob Storage
      • Webhook

      WebHook är en REST API-slutpunkt som du skapar, detta kan vara en Azure-funktion.

    Observera att du kanske vill filtrera meddelanden i din Azure-funktion baserat på enhets-ID:t som skickar data. Du kan hämta enhets-ID:t med hjälp av följande kod i Azure-funktionen:

    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 och Azure IoT Central stöder Device Twins, som innehåller önskat tillstånd (anges i IoT Hub/Central-programmet) och rapporterat tillstånd (tillstånd från enheten). Du kan använda Azure IoT Hub/Central Device Twin för att ange ett önskat tillstånd för loggdatas utförlighet (öka/minska loggningsfrekvensen eller mängden loggningsdata). Azure IoT-exemplet visar hur du hanterar enhetstvillingändringarDesired State.

Logga data till lagring

Azure Sphere stöder upp till 64 KB föränderlig lagring för ett högnivåprogram, detta kan användas för att bevara inställningar, programtillstånd eller andra data. Programutvecklare ansvarar för serialisering/deserialisering av data till föränderlig lagring – Azure Sphere-galleriet innehåller ett projekt som visar hur du använder ett nyckel/värde-par (ordlista) för att skriva/läsa tillstånd till föränderlig lagring (upp till 64 KB beroende på hur programmanifestet konfigureras).

Du kanske vill skriva mer än 64 KB logg-/tillståndsdata till någon form av extern lagring, detta kan vara användbart för enheter som har tillfälliga anslutningar eller behöver lagra/hämta mer än 64 KB data.

Ett alternativ är att lägga till extern lagring, kanske använda SPI Flash för att lagra data – det här projektet använder SPI-blixt för att lagra en over-the-air-uppdatering för en nedströmsenhet och kan ändras för att stödja loggning av telemetri-/tillståndsdata från ett Azure Sphere-program.