Udostępnij za pośrednictwem


Samouczek: tworzenie i debugowanie aplikacji partnerskich

Ważne

Jest to dokumentacja usługi Azure Sphere (starsza wersja). Usługa Azure Sphere (starsza wersja) zostanie wycofana 27 września 2027 r., a użytkownicy muszą przeprowadzić migrację do usługi Azure Sphere (zintegrowanej) do tej pory. Użyj selektora wersji znajdującego się powyżej spisu treści, aby wyświetlić dokumentację usługi Azure Sphere (zintegrowaną).

W tym samouczku pokazano, jak skompilować i debugować przykładowy projekt, który obejmuje zarówno aplikację wysokiego poziomu, jak i aplikację z obsługą w czasie rzeczywistym, gdzie dwie aplikacje komunikują się między rdzeniem A7 wysokiego poziomu a rdzeniem M4 w czasie rzeczywistym. Zobacz Omówienie aplikacji usługi Azure Sphere, aby uzyskać podstawowe informacje o aplikacjach wysokiego poziomu i aplikacjach obsługujących w czasie rzeczywistym.

Z tego samouczka dowiesz się, jak wykonywać następujące czynności:

  • Instalowanie łańcucha narzędzi ARM GNU
  • Konfigurowanie sprzętu do wyświetlania danych wyjściowych
  • Włączanie programowania i debugowania
  • Klonowanie przykładowego repozytorium usługi Azure Sphere
  • Uruchamianie emulatora terminalu w celu wyświetlenia danych wyjściowych
  • Kompilowanie, uruchamianie i debugowanie pary aplikacji partnerskich

Ważne

W tych instrukcjach przyjęto założenie, że używasz sprzętu zgodnego ze sprzętem tablicy referencyjnej MT3620 (RDB), takim jak zestaw deweloperski MT3620 z witryny Seeed Studios. Jeśli używasz innego sprzętu usługi Azure Sphere, zapoznaj się z dokumentacją producenta, aby dowiedzieć się, czy uART jest uwidoczniony i jak uzyskać do niego dostęp. Może być konieczne skonfigurowanie sprzętu do wyświetlania danych wyjściowych w inny sposób i zaktualizowanie przykładowego kodu oraz pola "Uarts" pliku app_manifest.json w celu użycia innego schematu UART.

Wymagania wstępne

Zainstaluj osadzony łańcuch narzędzi GNU dla procesorów ARM

  • Visual Studio 2022: Jeśli używasz programu Visual Studio 2022, zainstaluj osadzony łańcuch narzędzi GNU ARM (arm-none-eabi) z witryny internetowej dla deweloperów arm.
  • Visual Studio 2019: Łańcuch narzędzi jest automatycznie instalowany z rozszerzeniem usługi Azure Sphere dla programu Visual Studio w programie Visual Studio 2019. Jeśli używasz programu Visual Studio 2019, przejdź do sekcji Konfigurowanie sprzętu do wyświetlania danych wyjściowych. Jednak w przypadku ręcznego zainstalowania osadzonego łańcucha narzędzi GNU arm program Visual Studio będzie używać zainstalowanej wersji.

Aby zainstalować łańcuch narzędzi, na stronie dla deweloperów arm znajdź osadzony łańcuch narzędzi GNU ARM (arm-none-eabi), który zawiera kompilator procesora ARM Cortex-M4. Postępuj zgodnie z instrukcjami, aby pobrać i zainstalować kompilator dla platformy systemu operacyjnego.

Domyślnie program Visual Studio Code wyszukuje łańcuch narzędzi i powinien znaleźć zainstalowaną wersję. Jeśli wystąpią problemy z kompilacją związane z łańcuchem narzędzi, sprawdź pozycję Rozszerzenia>ustawień>preferencji>AzureSphere, aby upewnić się, że "Azure Sphere: Arm Gnu Path" identyfikuje katalog instalacyjny łańcucha narzędzi GNU Arm Embedded.

Konfigurowanie sprzętu do wyświetlania danych wyjściowych

Obecnie każdy rdzeń czasu rzeczywistego obsługuje moduł UART tylko tx. Aplikacja RTApps może użyć tego UART do wysyłania danych wyjściowych dziennika z urządzenia. Podczas tworzenia i debugowania aplikacji zazwyczaj potrzebny jest sposób odczytywania i wyświetlania danych wyjściowych. W przykładzie HelloWorld_RTApp_MT3620_BareMetal pokazano, jak aplikacja może zapisywać dane w usłudze UART.

Użyj adaptera USB-to-serial, takiego jak FTDI Friend, aby podłączyć UART na rdzeniu czasu rzeczywistego do portu USB na maszynie. Do wyświetlenia danych wyjściowych będzie również potrzebny emulator terminalu do nawiązania połączenia szeregowego z ustawieniami terminalu 115200-8-N-1 (115200 bps, 8 bitów, bez bitów parzystości, jeden bit zatrzymania).

Aby skonfigurować sprzęt do wyświetlania danych wyjściowych z aplikacji RTApp, wykonaj poniższe kroki. Należy zapoznać się z dokumentacją producenta sprzętu, aby określić lokalizacje pinezek. Jeśli używasz sprzętu, który jest zgodny z referencyjnym projektem płyty (RDB) MT3620, takiego jak zestaw deweloperski MT3620 firmy Seeed Studios, to użycie nagłówków interfejsu RDB może pomóc w ustaleniu lokalizacji pinezek.

  1. Połącz złącze GND na adapterze z portu USB na port szeregowy ze złączem GND w zestawie deweloperskim. Na sprzęcie RDB MT3620 złącze GND ma nagłówek 3, pinezka — 2.

  2. Połącz złącze RX na adapterze z portu USBna port szeregowy ze złączem IOM4-0 TX w zestawie deweloperskim. Na sprzęcie RDB MT3620 złącze IOM4-0 TX ma nagłówek 3, pinezka — 6.

  3. Podłącz adapter USB-szeregowy do wolnego portu USB na maszynie dewelopera i określ, z którym portem jest podłączone urządzenie szeregowe.

    • W systemie Windows uruchom Menedżer urządzeń, wybierz pozycję Wyświetl>urządzenia według kontenera i wyszukaj ciąg "USB UART". Na przykład FT232R USB UART wskazuje adapter FTDI Friend.

    • W systemie Linux wpisz następujące polecenie:

      dmesg | grep ttyUSB
      

      Port powinien mieć nazwę ttyUSBn, gdzie n wskazuje numer portu. Jeśli polecenie dmesg wyświetla kilka portów USB, ten, który jest podłączony do typowego ostatniego zgłoszonego jako dołączony. Na przykład w następujących celach należy użyć polecenia ttyUSB4:

    ~$ dmesg | grep ttyUSB
    [  144.564350] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB0
    [  144.564768] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB1
    [  144.565118] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB2
    [  144.565593] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB3
    [  144.570429] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB4
    [  254.171871] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
    
  4. Uruchom program emulatora terminalu i otwórz terminal 115200-8-N-1 do portu COM używanego przez adapter. Zapoznaj się z dokumentacją emulatora terminalu, aby dowiedzieć się, jak określić port i szybkość.

Włączanie programowania i debugowania

Aby można było utworzyć przykładową aplikację na urządzeniu usługi Azure Sphere lub utworzyć dla niej nowe aplikacje, musisz włączyć programowanie i debugowanie. Domyślnie urządzenia usługi Azure Sphere są "zablokowane"; oznacza to, że nie zezwalają na ładowanie aplikacji z komputera i nie zezwalają na debugowanie aplikacji. Przygotowanie urządzenia do debugowania powoduje usunięcie tego ograniczenia i załadowanie oprogramowania wymaganego do debugowania i odblokowania możliwości urządzenia zgodnie z opisem w temacie Możliwości i komunikacja urządzenia.

Aby debugować rdzenie czasu rzeczywistego, użyj polecenia azsphere device enable-development. To polecenie umożliwia skonfigurowanie urządzenia do akceptowania aplikacji z komputera na potrzeby debugowania i przypisywania urządzenia do grupy urządzeń deweloperskich, która nie zezwala na aktualizacje aplikacji w chmurze. Podczas tworzenia i debugowania aplikacji należy pozostawić urządzenie w tej grupie, aby aktualizacje aplikacji w chmurze nie zastępowały aplikacji w trakcie programowania.

W systemie Windows należy dodać --enable-rt-core-debugging parametr, który ładuje serwery debugowania i wymagane sterowniki dla każdego typu rdzenia na urządzeniu.

  1. Zaloguj się do usługi Azure Sphere, jeśli jeszcze tego nie zrobiono:

    azsphere login
    
  2. Otwórz interfejs wiersza polecenia przy użyciu programu PowerShell lub wiersza polecenia systemu Windows z uprawnieniami administratora. Parametr --enable-rt-core-debugging wymaga uprawnień administratora, ponieważ instaluje sterowniki USB dla debugera.

  3. Podaj następujące polecenie:

    azsphere device enable-development --enable-rt-core-debugging
    
  4. Zamknij okno po zakończeniu polecenia, ponieważ uprawnienia administratora nie są już wymagane. Najlepszym rozwiązaniem jest zawsze użycie najniższych uprawnień, które mogą wykonać zadanie.

Jeśli polecenie azsphere device enable-development zakończy się niepowodzeniem, zobacz Rozwiązywanie problemów z usługą Azure Sphere, aby uzyskać pomoc.

Pobieranie przykładowej aplikacji

Aplikacje komunikacji między rdzeniami można pobrać w następujący sposób: :

  1. Wskaż przeglądarkę w przeglądarce Microsoft Samples Browser.
  2. Wpisz "Azure Sphere" w polu Wyszukiwania.
  3. Wybierz pozycję Azure Sphere — komunikacja między rdzeniami z wyników wyszukiwania.
  4. Wybierz pozycję Pobierz plik ZIP.
  5. Otwórz pobrany plik i wyodrębnij go do katalogu lokalnego.

Kompilowanie i uruchamianie aplikacji partnerskich

  1. Uruchom program Visual Studio. Wybierz pozycję Otwórz folder lokalny i przejdź do folderu, w którym wyodrębniono aplikacje IntercoreComms.

    Ważne

    Jeśli używasz programu Visual Studio 2022 w wersji 17.1 lub nowszej i wyodrębniono przykład IntercoreComms przed wydaniem usługi Azure Sphere 22.02, musisz dodać plik CMakeWorkspaceSettings.json do folderu projektu najwyższego poziomu.

  2. Jeśli nie używasz bazy danych RDB MT3620, zaktualizuj pliki app_manifest.json dla aplikacji oraz pliku definicji sprzętu i CMakeLists.txt, aby aplikacja wysokiego poziomu odpowiadała sprzętowi.

  3. Jeśli generowanie narzędzia CMake nie zostanie uruchomione automatycznie, wybierz plik CMakeLists.txt.

  4. W programie Visual Studio wyświetl>dane wyjściowe Pokaż dane>wyjściowe z: dane wyjściowe narzędzia CMake powinny zawierać komunikaty CMake generation started i .CMake generation finished

  5. Wybierz pozycję Kompiluj>wszystko. Jeśli menu nie jest obecne, otwórz Eksplorator rozwiązań, kliknij prawym przyciskiem myszy plik CMakeLists.txt i wybierz polecenie Kompiluj. Lokalizacja wyjściowa aplikacji IntercoreComms_HL & IntercoreComms RT jest wyświetlana w oknie Dane wyjściowe .

  6. Wybierz pozycję Wybierz pozycję Start Item>IntercoreComms (Wszystkie rdzenie).

  7. Wybierz pozycję Debuguj debugowanie> lub naciśnij F5, aby wdrożyć i debugować aplikacje.

  8. W oknie Dane wyjściowe wybierz dane wyjściowe z menu, wybierz pozycję Dane wyjściowe urządzenia. W oknie Dane wyjściowe powinny zostać wyświetlone dane wyjściowe aplikacji wysokiego poziomu:

    Remote debugging from host 192.168.35.1, port 58817
    High-level intercore comms application
    Sends data to, and receives data from a real-time capable application.
    Received 19 bytes: rt-app-to-hl-app-07
    Sending: hl-app-to-rt-app-00
    Sending: hl-app-to-rt-app-01
    
  9. Połączony emulator terminalu powinien wyświetlać dane wyjściowe z programu obsługującego w czasie rzeczywistym:

    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
    Message size: 19 bytes:
    Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
    Text: hl-app-to-rt-app-00
    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
    Message size: 19 bytes:
    Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:31
    Text: hl-app-to-rt-app-01
    
  10. Użyj debugera, aby ustawić punkty przerwania, sprawdzić zmienne i wypróbować inne zadania debugowania.

  1. W programie Visual Studio Code otwórz folder, w którym wyodrębniono aplikacje IntercoreComms. Program Visual Studio Code wykrywa plik intercore.code-workspace i, czy chcesz otworzyć obszar roboczy. Wybierz pozycję Otwórz obszar roboczy, aby otworzyć jednocześnie aplikację czasu rzeczywistego i aplikację wysokiego poziomu.

  2. Jeśli nie używasz bazy danych RDB MT3620, zaktualizuj pliki app_manifest.json dla aplikacji oraz pliku definicji sprzętu i CMakeLists.txt, aby aplikacja wysokiego poziomu odpowiadała sprzętowi.

  3. Naciśnij F5, aby uruchomić debuger. Jeśli projekt nie został wcześniej skompilowany lub jeśli pliki uległy zmianie i ponowne kompilowanie jest wymagane, program Visual Studio Code skompiluje projekt przed rozpoczęciem debugowania.

  4. W oknie danych wyjściowych usługi Azure Sphere powinna zostać wyświetlona wartość „Trwa wdrażanie obrazu...” ze ścieżkami do zestawu SDK i kompilatora.

  5. W oknie danych wyjściowych powinny zostać wyświetlone dane wyjściowe aplikacji wysokiego poziomu:

    Remote debugging from host 192.168.35.1, port 58817
    High-level intercore comms application
    Sends data to, and receives data from a real-time capable application.
    Received 19 bytes: rt-app-to-hl-app-07
    Sending: hl-app-to-rt-app-00
    Sending: hl-app-to-rt-app-01
    
  6. Połączony emulator terminalu powinien wyświetlać dane wyjściowe z programu obsługującego w czasie rzeczywistym:

    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
    Message size: 19 bytes:
    Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
    Text: hl-app-to-rt-app-00
    Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
    Message size: 19 bytes:
    Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:31
    Text: hl-app-to-rt-app-01
    
  7. Użyj funkcji debugowania programu Visual Studio Code, aby ustawić punkty przerwania, sprawdzić zmienne i wypróbować inne zadania debugowania.

Rozwiązywanie problemów

Aplikacja może rozpocząć wykonywanie, zanim usługa OpenOCD nawiązuje połączenie. W związku z tym punkty przerwania ustawione na początku kodu mogą zostać pominięte. Prostym obejściem tego problemu jest opóźnienie uruchamiania aplikacji do momentu nawiązania połączenia z usługą OpenOCD.

  1. Wstaw następujący kod na początku punktu wejścia aplikacji RTCoreMain. Spowoduje to wprowadzenie aplikacji i pozostanie w while pętli, dopóki zmienna f nie zostanie ustawiona na wartość true.

    static _Noreturn void RTCoreMain(void)
    {
      .
      .
      .
     volatile bool f = false;
     while (!f) {
        // empty.
     }
      .
      .
      .
    }
    
  2. Naciśnij F5, aby uruchomić aplikację przy użyciu debugowania, a następnie przerwij w wykonywaniu.

  3. W okienku debugowania Lokalne zmień wartość f z zera na jedną.

  4. Wykonaj kroki kodu w zwykły sposób.

Podczas kompilowania przy użyciu interfejsu wiersza polecenia należy najpierw skompilować i wdrożyć aplikację obsługną w czasie rzeczywistym, a następnie skompilować i wdrożyć aplikację wysokiego poziomu.

Tworzenie i wdrażanie aplikacji obsługującej czas rzeczywisty

  1. Przejdź do folderu, w którym wyodrębniono aplikacje IntercoreComms, a następnie wybierz folder IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal.

  2. Otwórz plik app_manifest.json i sprawdź, czy identyfikator składnika aplikacji wysokiego poziomu jest wyświetlany w funkcji AllowedApplicationConnections.

  3. Otwórz interfejs wiersza polecenia przy użyciu programu PowerShell, wiersza polecenia systemu Windows lub powłoki poleceń systemu Linux. Przejdź do katalogu kompilacji projektu.

  4. W katalogu kompilacji projektu w wierszu polecenia uruchom narzędzie CMake z następującymi parametrami:

    cmake --preset <preset-name> <source-path>
    
    • --preset <preset-name>

      Wstępnie zdefiniowana w CMakePresets.json nazwa konfiguracji kompilacji.

    • --build <cmake-path>

      Katalog binarny zawierający pamięć podręczną CMake. Jeśli na przykład uruchomisz narzędzie CMake w usłudze Azure Sphere, polecenie kompilacji będzie następujące: cmake --build out/ARM-Debug.

    • <source-path>

      Ścieżka katalogu zawierającego pliki źródłowe przykładowej aplikacji. W tym przykładzie repozytorium przykładów usługi Azure Sphere zostało pobrane do katalogu o nazwie AzSphere.

      Parametry narzędzia CMake są oddzielone spacjami. Znak kontynuacji wiersza (^ dla wiersza polecenia systemu Windows, \ dla wiersza polecenia systemu Linux lub " dla programu PowerShell) może być używany do odczytu, ale nie jest wymagany.

    W poniższych przykładach przedstawiono polecenia narzędzia CMake dla aplikacji IntercoreComms RTApp:

    Wiersz polecenia systemu Windows

     cmake ^
    --preset "ARM-Debug" ^
     "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"
    

    Windows PowerShell

     cmake `
    --preset "ARM-Debug" `
     "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_RTApp_MT3620_BareMetal"
    
  5. W katalogu kompilacji projektu w wierszu polecenia uruchom narzędzie Ninja, aby skompilować aplikację i utworzyć plik pakietu obrazów.

    ninja -C out/ARM-Debug
    

    Ninja umieszcza wynikową aplikację i pliki imagepackage w określonym katalogu.

    Możesz również wywołać ninja za pomocą narzędzia CMake za pomocą następującego polecenia:

    cmake --build out/<binary-dir>
    

    Ustaw <binary-dir> na katalog binarny zawierający pamięć podręczną CMake. Jeśli na przykład uruchomisz narzędzie CMake w usłudze Azure Sphere, polecenie kompilacji będzie następujące: cmake --build out/ARM-Debug.

    Podczas rozwiązywania problemów, szczególnie po wprowadzeniu jakichkolwiek zmian w poleceniach narzędzia CMake usuń całą kompilację i spróbuj ponownie.

  6. Usuń wszystkie aplikacje, które zostały już wdrożone na urządzeniu:

    azsphere device sideload delete
    
  7. Z katalogu kompilacji projektu w wierszu polecenia załaduj pakiet obrazu utworzony przez ninja:

    azsphere device sideload deploy --image-package <path-to-imagepackage>
    

    Aplikacja zostanie uruchomiona wkrótce po załadowaniu.

  8. Pobierz identyfikator składnika dla obrazu:

    azsphere image-package show --image-package <path-to-imagepackage>
    

    Polecenie zwraca wszystkie metadane pakietu obrazów. Identyfikator składnika aplikacji jest wyświetlany w sekcji Tożsamość dla typu obrazu aplikacji. Na przykład:

    Image package metadata:
    Section: Identity
    Image Type:           Application
    Component ID:         <component id>
    Image ID:             <image id>
    

Kompilowanie i wdrażanie aplikacji wysokiego poziomu

  1. Przejdź do folderu, w którym wyodrębniono aplikacje IntercoreComms, a następnie wybierz folder IntercoreComms/IntercoreComms_HighLevelApp.

  2. Otwórz plik app_manifest.json i sprawdź, czy identyfikator składnika RTApp jest wyświetlany w funkcji AllowedApplicationConnections.

  3. Otwórz interfejs wiersza polecenia przy użyciu programu PowerShell, wiersza polecenia systemu Windows lub powłoki poleceń systemu Linux. Przejdź do katalogu kompilacji projektu.

  4. W katalogu kompilacji projektu w wierszu polecenia uruchom narzędzie CMake z następującymi parametrami:

    cmake --preset <preset-name> <source-path>
    
    • --preset <preset-name>

      Wstępnie zdefiniowana w CMakePresets.json nazwa konfiguracji kompilacji.

    • --build <cmake-path>

      Katalog binarny zawierający pamięć podręczną CMake. Jeśli na przykład uruchomisz narzędzie CMake w usłudze Azure Sphere, polecenie kompilacji będzie następujące: cmake --build out/ARM-Debug.

    • <source-path>

      Ścieżka katalogu zawierającego pliki źródłowe przykładowej aplikacji. W tym przykładzie repozytorium przykładów usługi Azure Sphere zostało pobrane do katalogu o nazwie AzSphere.

      Parametry narzędzia CMake są oddzielone spacjami. Znak kontynuacji wiersza (^ dla wiersza polecenia systemu Windows, \ dla wiersza polecenia systemu Linux lub " dla programu PowerShell) może być używany do odczytu, ale nie jest wymagany.

    W poniższych przykładach przedstawiono polecenia narzędzia CMake dla aplikacji wysokiego poziomu IntercoreComms.

    Wiersz polecenia systemu Windows

     cmake ^
     --preset "ARM-Debug" ^
     "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"
    

    Windows PowerShell

     cmake `
     --preset "ARM-Debug" `
     "C:\AzSphere\azure-sphere-samples\Samples\IntercoreComms\IntercoreComms_HighLevelApp"
    
  5. W katalogu kompilacji projektu w wierszu polecenia uruchom narzędzie Ninja, aby skompilować aplikację i utworzyć plik pakietu obrazów.

    ninja -C out/ARM-Debug
    

    Ninja umieszcza wynikową aplikację i pliki imagepackage w określonym katalogu.

    Możesz również wywołać ninja za pomocą narzędzia CMake za pomocą następującego polecenia:

    cmake --build out/<binary-dir>
    

    Ustaw <binary-dir> na katalog binarny zawierający pamięć podręczną CMake. Jeśli na przykład uruchomisz narzędzie CMake w usłudze Azure Sphere, polecenie kompilacji będzie następujące: cmake --build out/ARM-Debug.

    Podczas rozwiązywania problemów, szczególnie po wprowadzeniu jakichkolwiek zmian w poleceniach narzędzia CMake usuń całą kompilację i spróbuj ponownie.

  6. Z katalogu kompilacji projektu w wierszu polecenia załaduj pakiet obrazu utworzony przez ninja:

    azsphere device sideload deploy --image-package <package-name>
    

    Aplikacja zostanie uruchomiona wkrótce po załadowaniu.

  7. Pobierz identyfikator składnika dla obrazu:

    azsphere image-package show --image-package <path-to-imagepackage>
    

    Polecenie zwraca wszystkie metadane pakietu obrazów. Identyfikator składnika aplikacji jest wyświetlany w sekcji Tożsamość dla typu obrazu aplikacji. Na przykład:

    Image package metadata:
      Section: Identity
        Image Type:           Application
        Component ID:         <component id>
        Image ID:             <image id>
    

Uruchamianie aplikacji partnerskich z włączonym debugowaniem

  1. Zatrzymaj aplikację w czasie rzeczywistym, jeśli jest uruchomiona.

    azsphere device app stop --component-id <component id>
    
  2. Uruchom ponownie aplikację na potrzeby debugowania.

    azsphere device app start --component-id <component id>
    

    To polecenie zwraca rdzeń, na którym działa aplikacja.

      <component id>
      App state: running
      Core        : Real-time 0
    
  3. Przejdź do folderu Openocd folderu sysroot, za pomocą którego utworzono aplikację. Katalogi sysroot są instalowane w folderze instalacyjnym zestawu SDK usługi Azure Sphere. Na przykład w systemie Windows folder jest instalowany domyślnie w folderze C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd i w systemie Linux pod adresem /opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux.

  4. Uruchom polecenie , openocd jak pokazano w poniższym przykładzie. W przykładzie założono, że aplikacja działa na rdzeniu 0. Jeśli aplikacja jest uruchomiona na rdzeniu 1, zastąp ciąg "targets io0" ciągiem "targets io1".

       openocd -f mt3620-rdb-ftdi.cfg -f mt3620-io0.cfg -c "gdb_memory_map disable" -c "gdb_breakpoint_override hard" -c init -c "targets io0" -c halt -c "targets"
    
  5. Otwórz nowy wiersz polecenia usługi Azure Sphere (klasyczny interfejs wiersza polecenia usługi Windows Azure Sphere), standardowy wiersz polecenia lub program PowerShell (interfejs wiersza polecenia usługi Windows Azure Sphere) lub okno terminalu (Linux).

  6. Przejdź do folderu zawierającego plik .out aplikacji obsługującej czas rzeczywisty i uruchom arm-none-eabi-gdbplik , który jest częścią łańcucha narzędzi osadzonych arm GNU:

    Wiersz polecenia systemu Windows

    "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out
    

    Windows PowerShell

     & "C:\Program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update\bin\arm-none-eabi-gdb" IntercoreComms_RTApp_MT3620_BareMetal.out
    
  7. Serwer OpenOCD udostępnia interfejs serwera GDB w systemie :4444. Ustaw element docelowy na potrzeby debugowania.

    target remote :4444

  8. Teraz można uruchamiać polecenia gdb do aplikacji obsługującej czas rzeczywisty. Dodaj punkt przerwania w funkcji HandleSendTimerDeferred:

    break HandleSendTimerDeferred
    
  9. Połączony emulator terminalu powinien wyświetlać dane wyjściowe z aplikacji obsługującej czas rzeczywisty.

  10. Otwórz nowy wiersz polecenia usługi Azure Sphere (klasyczny interfejs wiersza polecenia usługi Windows Azure Sphere), standardowy wiersz polecenia lub program PowerShell (interfejs wiersza polecenia usługi Windows Azure Sphere) lub okno terminalu (Linux).

  11. Przejdź do folderu zawierającego plik .imagepackage aplikacji wysokiego poziomu.

  12. Zatrzymaj aplikację wysokiego poziomu, jeśli jest uruchomiona.

    azsphere device app stop --component-id <component id>
    
  13. Uruchom ponownie aplikację wysokiego poziomu przy użyciu debugowania.

    azsphere device app start --component-id <component id> --debug-mode
    
  14. Otwórz emulator terminalu i ustanów połączenie Telnet lub TCP z adresem 192.168.35.2 na porcie 2342, aby wyświetlić dane wyjściowe aplikacji wysokiego poziomu.

  15. Uruchom bazę danych gdb za pomocą następującego polecenia:

    Wiersz polecenia systemu Windows

    "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out
    

    Windows PowerShell

    & "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\gcc\arm-poky-linux-musleabi-gdb.exe" IntercoreComms_HighLevelApp.out
    

    Uwaga

    Zestaw SDK usługi Azure Sphere jest dostarczany z wieloma katalogami sysroot, dzięki czemu aplikacje mogą kierować do różnych zestawów interfejsów API zgodnie z opisem w temacie Wersja środowiska uruchomieniowego aplikacji, katalogi sysroot i interfejsy API beta. Katalogi sysroot są instalowane w folderze instalacyjnym zestawu SDK usługi Azure Sphere w obszarze Sysroots.

  16. Ustaw docelowy zdalny debugowanie na adres IP 192.168.35.2 na porcie 2345:

    target remote 192.168.35.2:2345

  17. Dodaj punkt przerwania w funkcji SendMessageToRTApp:

    break SendMessageToRTApp

  18. Wpisz c , aby kontynuować, obserwuj dane wyjściowe w terminalu Telnet/TCP, a następnie przejdź do wiersza polecenia lub okna terminalu zawierającego sesję debugowania aplikacji w czasie rzeczywistym.

  19. Wpisz c , aby kontynuować i obserwować dane wyjściowe w połączonej sesji szeregowej.

Możesz pracować tam i z powrotem między sesjami debugowania, przełączając się między aplikacją obsługą w czasie rzeczywistym a aplikacją wysokiego poziomu. Powinny zostać wyświetlone dane wyjściowe podobne do następujących w dwóch oknach wyjściowych:

Starting debugger....
                     Process /mnt/apps/25025d2c-66da-4448-bae1-ac26fcdd3627/bin/app created; pid = 40
                     Listening on port 2345
                                           Remote debugging from host 192.168.35.1, port 56522
              High-level intercore comms application
                                                    Sends data to, and receives data from a real-time capable application.
                                          Sending: hl-app-to-rt-app-00
                                                                      Sending: hl-app-to-rt-app-01
IntercoreComms_RTApp_MT3620_BareMetal
App built on: Nov 17 2020, 09:25:19
Sender: 25025d2c-66da-4448-bae1-ac26fcdd3627
Message size: 19 bytes:
Hex: 68:6c:2d:61:70:70:2d:74:6f:2d:72:74:2d:61:70:70:2d:30:30
Text: hl-app-to-rt-app-00

Aby zakończyć każdą sesję debugowania, wpisz q w wierszu polecenia bazy danych gdb.

Następne kroki