チュートリアル: パートナー アプリケーションのビルドとデバッグ
このチュートリアルでは、高レベルのアプリケーションとリアルタイム対応アプリケーションの両方を含むサンプル プロジェクトをビルドしてデバッグする方法について説明します。このアプリケーションは、高レベルの A7 コアとリアルタイム M4 コアの間で通信します。 高度なアプリケーションとリアルタイム対応アプリケーションの基本的な情報については、「 Azure Sphere アプリケーションの概要」を参照してください。
このチュートリアルでは、次の方法について説明します。
- GNU Arm ツールチェーンをインストールする
- 出力を表示するようにハードウェアを設定する
- 開発とデバッグを有効にする
- Azure Sphere サンプル リポジトリを複製する
- ターミナル エミュレーターを起動して出力を表示する
- パートナー アプリケーションのペアをビルド、実行、デバッグする
大事な
これらの手順では、MT3620 リファレンス ボード 設計 (RDB) ハードウェア (Seeed Studios の MT3620 Dev Kit など) に従うハードウェアを使用していることを前提としています。 別の Azure Sphere ハードウェアを使用している場合は、製造元のドキュメントを参照して、UART が公開されているかどうかを確認し、そのハードウェアにアクセスする方法を確認してください。 出力を異なる方法で 表示するようにハードウェアを設定 し、app_manifest.json ファイルのサンプル コードと Uarts フィールドを更新して、別の UART を使用する必要がある場合があります。
前提 条件
- Windows または Linux 用の Visual Studio Code をインストールします。
- Windows または Linux 用の CMake と Ninja をインストールします。
- Windows または Linux 用の Azure Sphere SDK をインストールします。
- カタログを選択し、デバイスを要求します。
- ネットワークを構成し、デバイス OS を更新します。
GNU Arm Embedded Toolchain をインストールする
- Visual Studio 2022: Visual Studio 2022 を使用している場合は、 Arm 開発者向け Web サイトから GNU Arm Embedded Toolchain (arm-none-eabi) をインストールします。
- Visual Studio 2019: ツールチェーンは、Visual Studio 2019 の Visual Studio 用 Azure Sphere 拡張機能と共に自動的にインストールされます。 Visual Studio 2019 を使用している場合は、 出力を表示するためのハードウェアのセットアップに進みます。 ただし、GNU Arm Embedded Toolchain を手動でインストールした場合、Visual Studio はインストールしたバージョンを使用します。
Arm 開発者向け Web サイトにツールチェーンをインストールするには、ARM Cortex-M4 プロセッサのコンパイラを含む GNU Arm Embedded Toolchain (arm-none-eabi) を見つけます。 こちらの手順に従って、OS プラットフォームのコンパイラをダウンロードしてインストールします。
既定では、Visual Studio Code はツールチェーンを検索し、インストールしたバージョンを見つける必要があります。 ツールチェーンに関連するビルドの問題が発生した場合は、「環境設定>>拡張機能>AzureSphere」をチェックして、"Azure Sphere: Arm Gnu Path" が GNU Arm Embedded Toolchain インストール ディレクトリを識別するようにします。
出力を表示するようにハードウェアを設定する
現時点では、各リアルタイム コアは TX 専用 UART をサポートしています。 RTApps はこの UART を使用して、デバイスからログ出力を送信できます。 アプリケーションの開発とデバッグ中は、通常、出力を読み取って表示する方法が必要です。 HelloWorld_RTApp_MT3620_BareMetalサンプルは、アプリケーションが UART に書き込む方法を示しています。
FTDI フレンドなどの USB からシリアルへのアダプターを使用して、リアルタイム コアの UART をコンピューターの USB ポートに接続します。 また、出力を表示するには、115200-8-N-1 ターミナル設定 (115200 bps、8 ビット、パリティ ビットなし、1 ストップ ビット) でシリアル接続を確立するための ターミナル エミュレーター も必要です。
RTApp からの出力を表示するようにハードウェアを設定するには、次の手順に従います。 ピンの場所を特定するには、ハードウェアの製造元のドキュメントを参照する必要があります。 MT3620 リファレンス ボード 設計 (RDB) ハードウェア (Seeed Studios の MT3620 Dev Kit など) に従うハードウェアを使用している場合は、 RDB インターフェイス ヘッダー を確認すると、ピンの場所を特定するのに役立つ場合があります。
USB からシリアルへのアダプターの GND を開発キットの GND に接続します。 MT3620 RDB ハードウェアでは、GND はヘッダー 3、ピン 2 です。
USB からシリアルへのアダプターの RX を開発キットの IOM4-0 TX に接続します。 MT3620 RDB ハードウェアでは、IOM4-0 TX はヘッダー 3、ピン 6 です。
USB からシリアルへのアダプターを開発用コンピューター上の空き USB ポートに接続し、シリアル デバイスが接続されているポートを決定します。
Windows で、デバイス マネージャーを開始し、[コンテナー別にデバイスを表示>] を選択し、[USB UART] を探します。 たとえば、FT232R USB UART は FTDI フレンド アダプターを示します。
Linux では、次のコマンドを入力します。
dmesg | grep ttyUSB
ポートには ttyUSBn という名前を付ける必要があります。 n はポート番号を示します。 コマンドに複数の
dmesg
USB ポートが一覧表示されている場合、接続されているポートは通常、最後の USB ポートに接続済みとして報告されます。 たとえば、次の例では、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
ターミナル エミュレーター プログラムを起動し、アダプターで使用される COM ポートに 115200-8-N-1 ターミナルを開きます。 ポートと速度を指定する方法については、ターミナル エミュレーターのドキュメントを参照してください。
開発とデバッグを有効にする
Azure Sphere デバイスでサンプル アプリケーションを構築したり、新しいアプリケーションを開発したりする前に、開発とデバッグを有効にする必要があります。 既定では、Azure Sphere デバイスは "ロック" されます。つまり、開発中のアプリケーションを PC から読み込むのは許可せず、アプリケーションのデバッグも許可しません。 デバッグ用にデバイスを準備すると、この制限が解除され、デバッグに必要なソフトウェアが読み込まれて、デバイス機能 のロックが解除されます。
リアルタイム コアでデバッグするには、 az sphere device enable-development コマンドを使用します。 このコマンドは、デバッグのために PC からアプリケーションを受け入れるようにデバイスを構成し、クラウド アプリケーションの更新を許可しない開発デバイス グループにデバイスを割り当てます。 アプリケーションの開発とデバッグ中は、クラウド アプリケーションの更新によって開発中のアプリケーションが上書きされないように、デバイスをこのグループに残す必要があります。
Windows では、デバッグ サーバーとコアの --enable-rt-core-debugging
種類ごとに必要なドライバーをデバイスに読み込むパラメーターを追加する必要があります。
まだログインしていない場合は、Azure Sphere にログインします。
az login
PowerShell または Windows コマンド プロンプトを使用して、管理者特権でコマンド ライン インターフェイスを開きます。 パラメーターには
--enable-rt-core-debugging
、デバッガー用の USB ドライバーがインストールされるため、管理者特権が必要です。次のコマンドを入力します。
az sphere device enable-development --enable-rt-core-debugging --catalog <CatalogName> --resource-group <ResourceGroupName>
管理者特権が不要になったため、コマンドの完了後にウィンドウを閉じます。 ベスト プラクティスとして、タスクを実行できる最小限の特権を常に使用する必要があります。
az sphere device enable-development コマンドが失敗した場合は、「Azure Sphere の問題のトラブルシューティング」を参照してください。
サンプル アプリケーションをダウンロードする
InterCore Communications アプリケーションは、次のようにダウンロードできます。
- ブラウザーを Microsoft Samples Browser にポイントします。
- [Search] ボックスに「Azure Sphere」と入力します。
- 検索結果から [ Azure Sphere - コア間通信 ] を選択します。
- [ ZIP のダウンロード] を選択します。
- ダウンロードしたファイルを開き、ローカル ディレクトリに展開します。
パートナー アプリケーションをビルドして実行する
Visual Studio を起動します。 [ローカル フォルダーを開く] を選択し、IntercoreComms アプリケーションを抽出したフォルダーに移動します。
大事な
Visual Studio 2022 バージョン 17.1 以降を使用していて、22.02 Azure Sphere リリースより前に IntercoreComms サンプルを抽出した場合は、 CMakeWorkspaceSettings.json ファイルを最上位のプロジェクト フォルダーに追加する必要があります。
MT3620 RDB を使用していない場合は、アプリケーションとハードウェア定義ファイルの両方のapp_manifest.jsonファイルと、ハードウェアに一致する高レベルアプリケーションの CMakeLists.txt ファイルを更新します。
CMake の生成が自動的に開始されない場合は、CMakeLists.txt ファイルを選択します。
Visual Studio では、出力>の表示>出力の表示元: CMake 出力には、メッセージ
CMake generation started
とCMake generation finished
が表示されます。[Build All]\(すべてビルド\) を>選択します。 メニューが表示されない場合は、ソリューション エクスプローラーを開き、CMakeLists.txt ファイルを右クリックして、[ビルド] を選択します。 IntercoreComms_HL & IntercoreComms RT アプリケーションの出力場所が [出力 ] ウィンドウに表示されます。
[スタートアップ項目の IntercoreComms (すべてのコア)]を選択します>。
[ デバッグ]>を 選択するか、F5 キーを押してアプリケーションをデプロイしてデバッグします。
[ 出力 ] ウィンドウの [ 出力の選択] メニューで 、[ デバイスの出力] を選択します。 [ 出力] ウィンドウには、アプリケーションの大まかな出力が表示されます。
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
接続されたターミナル エミュレーターには、リアルタイム対応プログラムからの出力が表示されます。
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
デバッガーを使用してブレークポイントを設定し、変数を検査し、他のデバッグ タスクを試します。
Visual Studio Code で、IntercoreComms アプリケーションを抽出したフォルダーを開きます。 Visual Studio Code は intercore.code-workspace ファイルを検出し、ワークスペースを開くかどうかを確認します。 [ワークスペースを開く] を選択して、リアルタイム アプリケーションと高レベル アプリケーションの両方を一度に開きます。
MT3620 RDB を使用していない場合は、アプリケーションとハードウェア定義ファイルの両方のapp_manifest.jsonファイルと、ハードウェアに一致する高レベルアプリケーションの CMakeLists.txt ファイルを更新します。
F5 キーを押してデバッガーを起動します。 プロジェクトが以前にビルドされていない場合、またはファイルが変更され、再構築が必要な場合、Visual Studio Code はデバッグを開始する前にプロジェクトをビルドします。
Azure Sphere の出力ウィンドウに "イメージのデプロイ... " が表示されます。SDK とコンパイラへのパスが続きます。
出力ウィンドウには、アプリケーションの大まかな出力が表示されます。
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
接続されたターミナル エミュレーターには、リアルタイム対応プログラムからの出力が表示されます。
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
Visual Studio Code デバッグ機能を使用して、ブレークポイントの設定、変数の検査、その他のデバッグ タスクの試行を行います。
トラブルシューティング
OpenOCD が接続する前に、アプリケーションの実行が開始される可能性があります。 その結果、コードの早い段階で設定されたブレークポイントが見逃される可能性があります。 この簡単な回避策は、OpenOCD が接続されるまでアプリの起動を遅らせることです。
アプリケーション エントリ ポイント RTCoreMain の先頭に次のコードを挿入します。 これにより、変数
f
が true に設定されるまで、アプリケーションはループにwhile
入り続けます。static _Noreturn void RTCoreMain(void) { . . . volatile bool f = false; while (!f) { // empty. } . . . }
F5 キーを押してデバッグでアプリを起動し、実行に分割します。
[ ローカル ] デバッグ ウィンドウで、 の
f
値を 0 から 1 に変更します。通常どおりにコードをステップ実行します。
CLI を使用してビルドする場合は、まずリアルタイム対応アプリケーションをビルドしてデプロイしてから、高レベルのアプリケーションをビルドしてデプロイします。
リアルタイム対応アプリケーションを構築してデプロイする
IntercoreComms アプリケーションを抽出したフォルダーに移動し、IntercoreComms/IntercoreComms_RTApp_MT3620_BareMetal フォルダーを選択します。
app_manifest.json ファイルを開き、上位レベルのアプリのコンポーネント ID が AllowedApplicationConnections 機能に表示されていることを確認します。
PowerShell、Windows コマンド プロンプト、または Linux コマンド シェルを使用して、コマンド ライン インターフェイスを開きます。 プロジェクトビルドディレクトリに移動します。
プロジェクト ビルド ディレクトリから、コマンド プロンプトで、次のパラメーターを指定して CMake を実行します。
cmake --preset <preset-name> <source-path>
--preset <preset-name>
CMakePresets.jsonで定義されているビルド構成プリセット名。
--build <cmake-path>
CMake キャッシュを含むバイナリ ディレクトリ。 たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルド コマンドは になります
cmake --build out/ARM-Debug
。<source-path>
サンプル アプリケーションのソース ファイルを含むディレクトリのパス。 この例では、Azure Sphere サンプル リポジトリが AzSphere というディレクトリにダウンロードされました。
CMake パラメーターはスペースで区切られます。 行継続文字 (^ for Windows コマンド ライン、\ for Linux コマンド ライン、または ' for PowerShell) は読みやすくするために使用できますが、必須ではありません。
次の例は、IntercoreComms RTApp の CMake コマンドを示しています。
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"
プロジェクト ビルド ディレクトリから、コマンド プロンプトで Ninja を実行してアプリケーションをビルドし、イメージ パッケージ ファイルを作成します。
ninja -C out/ARM-Debug
Ninja は、結果のアプリケーションファイルと .imagepackage ファイルを指定されたディレクトリに配置します。
次のコマンドを使用して、CMake を介して Ninja を呼び出すこともできます。
cmake --build out/<binary-dir>
CMake キャッシュを含むバイナリ ディレクトリに設定
<binary-dir>
します。 たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルド コマンドは になりますcmake --build out/ARM-Debug
。特に CMake コマンドに変更を加えてからトラブルシューティングを行う場合は、ビルド全体を削除してやり直してください。
デバイスに既にデプロイされているアプリケーションを削除します。
az sphere device sideload delete
プロジェクト ビルド ディレクトリから、コマンド プロンプトで、ninja によって作成されたイメージ パッケージを読み込みます。
az sphere device sideload deploy --image-package <path-to-imagepackage>
アプリケーションが読み込まれた直後に、アプリケーションの実行が開始されます。
イメージのコンポーネント ID を取得します。
az sphere image-package show --image-package <path-to-imagepackage>
コマンドは、イメージ パッケージのすべてのメタデータを返します。 アプリケーションのコンポーネント ID は、[アプリケーション イメージの種類] の [ID] セクションに表示されます。 例えば:
... "Identity": { "ComponentId": "<component-id>", "ImageId": "<image-id>", "ImageType": "Application" }, ...
高度なアプリケーションをビルドしてデプロイする
IntercoreComms アプリケーションを抽出したフォルダーに移動し、IntercoreComms/IntercoreComms_HighLevelApp フォルダーを選択します。
app_manifest.json ファイルを開き、RTApp のコンポーネント ID が AllowedApplicationConnections 機能に表示されていることを確認します。
PowerShell、Windows コマンド プロンプト、または Linux コマンド シェルを使用して、コマンド ライン インターフェイスを開きます。 プロジェクトビルドディレクトリに移動します。
プロジェクト ビルド ディレクトリから、コマンド プロンプトで、次のパラメーターを指定して CMake を実行します。
cmake --preset <preset-name> <source-path>
--preset <preset-name>
CMakePresets.jsonで定義されているビルド構成プリセット名。
--build <cmake-path>
CMake キャッシュを含むバイナリ ディレクトリ。 たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルド コマンドは になります
cmake --build out/ARM-Debug
。<source-path>
サンプル アプリケーションのソース ファイルを含むディレクトリのパス。 この例では、Azure Sphere サンプル リポジトリが AzSphere というディレクトリにダウンロードされました。
CMake パラメーターはスペースで区切られます。 行継続文字 (^ for Windows コマンド ライン、\ for Linux コマンド ライン、または ' for PowerShell) は読みやすくするために使用できますが、必須ではありません。
次の例は、IntercoreComms の高レベル アプリケーションの CMake コマンドを示しています。
プロジェクト ビルド ディレクトリから、コマンド プロンプトで Ninja を実行してアプリケーションをビルドし、イメージ パッケージ ファイルを作成します。
ninja -C out/ARM-Debug
Ninja は、結果のアプリケーションファイルと .imagepackage ファイルを指定されたディレクトリに配置します。
次のコマンドを使用して、CMake を介して Ninja を呼び出すこともできます。
cmake --build out/<binary-dir>
CMake キャッシュを含むバイナリ ディレクトリに設定
<binary-dir>
します。 たとえば、Azure Sphere サンプルで CMake を実行する場合、ビルド コマンドは になりますcmake --build out/ARM-Debug
。特に CMake コマンドに変更を加えてからトラブルシューティングを行う場合は、ビルド全体を削除してやり直してください。
プロジェクト ビルド ディレクトリから、コマンド プロンプトで、ninja によって作成されたイメージ パッケージを読み込みます。
az sphere device sideload deploy --image-package <package-name>
アプリケーションが読み込まれた直後に、アプリケーションの実行が開始されます。
イメージのコンポーネント ID を取得します。
az sphere image-package show --image-package <path-to-imagepackage>
コマンドは、イメージ パッケージのすべてのメタデータを返します。 アプリケーションのコンポーネント ID は、[アプリケーション イメージの種類] の [ID] セクションに表示されます。 例えば:
... "Identity": { "ComponentId": "<component-id>", "ImageId": "<image-id>", "ImageType": "Application" }, ...
デバッグを有効にしてパートナー アプリケーションを実行する
リアルタイム アプリケーションが実行されている場合は停止します。
az sphere device app stop --component-id <component id>
デバッグのためにアプリケーションを再実行します。
az sphere device app start -- --debug-mode true --component-id <component id>
このコマンドは、アプリケーションが実行されているコアを返します。
<component id> App state: running Core : Real-time 0
アプリケーションがビルドされた sysroot の Openocd フォルダーに移動します。 sysroots は、Azure Sphere SDK のインストール フォルダーにインストールされます。 たとえば、Windows では、フォルダーは既定で Linux の と
/opt/azurespheresdk/Sysroots/*sysroot*/tools/sysroots/x86_64-pokysdk-linux
でC:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\*sysroot*\tools\openocd
インストールされます。次の例に示すようにを実行
openocd
します。 この例では、アプリがコア 0 で実行されていることを前提としています。 アプリがコア 1 で実行されている場合は、"targets io0" を "targets io1" に置き換えます。新しい Azure Sphere コマンド プロンプト (Windows Azure Sphere クラシック CLI)、標準コマンド プロンプト、PowerShell (Windows Azure CLI)、またはターミナル ウィンドウ (Linux) を開きます。
リアルタイム対応アプリケーション .out ファイルを含むフォルダーに移動し、GNU Arm Embedded Toolchain の一部である start
arm-none-eabi-gdb
に移動します。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
OpenOCD サーバーは、:4444 で GDB サーバー インターフェイスを提供します。 デバッグのターゲットを設定します。
target remote :4444
リアルタイム対応アプリケーションに対して gdb コマンドを実行できるようになりました。 関数 HandleSendTimerDeferred にブレークポイントを追加します。
break HandleSendTimerDeferred
接続されたターミナル エミュレーターは、リアルタイム対応アプリケーションからの出力を表示する必要があります。
新しい Azure Sphere コマンド プロンプト (Windows Azure Sphere クラシック CLI)、標準コマンド プロンプト、PowerShell (Windows Azure CLI)、またはターミナル ウィンドウ (Linux) を開きます。
高度なアプリケーション .imagepackage ファイルを含むフォルダーに移動します。
高度なアプリケーションが実行されている場合は停止します。
az sphere device app stop --component-id <component id>
デバッグを使用して、高度なアプリケーションを再開します。
az sphere device app start --debug-mode true --component-id <component id> --debug-mode
ターミナル エミュレーターを開き、ポート 2342 で 192.168.35.2 への Telnet または TCP 接続を確立して、上位レベルのアプリの出力を表示します。
次のコマンドを使用して gdb を起動します。
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
メモ
Azure Sphere SDK には複数の sysroot が付属しているため、「アプリケーション ランタイム バージョン、sysroots、Beta API」で説明されているように、アプリケーションが異なる API セットをターゲットにすることができます。 sysroots は、 Sysroots の Azure Sphere SDK インストール フォルダーにインストールされます。
リモート デバッグ ターゲットを、ポート 2345 の IP アドレス 192.168.35.2 に設定します。
target remote 192.168.35.2:2345
関数 SendMessageToRTApp にブレークポイントを追加します。
break SendMessageToRTApp
「」と入力
c
して続行し、Telnet/TCP ターミナルの出力を確認してから、リアルタイム アプリケーション デバッグ セッションを含むコマンド プロンプトまたはターミナル ウィンドウに切り替えます。「」と入力
c
して続行し、接続されたシリアル セッションの出力を確認します。
デバッグ セッション間でやり取りし、リアルタイム対応アプリケーションと高レベル アプリケーションを切り替えることができます。 次のような出力が 2 つの出力ウィンドウに表示されます。
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
各デバッグ セッションを終了するには、gdb プロンプトで「」と入力 q
します。
次の手順
- 高レベルおよびリアルタイム対応アプリケーションの 追加サンプル を調べる
- Azure Sphere アプリケーションの詳細
- Azure Sphere 開発環境の詳細