チームの皆さん、こんにちは。
現在、画面ミラーリング機能を搭載したインストルメントクラスターの開発に取り組んでいます。私たちのアーキテクチャでは、対応するモバイルアプリがWi-Fi経由でホストMCUにフレームをストリーミングします。データはSDIO接続のWi-Fiモジュールを通じて受信され、FFmpegでデコードされ、ディスプレイ上でレンダリングされます。ネットワークスタックにはlwIPを、クラスタHMI用のMCUにはQtを使用しています。
システム仕様:
ホストMCU: NXP i.MX RT1176
Wi-Fiモジュール: u-blox MAYA-W161(SDIOインターフェース)
ディスプレイ: LCDIFV2(パラレルRGBインターフェース)
OS: FreeRTOS
問題点:グラフィック処理の負荷と直接関係していると思われる、断続的なWi-Fi接続切断が発生しています。Wi-Fi接続が切断されるのは、ディスプレイがリソースを大量に消費するGUI(多数の要素やアニメーションを含む)を実行している場合のみです。軽量なUIに切り替えても、Wi-Fi接続は完全に安定します。
この問題を解決するためのご指導をお願いいたします。
よろしくお願いいたします。
ヴィグネシュ
こんにちは、 @Vignesh_Vinayak さん。お元気でお過ごしでしょうか。
画像プロセッシングは高いCPU使用率と大きなメモリ使用量を必要とするため、GUI関連アプリケーションでは、2つのコアのうち1つがインターフェース管理に専用であることが想定されています。貴社の実装方法では、2つのコアを使用しているかどうかを明確にしていただけますか?各スレッドごとに十分なスタックがありますか?
さらに、Wi-Fiスタックでデバッグログを有効にした状態でログを共有していただけますか?Wi-Fi Threadの状態をさらに分析するために。デバッグログを有効にするには、wifi_config.hの「CONFIG_WLCMGR_DEBUG」と「CONFIG_WIFI_SDIO_DEBUG」マクロを有効にしてくださいヘッダーファイル?
こんにちは、 @RomanVR さん。
こんなに早く返信してくれてありがとうございます。
ご依頼いただいた詳細情報とログは以下のとおりです。
現在、私たちのプロジェクトはCortex-M7コアのみを使用しています。M4コアは利用されていません。
はい、すべてのスレッドには十分なスタックが割り当てられています。また、FreeRTOSのスタックオーバーフローフック関数を使用して確認したところ、オーバーフローは発生していませんでした。
提案されたマクロを有効にしたログファイルを添付しました。ログ内には、最終的なWLCMログ以降に表示されるすべてのログがアプリケーションログで構成されており、Wi-Fiパケットが受信されるたびにランダムなフレームサイズを単に印刷します。ご覧の通り、ログはある時点で止まります。そこでWi-Fiが切断されます。接続が切断された時点では、wlcmからもSDIOからもログは出力されていません。
よろしくお願いします、
ヴィグネシュ。
こんにちは、 @Vignesh_Vinayak さん。
切断が起きた後、ディスプレイを含む他のアプリケーションは正常に動作しているのか教えていただけますか?もしそうなら、スレッドの優先度設定を共有していただけませんか?
前の質問に関連して、実行中のスレッドのFreeRTOSランタイム統計を共有していただけますか?
そのためには、 FreeRTOSConfig.hで「configGENERATE_RUN_TIME_STATS」を有効にする必要があります。ファイルを作成し、FreeRTOS API「vTaskGetRunTimeStats」を定期的に呼び出し、結果をターミナルに出力するタスクを定義します。これにより、各ThreadのCPU使用率に関する有用な情報が得られ、Wi-Fi切断の根本原因を絞り込むことができます。これに関連して、ディスプレイアプリケーションは高いCPU負荷を引き起こすため、高負荷アプリケーションの適切な実行を確保するためにデュアルコアアーキテクチャの実装が強く推奨されます。