Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
RT1170 MIPI-CSI カメラ - YUV422 (8 ビット) サポート こんにちは、 i.MX RT1170 MIPI-CSI インターフェースを使用して YUV422 (8 ビット) を出力するカメラ モジュールの使用方法を示すリファレンス デザイン、アプリケーション ノート、またはサンプル プロジェクトはありますか? RT1170 エラッタ ( https://www.nxp.com/docs/en/errata/IMXRT1170ACE.pdf ) を確認し、YUV422 10 ビット形式はサポートされていないことを理解しましたが、YUV422 8 ビット操作を具体的に示す公開例や確認は見つかりませんでした。 あらゆるガイダンス、動作が確認されている構成、またはカメラ モジュールの例があれば、大変助かります。 Re: RT1170 MIPI-CSI Camera - YUV422 (8 bit) support こんにちは@mtreloarさん、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 RT1170 MIPI-CSI は YUV422 (YUYV 8 ビット) 形式をサポートします。SDK のこのサンプル プロジェクトを参照できます。 よろしくお願いします、 ギャビン
查看全文
eRPCの紹介 このチュートリアルでは、eRPC(埋め込みリモートプロシージャコール)オープンソースプロジェクトを紹介します。 eRPC(Embedded Remote Procedure Call)は、NXPが作成したリモートプロシージャコール(RPC)システムです。RPC は、単純なローカル関数呼び出しを使用してリモートシステム上のソフトウェアルーチンを呼び出すためのメカニズムです。リモートシステムは、ネットワーク経由のサーバー、マルチコアシステム内の別の CPU コアなど、任意の通信チャネルによって接続された任意の CPU です。クライアントにとっては、アプリケーションに組み込まれているライブラリの関数を呼び出すのと同じようなものです。唯一の違いは、通信チャネルによって生じる遅延や信頼性の低下です。 重要なリンク: eRPC 開発に関連するすべてのものはGitHub - eRPC baseに公開されています。 eRPC開発はGitHub - eRPC開発に公開されています。 eRPC のリリースはGitHub - eRPC Releasesに公開されています。 eRPCのドキュメントはGitHub - eRPC wikiに公開されています。 pypiでのeRPC PythonパッケージとしてのeRPC eRPC は、マルチコアおよびマルチプロセッサタイプのアプリケーションをサポートしています。 eRPCの例が見つかる場所 NXP MCUXpressoSDK パッケージには、eRPC マルチコアおよびマルチプロセッサの例が豊富に含まれています。これらのパッケージを構成、ビルド、ダウンロードするには、https://mcuxpresso.nxp.comにアクセスしてください。 マルチコアサポート(eRPCを含む)を備えたボードリストを取得するには、ミドルウェアに基づくフィルタリングを使用し、「multicore」という文字列を検索してください。選択したマルチコアミドルウェアを含むパッケージをダウンロードしたら、 /boards/ /multicore_examples で eRPC マルチコアの例 (RPMsg_Lite またはメッセージングユニットトランスポートを使用) または /boards/ /multiprocessor_examples で eRPC マルチプロセッサの例 (UART または SPI トランスポートを使用) を参照してください。 eRPC の例では、「erpc_」という名前のプレフィックスを使用しています。 NXP MCUXpressoSDK eRPC マルチコアおよびマルチプロセッサの例を取得するもう1つの方法としては、mcux-sdk Github リポジトリを使用します。West ツールを使用して mcuxsdk リポジトリを複製および更新する方法については、readme の「概要」セクションの説明に従ってください。完了すると、armgcc eRPCの例は mcuxsdk/examples/ /multicore_examples または mcuxsdk/examples/ /multiprocessor_examples フォルダで見つかります。 例えば、board_name として evkmimxrt1170 を使用することができます。MCUXpressoSDK パッケージと同様に、eRPC の例では「erpc_」という名前のプレフィックスを使用します。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kunal様、あなたの質問がこちらで取り上げられているようです。 eRPCをiMx6sxに実装するためのステップバイステップの手順が必要です。 · 問題 #5 · EmbeddedRPC/erpc-imx-demos · GitHub  Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI [email protected]‌, MPC5748GでのeRPCの公式な使用法についてはわかりません。念のために言っておくと、eRPCはプログラム言語、OS、トランスポート層に依存します。ボード固有のファイルはありません。したがって、FreertosとC言語が使用されている場合、ほぼ問題なく動作します。必要なのは、使用したいトランスポートを移植することだけです(まだである場合)。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan,       eRPCはNXP MPC5748Gに移植されていますか?参照できるサンプルコードはありますか? よろしくお願いいたします。 Alex Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected], 私はこの分野での経験があまりありません。最近、複数のタスクから複数のerpc呼び出しが行われた際に、いくつかのミューテックスを追加する必要がありました。でも、あなたのアイデアは気に入りました。 すぐにソースコードを確認しましたが、ユースケースを指定する必要があります。しかし、これは RPSMG を使用する Mcore と iMX Linux のどちらが優れているかの問題だと思います。この場合、私たちと同じようにミューテックスを追加できると思います(これにより、eRPC呼び出しがシリアル化されます。performRequest 関数のどこかに追加する必要があります。)スレッドごとにエンドポイントを作成するのは良さそうに聞こえますが、解決しなければならない問題がまだあります。より小さなソリューションは次のようになります。トランスポート初期化関数は(タスクの数に基づいて)より多くのエンドポイントを初期化し、クライアント側のeRPC rpmsg送受信機能を未使用のエンドポイントを使用して送信し、同じエンドポイントを使用してメッセージを受信するように変更し、サーバーのeRPC rpmsg受信機能はすべてのエンドポイントでメッセージを待つ必要があります。 あなたにとってこれが簡単な作業なのか、それとももっと複雑な作業なのかわかりませんが、コードを変更しないとマルチスレッド呼び出しができなくなるのではないか心配です。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 私はここCubicでチャンディーニと一緒に働いています。複数のスレッドから呼び出されたときに、eRPCに関する追加情報を取得したいと思いました。現在、私たちは単一のエンドポイントを使用しており、次の呼び出しを行う前に完了する一度限りの呼び出しに、これを使用しています。現在、複数のスレッドから複数の呼び出しを行う可能性があるため、これを行う最善の方法を検討しています。 実際、私の知識不足から、同時に他の電話をかけてみましたが、問題が発生するまでそれを行っていることに気づきませんでした。 現在、eRPCから通信失敗エラーコードが返されていることが確認できます。 これには単一のエンドポイントを使用できますか。つまり、クライアント側でスレッドセーフにすべきでしょうか。 そうでない場合、スレッドごとに別々のエンドポイントを使用すべきでしょうか。 それとも、何か他のことをすべきでしょうか? よろしくお願いします。 リー Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected]‌, お知らせいただきありがとうございます。面白いですね、今日は別のプロジェクトでこのことを読みました(笑顔の顔文字) Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, 迅速なご返信をありがとうございます。 クライアントとサーバーの両方のソケット接続で以下の API 呼び出しを使用して Nagle アルゴリズムを無効にすることで、TCP でより良いパフォーマンス(マイクロ秒単位の応答)を実現できました。 int result = setsockopt(sock, /* 影響を受けるソケット */                         IPPROTO_TCP,     /* TCPレベルでオプションを設定する */                         TCP_NODELAY,     /* オプションの名前 */ (char *) &flag、/* キャストは歴史的な名残です */                         sizeof(int));    /* オプション値の長さ */ 参考資料: TCP_NODELAY: 2018年のTCP最適化のベストプラクティス | ExtraHop ありがとうございます サシダラン。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi [email protected]‌, おそらくGitHubで(同じトピックで、または新しいトピックを作成して)質問すると良いでしょう。TCP を使って何かをしている人が少なくとも 2 人います。 github: GitHub - EmbeddedRPC/erpc: Embedded RPC スレッド1:複数の接続を処理する TCP トランスポートを備えたサーバー · 問題 #32 · EmbeddedRPC/erpc · GitHub スレッド2: TCP サンプルクライアント/サーバーコード · 問題 #39 · EmbeddedRPC/erpc · GitHub 個人的にこれを見つけましたが、これがあなたのケースに当てはまるか、役立つかどうかはわかりません: linux - Ubuntuでの低遅延TCP設定 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, eRPCをTCPソケットに移植したいと思います。 仮想シリアル(Linux内)でサンプルテストコード(test_arrays)を実行したところ、シリアルの応答時間は1ミリ秒未満でした。 同じサンプルコードをTCP経由で実行したところ、TCPの応答時間は約90ミリ秒でした。 遅延を減らし、シリアルと同様に TCP 上のパフォーマンスを向上させる方法はありますか。 ありがとうございます サシダラン。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi, Dusan. 助かりました。ちなみに、ヘッダーファイルに例が挙げられていました。 A9 からの関数呼び出しは正常に動作し、M4 はデータを返します。 しかし、現在の問題はM4が関数を呼び出すときに発生します。エラーがA9に表示されています。「MU送信バッファ空のタイムアウトが発生しました。 うーん、imx_mu_rpmsg_send()が失敗しました:-5」。  このエラーの後、他の側でもデータ関数の呼び出しが機能しなくなります: 「rpmsg_multiept rpmsg0: virtqueue_add_outbuf failed: -5」 何を確認すればよいでしょうか? ご協力ありがとうございます。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim, 一般的には2つのタスクが必要です。1つはクライアント用、もう1つはサーバー用です。問題は、erpc_arbitrated_client_initからの出力をinitサーバーのパラメータとして設定する必要があることです。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、ドゥシャンさん、マレクさん、コミュニティの皆様。 eRPC を使用していくつかのアプリケーションを作成しました。M4(クライアント)-A9(サーバー)または M4(サーバー)-A9(クライアント)は問題なく動作しますが、各側でクライアント/サーバーアプリケーションを使用したいと考えています。しかし、今は動作しておらず、片側からの機能が1回しか実行されず、アプリケーションがハングします。 コードの全体的な構造を確認したいです。 何が問題なのでしょう。 M4上でクライアントとサーバーに2つの別々のFreeRTOSタスクを使用すべきですか。 M4 . . erpc_transport_t transport = erpc_transport_rpmsg_lite_rtos_remote_init(.....); erpc_mbf_t message_buffer_factory = erpc_mbf_rpmsg_init(transport); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function1(....); } A9 . . erpc_transport_t transport = erpc_transport_rpmsg_linux_init(......); erpc_mbf_t message_buffer_factory = erpc_mbf_dynamic_init(); erpc_server_init(transport, message_buffer_factory); erpc_add_service_to_server(create_TEST_service()); erpc_arbitrated_client_init(transport, message_buffer_factory); while (true) { erpc_server_poll(); function2(....); } Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> vadimfilippenko様、Python バージョンの使用にまだ興味がある場合は、こちらのスレッド「MPU パッチをカーネルに追加する - 新しいモジュールが表示されません · 問題 #2 · EmbeddedRPC/erpc-imx-demos · GitHub」をご覧ください。mhanuel26の少なくとも最後の2つのメッセージ では、Pythonアプリケーションを使用できているということですので、あなたにとって興味深い内容となっているでしょう。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Dusan, Marek, ついに、修正されたeRPCの例を正常に起動することができました。しかし、Linux側ではCを使用し、M4では6つのパラメーターを持つerpc 1.5.0のrpmsg初期化関数を使用しています(6番目のパラメーターに関するDusanのヒントはGitHubにあります)。サポートありがとうございます。まだ質問させていただきます。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Python アプリの前に M4 アプリを実行する必要があります。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim, こちらに投稿してください:ls /sys/class/rpmsg ネームサービスが M4 から送信されなかったようです (M4 は正しいファームウェアで実行されていますか?)。このため、M4から動的にアナウンスされたチャネルを持つフォルダが作成されなかったため、Pythonはrpmsgトランスポートを作成できません...M4コアの出力を確認してください。よろしくお願いします。 Marek Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vadim,  他のコメントをご覧のとおり、できるだけ早く回答するよう努めておりますが、今週(そしておそらく来週)は忙しくしております。 ただ、私がエラーで見たところでは、transport.py 内の RpmsgTransport クラスにある init 関数を比較する必要があります。 こちらもご確認ください。 erpc-imx-demos/sysfs.py at master · EmbeddedRPC/erpc-imx-demos · GitHub   - クラス RpmsgEndpoint GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices が最新であり、サブリポジトリが erpc-imx-demos と整合しており、コミット時にチェックアウトされていることを確認してください。 おそらく、ここで何が問題なのか、mareknovakが教えてくれるでしょう。 以下のようになります。 if self.id == -1: raise Exception() is returning -1 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以下の問題について、どなたかお手伝いいただけますか。 私は、iMX6COM ボード上の erpc-imx-demos から eRPC デモの例を使用しています。 M4側でデモアプリケーションを開始しています。 "ハードウェアが初期化されました eRPCが初期化されました MatrixMultiplyサービスが追加されました" Linuxでドライバーを追加中です。 "root@imx6sxea-com:~# modprobe -v rpmsg_multiept insmod /lib/modules/4.1.15-2.0.3+geb0b90b/kernel/drivers/rpmsg/rpmsg_multiept.ko" (システムから、rpmsgチャネルが作成されたことや、sys/class/rpmsgの下のrpmsgフォルダが空であることに関するフィードバックはありません) Linuxでapplデモを開始します。 トレースバック(最後の呼び出し): ファイル「example.py」、 の111 行目 transport = erpc.transport.RpmsgTransport() ファイル「build/bdist.linux-armv7l/egg/erpc/transport.py」、__init__の199行目 ファイル「build/bdist.linux-armv7l/egg/rpmsg/sysfs.py」__init__ の116行目 例外 例外タイプエラー: > の 追伸: cmake と eclipse を使用してM4 eRPC デモアプリを作成しました。 M4 rpmsg デモアプリケーションは正常に動作しています。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Vakul, 申し訳ありません、コメントを見逃しました。現在、暗号化トランスポートはサポートされていません。しかし、eRPC はモジュール式であるため、この機能を eRPC プロジェクトに簡単に追加できると思います。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi eRPC通信は、何らかの暗号化通信プロトコルを使用して保護できますか(例:TLS)。 よろしくお願いします。 Vakul Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、Evgenyさん。現時点ではその見積もりはありません。しかし、erpc_malloc/erpc_free関数の独自の実装を書くことで、独自のアロケータを作成または使用できると考えています。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, erpcMatrixMultiply_shim の生成された同等物など、追加部分に静的メモリ割り当てを追加する予定はありますか。すべての入力引数が、コーデックからデータを入力する前に動的に割り当てられ、関数呼び出し後に解放される場所のはどこですか。 事前に割り当てられたメモリを(ユーザーアプリによって静的に)フレームワークに渡すようなものですか。 ありがとうございます Evgeny Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Evgeny様、これは MCUExpresso プロジェクトファイル/IDE の問題のようです。フォルダー名の最上位層は仮想ディレクトリである必要があり、将来的にはそこに表示されなくなります。ディスク上のパッケージでは、eRPCはGitHubと同様のディレクトリ構造を持つ必要があります。Github のディレクトリ構造が推奨されています。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan, erpc は実行時に大量の動的メモリ割り当てを使用しているようです。さらに組み込み向けにして、静的メモリ割り当てスキームを追加する予定はありますか。 編集: 最初の質問についてですが、申し訳ありません。リポジトリに erpc_setup_mbf_static.cpp があるのは確認できました。問題は、私のコードはMCUXpresso SDK-frdmk66f_multiprocessor_examples_erpc_server_matrix_multiply_spi & frdmk66f_multiprocessor_examples_erpc_client_matrix_multiply_spiで提供されている例に基づいて作成されているということです。リポジトリ内のコードとはディレクトリ構造がまったく異なります。 再度確認させていただきます。SDKサンプルのディレクトリ構造を使用するべきか、それともリポジトリを使用するべきかですか。これらは大きく違うのですか。 ありがとうございます Evgeny  Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Evgeny, まず、開発ブランチのsmac.erpc(およびここでビルドされたアプリ)を使用していますか。私の場合、このバージョンが動作しています。 現在、erpcgen アプリのバージョンと残りの eRPC コードが接続されています。ですから、GitHubからビルドした新しいerpcgenアプリを使用する場合は、GitHubのerpc_c/*ファイルをGitHubから例にコピーする必要があります。その後、新しい erpcgen アプリでコードを再生成し、アプリケーション(erpc init + transport)関数を更新すれば、すべてが正常に機能するはずです。そうではなく、erpc_c ファイルを更新しない場合は、提供されている erpcgen アプリを使用する必要があります。 このページの下部「はじめに · EmbeddedRPC/erpc Wiki · GitHub」をご覧ください。新しい erpcgen バージョンでは最新の状態になっているはずです。 確証はありませんが、最新のコミットで SPI が変更される可能性があるため、代わりに古い実装を使用してください。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hey Dusan, 私がビルドした erpcgen.exe を使用すると、smac.erpc の例で同じエラーが発生します。 エラー: ファイル smac.erpc:135:5: 構文エラー、予期しない識別子、'}' を期待しています 私が言及していたディレクトリ構造は、リポジトリの erpc_c で、次のとおりです。 SDKのサンプルでは、どのディレクトリ構造が正しいのでしょうか。新しく生成したファイル(私が作成したもの)を SDK のサンプルコードで使用しても安全でしょうか。 ありがとうございます Evgeny Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi evgenyerlihman‌, 推奨されるコードは常に GitHub の develop ブランチにあります。このコードが新規リリースの要件を満たしたら、マスターブランチにマージし、アプリケーションのバイナリも提供します。開発ブランチでのこれらの更新は、Kinetis SDK のリリースよりも頻繁に行われます。既存の eRPC トランスポートが Kinetis SDK で使用されているトランスポートのバージョンと一致しない場合は、古い eRPC トランスポートと新しいものを比較するか、git リポジトリでファイルの変更を確認できます。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hey dusancervenka-b51352, 迅速なご返信ありがとうございます。devブランチをクローンしました。erpc_c ディレクトリ構造が Kinetis SDK に付属する例とは大きく異なることがわかります。どちらが好ましいですか。 ありがとうございます Evgeny Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi evgenyerlihman‌, 実のところ、より頻繁に更新を行っています。ブランチを開発するにはスイッチが必要です。 GitHub - EmbeddedRPC/erpc at develop. 最後のコード更新は昨日でした。ただし、そこで erpcgen アプリケーションをビルドする必要があります。そのsmacでIDLは動作するはずです。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi dusancervenka-b51352, 複数の NXP Kinetis デバイスを使用する新製品に erpc フレームワークを使用することを検討しています。erpc GitHubの最終更新は6か月前に行われたようです。お尋ねしたいのは、これがまだ保守/修正/開発されているのかどうかです。GitHubのサンプルを試しました。 erpcgen.exe smac.erpc エラーが発生し、cppソースコードの生成に失敗しました。 erpcgen 実行可能ファイルは、MCUXpresso SDKからのものです。 ありがとうございます Evgeny Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、チャンディーニさん 大丈夫です。私も長期休暇中でした。楽しんでいただけたのであれば幸いです。 コミュニティ・メッセージング・システム (プライベート・メッセージ) を通じてあなたにメールを送りました。 メールで詳細を話し合うことができます。基本的には、GitHubでフォークを作成し、開発ブランチにチェックアウトし、変更を適用し、コミットを作成し、プルリクエストを作成する必要があります。私たちはあなたの変更を確認し、変更を提案し、開発ブランチにマージします。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , ご返信が遅くなり、申し訳ございません。長期休暇を取っていました。戻ってきましたところで、ここにいるメンバーと相談しました。リソースを転送できるように、メールアドレスを教えていただけますか。NXPの方針で、あなたの GitHub に直接入れることができません。 よろしくお願い申し上げます。 チャンディーニ Re: Introducing eRPC こんにちは、ドゥサンさん はい、先輩に相談してプルリクエストを作成します。現在休暇中です。返信が遅くなり申し訳ありません。 よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Chandini様、ご成功を収められたことを嬉しく思います。もし特別な提案をさせていただけるなら、新しく作成したトランスポートレイヤーを使用して、eRPCのGitHubの開発ブランチにプルリクエストを送信していただけますか。新しい eRPC で動作させるには、多少の作業が必要になるかもしれません。しかし、あなたがそれを更新したくない場合は、こちらでそれを行うことができます。(ウィンクの顔文字) GitHubのプルリクエストを使用すれば、コントリビューター履歴に常に表示される貴重なコントリビューターになっていただけます。eRPC があなたにとって良い解決策となることを願っております。いつでもこちら/または GitHub よりお手伝いさせていただきます(ウインクの顔文字) Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi dusancervenka-b51352 , b50844 , novakma7   ようやく動作しました。LinuxでC++コードを使ってデモが正常に動作しています。 質問にすべて答えてくださり、本当にありがとうございます。(笑顔の顔文字) Dusan様に感謝いたします。(笑顔の顔文字) よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI Dusan , 他の作業で忙しかったので、昨日は何も試すことができませんでした。今日は試してみて、結果をを知らせします。 自分の機能を少し変えて試してみる必要があると思います。これまでは、送信関数と受信関数に char* だけを渡していました。 すぐにご連絡いたします。 よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Chandini様、その通りです。社外にいたので、機能の正確な名前はわかりませんでした。あなたの場合、これはうまく動作していますか。 Re: Introducing eRPC こんにちは、ドゥサン お返事ありがとうございます : write(fd, message->getBuffer() , message->getUsed()😞 9e18d069aeae19a6e80a5e8783903bc63bd9b567 · EmbeddedRPC/erpc · GitHub の erpc/ message_buffer.h に getused 関数が記載されていますが、getbuffer 関数は見つかりませんでした。 バッファを取得するには以下の関数を使用する必要があると思います。これは正しいでしょうか。 /*! * @brief この関数は、読み取り/書き込み用のバッファへのポインターを返します。 * * @return 読み取り/書き込みするバッファへのポインタ。 */ uint8_t *get() { m_buf を返します; } そしで、私の関数は次のようになります。 send :erpc_status_t send(MessageBuffer *message) { write(fd, message->get, message->getUsed())};  よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、chanidi さん。別の方法で行う必要があります。transport.h を使用しなければなりません。それを使わないと、うまくいきません。 おそらく、前述のように ioctl コマンドを使用することができるでしょう。 erpc_status_t receive(MessageBuffer *message) {int fd = open("/dev/rpmsg_ept1024.1", O_RDWR);} 送信 :erpc_status_t send(MessageBuffer *message) { write(fd, message->getBuffer(), message->getUsed())}; 読み取り: erpc_status_t receive(MessageBuffer *message){size_t size = read(fd, message->getBuffer(), 500);message->setUsed(size)}; novakma7 手順を確認いただけますか。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Dusan , Marek はい、私もそのファイルを言及していますが、 trasport.hを使用して、トランスポートレイヤーを作成しています。しかし、引数の不一致の問題に直面しています。 transport.h の send 関数と receive 関数はMessagebufferを引数として取ります。          virtual erpc_status_t receive(MessageBuffer *message) = 0;          virtual erpc_status_t send(MessageBuffer *message) = 0; example.py に従って、以下の引数が必要な RPMSGendPoint クラスを作成しました。       RpmsgEndpoint::receive(int maxlen) RpmsgEndpoint::send(char *buffer,int dst) 私の理解では、Linuxから /dev/rpmsg_ept1024.1デバイスを読み書きするだけでよいと考えています。   ですから、transport.h を使用する代わりに、独自の transport.h バージョンを作成する必要があるのではないかと考えています。 皆様、ありがとうございました。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> どういたしまして。/erpc-imx-demos/middleware/erpc/transport/フォルダからヒントを得ることができます。いくつかのトランスポート手段があります。 Re: Introducing eRPC ドゥサンさん、早速返信ありがとうございます それで、私は同じ道を進み続け、すぐにあなたに戻ってきます。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Chandini様、おっしゃる通り、それが正しい手順です。transport.h からクラスを継承するクラスを作成する必要があります。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Marek 私は再び質問があります。 現時点の作業のステータスは以下の通りです。 C++でRpmsgEndpointクラスを取得しました。 現在、クライアントアプリケーションを動作させる方法を検討しています。 erpc-imx-demos/MPU/example_erpc at master · EmbeddedRPC/erpc-imx-demos · GitHub の Python example.py で、Transport クラスから継承された RpmsgTransport を呼び出します。 transport.hを使用すべきかどうかというのが質問です。これは、/erpc-imx-demos/middleware/erpc/erpc_c/infra にあり、アプリケーションを動作させています。 そうすることで、RpmsgTransport クラスを作成し、これをクライアントアプリケーションと呼ぶことができるようになります。 この考え方で正しいでしょうか。 よろしくお願いいたします チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> はい、その通りです。 Python が行うのは、ファイルに対する IO 操作(読み取り/書き込み)だけです。これは C/C++ を含むあらゆる言語で実行できます。Python は、Linux ユーザースペースでの人気から、実行方法をを示すために選ばれましたが、もちろん C に移植することも可能です。 これで認識が一致していると思います。 幸運を祈っています。 これからもよろしくお願いいたします。 Marek Re: Introducing eRPC こんにちは、マレク ご返信ありがとうございます。疑問がいくつか解消されました。 freeRTOSを両方使う予定はありません。 私たちのプランは次のようなものです。   M4-FreeRTOS ----これはお客様のデモにあります。 A7-Linux -----デモにはカーネルRPMSG実装を利用するためのPythonコードが含まれています。   私たちに必要なのは、PythonではなくCまたはC++です。 PythonコードはCまたはC++に簡単に移植できるのですよね。 よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちはチャンディーニ・インダバラ・バサヴァラジュさん、 RPMSg-Lite は RPMsg プロトコルの実装であり、FreeRTOS またはベアメタルを実行する M4 側のみを対象としています。Linux/A7 側では、カーネル内の RPMsg 実装で問題ないでしょう。(こちらにある通りです: GitHub - EmbeddedRPC/erpc-imx-demos: i.MX デバイス用の eRPC デモ) それとも、M4コアとA7コアの両方でFreeRTOSを実行する予定ですか。その場合も機能しますが、これは標準的なユースケースではありません。Aコア用の移植レイヤーを作成し、そこでFreeRTOSを実行する必要があります。 これで何らかの方向性が見えることを願っております。 Marek Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Marek どういうわけかあなたのメッセージを見逃してしまいました。申し訳ありません。 どうもありがとうございます。(笑顔の顔文字)すぐに新しいバージョンを試してみます。 RPMSG トランスポート層に関する最後の質問にお答えいただけますか。 ありがとうございます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、分かりました。 新しいものを作成する必要があります(また、GitHubのプルリクエストを使用して、必要に応じてリポジトリに追加できます)。 Linux 側では、/dev/ttyRPMSG を使用できます(システムに存在する場合)。   たとえば、こちらの erpc_c/transports で新しいトランスポートを作成します。 init は次のようになります: int fd = open("/dev/ttyRPMSG", O_RDWR); 送信:write(fd, buffer, buffer_size); read: size_t size = read(fd, buffer, 予想サイズ); このように名前が付けられたデバイスがない場合は、Python コードからヒントを得ることができます。RPMSGは私の好みではありません。Linuxでどのように使用すべきかわかりません。ご質問をMarekに転送します。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , Marek 私が計画していること: M4(freertos)およびA7(Linux)の両方でrpmsg-liteを使用する 必要なもの M4とA7の両方で使用できるRPMSG Cラッパー(erpc_c/setup内) M4とA7の両方で使用できるRPMSGトランスポートレイヤー(erpc_c/transports内) 質問があります。 教えていただけますか、そのためのトランスポート層をお持ちですか? または rpmsg-pythonを参照して同様に記述する必要がありますか。 どんのようなご提案でもとても役立ちます。 皆様、ありがとうございました。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは。必要なもの(Linux側用のCトランスポート)があるかどうかわかりませんが、新しいものを作成するのは簡単なはずです。/dev/ttyRPMSG から読み取りと書き込みができます(システムに存在する場合)。 以下にその例をご紹介します。 init は次のように見えます: int fd = open("/dev/ttyRPMSG", O_RDWR); 送信:write(fd, buffer, buffer_size); read: size_t size = read(fd, buffer, expected size) mareknovakがこの問題にさらに答えをくれるはずです。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan , アップデートについてお知らせいただき、ありがとうございます。 今は手元にあるerpcで大丈夫だと思います。rpmsgクライアントアプリケーションが動作するようになったら、erpcのバージョンも更新できます。 rpmsg-lite、M4プラットフォームファイルを含むものを探していたところです。 A7プラットフォーム用の製品はありますか。あるいは、何か情報があれば大変助かります。主な目的は、トランスポートレイヤーとしてRPMSgを使用し、C言語でクライアントアプリケーションを作成することです よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ご自分で問題解決を進めておられるとのこと、嬉しく思います(開発者にとってそれほど複雑ではないということでしょうから)。また、mareknovakは、上記のコメントで言及されている通り、リポジトリ内の imx デモアプリケーションをすでに更新しています。次のステップでは、新しいRPC機能を使用しているため、そのバージョンをお使いいただけます。(ウィンクの絵文字) Re: Introducing eRPC 返信ありがとうございます、ドゥサン それが私が探していた情報です。TCP用のCラッパーを作成し、erpcでいくつか修正した後、うまくいきました。 次のステップは、TCP層をrpmsgに置き換えることです。 再度ありがとうございます チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちはチャンディーニ・インダバラ・バサヴァラジュさん、 GitHub - EmbeddedRPC/erpc-imx-demos: eRPC demos for i.MX devices リポジトリが eRPC 1.4.0 と RPMSg-Lite 1.1.0 を使用するように更新しました。 コード生成に使用されるビルド済みの erpcgen アプリケーションをこちらからダウンロードできます: Release v1.4 · EmbeddedRPC/erpc · GitHub  ダウンロードセクションで、アーキテクチャを選択してください。 その後、./erpcgen-gpy nameOfInterfaceDefinitionLanguageFile.erpc のように呼び出します。ERPC、Pythonのシリアル化と逆シリアル化のシムコードが生成されます。-gpy を省略するか、-gc を指定すると、C シムコードが得られます。 ser/des shimコードもerpc-imx-demosリポジトリの最新のコミットで更新されているので、気軽にご利用ください。 プルリクエストの形で変更を送信してください。 よろしくお願いいたします。eRPC & RPMsg-Liteをご利用いただきありがとうございます。 Marek Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、現在githubリポジトリに例がありませんが、C(c ++)テストがあります。Linux または Mac に慣れていれば、それを例として使用できます。その他のオプションは上記の通りです。 1. サポートされているボード用の SDK をダウンロード -> マルチコア・マルチプロセッサ C/Python の例。 2. この記事をお読みください:はじめに · EmbeddedRPC/erpc Wiki · GitHub Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan PythonではなくCのクライアントアプリケーションのサンプルがあるか、あるいは、作成の予定があるか教えていただけますかすでにあれば、とても便利で役に立ちます。 よろしくお願いいたします チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ようやく動くようになりました。ご協力いただき、ありがとうございます。(笑顔の顔文字) Dusan 申し訳ありませんが、パッチを添付するためのオプションが見つかりませんでした。以下に貼り付けました。 From 7a5b152524a3c82b5bced4a72ed396f21860b666 Mon Sep 17 00:00:00 2001 日付: 2017年5月8日(月)11:33:05 +0100 件名: [PATCH] eRPC_demo実行のための修正 --- erpc_c/infra/transport.h | 4 +- erpc_c/setup/erpc_server_setup.cpp | 36 ++++- erpc_c/setup/erpc_server_setup.h | 2 +- erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp | 54 +++++++ erpc_c/setup/erpc_transport_setup.h | 18 ++- erpc_c/transports/rpmsg_lite_rtos_transport.cpp | 158 ++++++++++++++++++ erpc_c/transports/rpmsg_lite_rtos_transport.h | 177 +++++++++++++++++++++ erpc_c/transports/rpmsg_rtos_transport.h |147 +++++++++++++++++ erpc_python/erpc/transport.py | 21 +++ 9 ファイル変更、602 挿入(+)、15 削除(-) 作成モード 100644 erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp 作成モード 100644 erpc_c/transports/rpmsg_lite_rtos_transport.cpp 作成モード 100644 erpc_c/transports/rpmsg_lite_rtos_transport.h 作成モード 100644 erpc_c/transports/rpmsg_rtos_transport.h diff --git a/erpc_c/infra/transport.h b/erpc_c/infra/transport.h index eb7ec71..fd4862a 100644 --- a/erpc_c/infra/transport.h +++ b/erpc_c/infra/transport.h @@ -48,7 +48,7 @@ //////////////////////////////////////////////////////////////////////////////// namespace erpc { - +class MessageBuffer; /*! * @brief トランスポートレイヤーの抽象インターフェース。 * @@ -89,7 +89,7 @@ public: * * @return 送信の実装に基づいています。 */ - virtual erpc_status_t send(MessageBuffer *message) = 0; + virtual erpc_status_t send(const MessageBuffer *message) = 0; /*! * @brief 受信メッセージをポーリングします。 diff --git a/erpc_c/setup/erpc_server_setup.cpp b/erpc_c/setup/erpc_server_setup.cpp index 51fa799..5cd4346 100644 --- a/erpc_c/setup/erpc_server_setup.cpp +++ b/erpc_c/setup/erpc_server_setup.cpp @@ -33,8 +33,10 @@ #include "basic_codec.h" #include "manually_constructed.h" #include "simple_server.h" -#include +#include "message_buffer.h" +#include "erpc_config_internal.h" #include +#include #if !(__embedded_cplusplus) using namespace std; @@ -43,6 +45,29 @@ using namespace std; using namespace erpc; //////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +class BasicMessageBufferFactory : public MessageBufferFactory +{ +public: + virtual MessageBuffer create() + { + uint8_t *buf = new (nothrow) uint8_t[ERPC_DEFAULT_BUFFER_SIZE]; + return MessageBuffer(buf, ERPC_DEFAULT_BUFFER_SIZE); + } + + virtual void dispose(MessageBuffer *buf) + { + assert(buf); + if (*buf) + { + delete[] buf->get(); + } + } +}; + +//////////////////////////////////////////////////////////////////////////////// // Variables //////////////////////////////////////////////////////////////////////////////// @@ -50,29 +75,32 @@ using namespace erpc; static ManuallyConstructed s_server; SimpleServer *g_server; +static ManuallyConstructed s_msgFactory; static ManuallyConstructed s_codecFactory; //////////////////////////////////////////////////////////////////////////////// // Code //////////////////////////////////////////////////////////////////////////////// -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory) +void erpc_server_init(erpc_transport_t transport) { // ファクトリを初期化します。 + s_msgFactory.construct(); s_codecFactory.construct(); // 提供されたトランスポートでサーバーを初期化します。s_server.construct(); s_server->setTransport(reinterpret_cast (transport)); + s_server->setMessageBufferFactory(s_msgFactory); s_server->setCodecFactory(s_codecFactory); - s_server->setMessageBufferFactory(reinterpret_cast (message_buffer_factory)); g_server = s_server; } - void erpc_server_deinit() { + s_msgFactory.destroy(); s_codecFactory.destroy(); s_server.destroy(); + } void erpc_add_service_to_server(void *service) diff --git a/erpc_c/setup/erpc_server_setup.h b/erpc_c/setup/erpc_server_setup.h インデックス 8e6a6ef..e4e9eaa 100644 --- a/erpc_c/setup/erpc_server_setup.h +++ b/erpc_c/setup/erpc_server_setup.h @@ -60,7 +60,7 @@ extern "C" { * * この関数は、サーバーの実行に必要なすべてのコンポーネントを使用してサーバーを初期化します。 */ -void erpc_server_init(erpc_transport_t transport, erpc_mbf_t message_buffer_factory); +void erpc_server_init(erpc_transport_t transport); /*! * @brief この関数はサーバーの初期化を解除します。 diff --git a/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp new file mode 100644 index 0000000..b480d42 --- /dev/null +++ b/erpc_c/setup/erpc_setup_rpmsg_lite_rtos_remote.cpp @@ -0,0 +1,54 @@ + /* + * Copyright (c) 2014-2016, Freescale Semiconductor, Inc. + * + * ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、+ * 以下の条件を満たしている場合に限り許可されます。 + *+ * o ソースコードの再配布には、上記の著作権表示、この条件の一覧、および + * 以下の免責事項を含める必要があります。 + * + * o バイナリ形式での再配布では、上記の著作権表示、この + * 条件リスト、 および以下の免責事項をドキュメントおよび/または 配布物に付属する他の資料に複製する必要があります。+ * + * o Freescale Semiconductor, Inc.の名前もその + * 貢献者の名前も、この + * ソフトウェアから派生した製品の推奨または宣伝に使用することは、書面による事前の特別な許可なしにできません。 + * + * このソフトウェアは、著作権所有者およびコントリビューターによって「現状のまま」提供され、 + * 明示的であるかまたは黙示的であるかにかかわらず、商品性および特定目的への適合性に関する黙示の + * 保証を含むがこれに限定されない、いかなる保証も + * 否認されます。いかなる場合も、著作権者またはコントリビューターは、 + * 直接的、間接的、付随的、特別、例示的、または結果的な損害 + *(代替の商品やサービスの調達を含むがこれらに限定されない、 + * 使用、データ、または利益の喪失、あるいは事業の中断を含むが、これらに限定されない) + * あらゆる責任理論(契約、厳格責任、または不法行為を含む)について、 + *(過失を含むか否かにかかわらず)この + * ソフトウェアの使用から生じるいかなる形でも、そのような損害の可能性について知らされていたとしても、責任を負わないものとします。+ */ + +#include "manually_constructed.h" +#include "rpmsg_lite_rtos_transport.h" +#include "erpc_transport_setup.h" + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// Variables +//////////////////////////////////////////////////////////////////////////////// + +static ManuallyConstructed s_transport; + +//////////////////////////////////////////////////////////////////////////////// +// Code +//////////////////////////////////////////////////////////////////////////////// + +erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + s_transport.construct(); + s_transport->init(src_addr, dst_addr, start_address, rpmsg_link_id, ready_cb, send_nameservice); + return reinterpret_cast (s_transport.get()); +} + + diff --git a/erpc_c/setup/erpc_transport_setup.h b/erpc_c/setup/erpc_transport_setup.h index 798d92f..6c3959e 100644 --- a/erpc_c/setup/erpc_transport_setup.h +++ b/erpc_c/setup/erpc_transport_setup.h @@ -34,6 +34,7 @@ #include "erpc_version.h" #include +#include /*! * @addtogroup transport_setup @@ -48,7 +49,7 @@ //! @brief 不透明なトランスポートオブジェクトタイプ。 typedef struct ErpcTransport *erpc_transport_t; //! @brief トランスポートの準備完了コールバックオブジェクトタイプ。 -typedef void (*rpmsg_ready_cb)(void); +//typedef void (*rpmsg_ready_cb)(void); //////////////////////////////////////////////////////////////////////////////// // API @@ -106,21 +107,21 @@ erpc_transport_t erpc_transport_rpmsg_lite_master_init(unsigned long src_addr, /*! * @brief RPMsg-Lite ゼロコピー転送を作成します。 */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, - unsigned long dst_addr, - int rpmsg_link_id); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_master_init(unsigned long src_addr, +// unsigned long dst_addr, +// int rpmsg_link_id); /*! * @brief RPMsg-Lite トランスポートを作成します。 */ erpc_transport_t erpc_transport_rpmsg_lite_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); /*! * @brief RPMsg-Lite ゼロコピー・トランスポートを作成します。 */ -erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); +//erpc_transport_t erpc_transport_rpmsg_lite_zc_remote_init( +// unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); /*! * @brief RPMsg-Lite RTOS トランスポートを作成します。 @@ -133,7 +134,8 @@ erpc_transport_t erpc_transport_rpmsg_lite_rtos_master_init (unsigned long src_ad * @brief) RPMsg-Lite RTOSトランスポートを作成します。*/ erpc_transport_t erpc_transport_rpmsg_lite_rtos_remote_init( - unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, rpmsg_ready_cb ready); + unsigned long src_addr, unsigned long dst_addr, void *start_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + //@} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.cpp b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp new file mode 100644 index 0000000..e04ae91 --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.cpp @@-0,0 +1,158 @@ +/* + * Copyright (c) 2015, Freescale Semiconductor, Inc. + * + * ソース形式およびバイナリ形式での再配布および使用は、変更の有無にかかわらず、 + * 以下の条件を満たしている場合に限り許可されます。 + * + * o ソースコードの再配布には、上記の著作権表示、この条件の一覧 + * および以下の免責事項を含める必要があります。 + * + * o バイナリ形式での再配布では、上記の著作権表示、この + * 条件リスト、 および以下の免責事項をドキュメントおよび/または 配布物に付属する他の資料に複製する必要があります。 + * + * o Freescale Semiconductor, Inc.の名前もその + *コントリビューターの名前も、この + *ソフトウェアから派生した製品の推奨または宣伝に使用することは、書面による事前の特別な許可なしにできません。 + * + * このソフトウェアは、著作権所有者およびコントリビューターによって「現状のまま」提供され、 + * 明示的であるかまたは黙示的であるかにかかわらず、商品性および特定目的への適合性に関する黙示の + * 保証を含むがこれに限定されない、いかなる保証も + * 否認されます。いかなる場合も、著作権者またはコントリビューターは、 + * 直接的、間接的、付随的、特別、例示的、または結果的な損害 + *(代替の商品やサービスの調達を含むがこれらに限定されない、 + * 使用、データ、または利益の喪失、あるいは事業の中断を含むが、これらに限定されない) + * あらゆる責任理論(契約、厳格責任、または不法行為を含む)について、 + *(過失を含むか否かにかかわらず、このソフトウェアの使用から生じるいかなる形で、そのような損害の可能性について知らされていたとしても、責任を負わないものとします。 + */ + +#include "rpmsg_lite_rtos_transport.h" +#include + +#if !(__embedded_cplusplus) +using namespace std; +#endif + +using namespace erpc; + +//////////////////////////////////////////////////////////////////////////////// +// Variables +//////////////////////////////////////////////////////////////////////////////// +uint8_t RPMsgRTOSTransport::s_initialized = 0; +struct rpmsg_lite_instance *RPMsgRTOSTransport::s_rpmsg; + +//////////////////////////////////////////////////////////////////////////////// +// Code +//////////////////////////////////////////////////////////////////////////////// + +RPMsgRTOSTransport::RPMsgRTOSTransport() +: Transport() +, m_dst_addr(0) +{ +} + +RPMsgRTOSTransport::~RPMsgRTOSTransport() +{ + rpmsg_lite_deinit(s_rpmsg); + s_initialized = 0; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_master_init(base_address, length, rpmsg_link_id, RL_NO_FLAGS); + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice) +{ + if (!s_initialized) + { + s_rpmsg = rpmsg_lite_remote_init(base_address, rpmsg_link_id, RL_NO_FLAGS); + + /* 他のコアに準備ができたことを知らせます */ + if (ready_cb != NULL) + { + ready_cb(); + } + + while (!rpmsg_lite_is_link_up(s_rpmsg)) + { + } + + s_initialized = 1; + } + + m_rpmsg_queue = rpmsg_queue_create(s_rpmsg); + m_rpmsg_ept = rpmsg_lite_create_ept(s_rpmsg, src_addr, rpmsg_queue_rx_cb, m_rpmsg_queue); + + if(send_nameservice) + { + rpmsg_ns_announce(s_rpmsg, m_rpmsg_ept, + "rpmsg-openamp-demo-channel", + 0); + } + + m_dst_addr = dst_addr; + return m_rpmsg_ept == RL_NULL ? kErpcStatus_InitFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::receive(MessageBuffer *message) +{ + int ret_val = rpmsg_queue_recv(s_rpmsg, m_rpmsg_queue, &m_dst_addr, (char *)message->get(), kRpmsgMessageBufferSize, + NULL, RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_ReceiveFailed : kErpcStatus_Success; +} + +erpc_status_t RPMsgRTOSTransport::send(const MessageBuffer *message) +{ + int ret_val = + rpmsg_lite_send(s_rpmsg, m_rpmsg_ept, m_dst_addr, (char *)message->get(), message->getUsed(), RL_BLOCK); + return ret_val != RL_SUCCESS ? kErpcStatus_SendFailed : kErpcStatus_Success; +} + +MessageBuffer RPMsgMessageBufferFactory::create() +{ + uint8_t idx = 0; + while (((m_freeBufferBitmap & idx) == 0) && (idx < kInitCountMessageBuffers)) + { + idx++; + } + + assert(idx < kInitCountMessageBuffers); + + m_freeBufferBitmap &= ~(1 << idx); + + uint8_t *buf; + buf = m_buffers[idx]; + + assert(NULL != buf); + return MessageBuffer(buf, kRpmsgMessageBufferSize); +} + +void RPMsgMessageBufferFactory::dispose(MessageBuffer *buf) +{ + assert(buf); + uint8_t *tmp = buf->get(); + + if (tmp) + { + uint8_t idx = 0; + while ((tmp != m_buffers[idx]) && (idx < kInitCountMessageBuffers)) + { + ++idx; + } + m_freeBufferBitmap |= 1 << idx; + } +} diff --git a/erpc_c/transports/rpmsg_lite_rtos_transport.h b/erpc_c/transports/rpmsg_lite_rtos_transport.h new file mode 100644 index 0000000..f1aec8a --- /dev/null +++ b/erpc_c/transports/rpmsg_lite_rtos_transport.h @@ -0,0 +1,177 @@ +/* + * Copyright (c) 2015-2016, Freescale Semiconductor, Inc. + * + * ソースおよびバイナリ形式での再配布および使用は、修正の有無にかかわらず、 + * 以下の条件が満たされている場合に許可されます。 + * + * o ソースコードの再配布には、上記の著作権表示、この条件のリスト、 + * および以下の免責事項を保持する必要があります。 + * + * o バイナリ形式での再配布では、上記の著作権表示、この + * 条件リスト、 および以下の免責事項をドキュメントおよび/または 配布物に付属する他の資料に複製する必要があります。 + * + * o Freescale Semiconductor, Inc.の名前もその + *貢献者の名前も、この + *ソフトウェアから派生した製品の推奨または宣伝に使用することは、書面による事前の特別な許可なしにできません。 + * + * このソフトウェアは、著作権所有者およびコントリビューターによって「現状のまま」提供されます。 + * 明示的であるかまたは黙示的であるかにかかわらず、 + * 商品性および特定目的への適合性に関する黙示の保証を含むがこれに限定されない、いかなる保証も + * 否認されます。いかなる場合も、著作権者またはコントリビューターは、 + * 直接的、間接的、付随的、特別、例示的、または結果的な損害、+ *(代替の商品やサービスの調達を含むがこれらに限定されない、 + * 使用、データ、または利益の喪失、あるいは事業の中断を含むが、これらに限定されない)+ * あらゆる責任理論(契約、厳格責任、または不法行為を含む)について、 + *(過失を含むか否かにかかわらず)この + * ソフトウェアの使用から生じるいかなる形で、そのような損害の可能性について知らされていたとしても、責任を負わないものとします。 + */++#ifndef _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_+#define _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_++#include "transport.h"+#include "message_buffer.h"+#include "rpmsg_lite.h"+#include "rpmsg_queue.h"+#include 「rpmsg_ns.h」+ +/*! + * @addtogroup rpmsg_lite_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// Definitions +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, + kInitCountMessageBuffers = 2, +}; + +//////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief プロセッサ間メッセージングに RPMsg RTOS API を使用するトランスポート。 + * + * @ingroup rpmsg_lite_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief コンストラクタ。 + *+ * この関数はオブジェクトの属性を初期化します。+ */+ RPMsgRTOSTransport();++ /*!+ * @brief RPMsgRTOSTransport デストラクタ+ */+ virtual ~RPMsgRTOSTransport();++ /*!+ * @brief この関数は、RPMsg RTOS 初期化関数を呼び出します - RPMsg マスターとして+ *+ * @Param[in] src_addr ソースアドレス。+ * @Param[in] dst_addr 宛先アドレス。 + * @Param[in] base_address 共有メモリ内の RPMsg ベースアドレス。 + * @Param[in] length RPMsg 共有メモリ領域の長さ。 + * @Param[in] rpmsg_link_id どのコア間で通信が行われるかの選択。 + *+ * @retval kErpcStatus_Success rpmsg init 関数が正常に実行されたとき。 + * @retval kErpcStatus_InitFailed rpmsg init 関数が正常に実行されなかったとき。 + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, unsigned long length, int rpmsg_link_id); + + /*! + * @brief この関数は RPMsg RTOS 初期化関数を呼び出します - RPMsg リモートとして + * + * @Param[in] src_addr 送信元アドレス。 + * @Param[in] dst_addr 宛先アドレス。 + * @Param[in] base_address 共有メモリ内の RPMsg ベースアドレス。 + * @Param[in] rpmsg_link_id どのコア間で通信が行われるかの選択。 + * @Param[in] ready_cb RPMsgの初期化が完了し、コアの準備が整った後に呼び出されるコールバック。 + * @Param[in] send_nameservice true の場合、RPMsg マスターはネームサービスによって通知されます。 + * + * @retval kErpcStatus_Success rpmsg init 関数が正常に実行されたとき。 + * @retval kErpcStatus_InitFailed rpmsg init 関数が正常に実行されなかったとき。 + */ + virtual erpc_status_t init( + unsigned long src_addr, unsigned long dst_addr, void *base_address, int rpmsg_link_id, void (*ready_cb)(void), bool send_nameservice); + + /*! + * @brief 受信メッセージをメッセージバッファに保存します。 + * + * メッセージが来ない間、ループを繰り返します。 + * + * @Param[in] message 受信メッセージが格納されるメッセージバッファ。 + * + * @retval kErpcStatus_ReceiveFailed メッセージバッファの受信に失敗しました。 + * @retval kErpcStatus_Success すべてのデータを正常に受信しました。 + */ + virtual erpc_status_t receive(MessageBuffer *message); + + /*! + * @brief 用意されたメッセージを送信する関数。 + * + * @Param[in] message 送信するメッセージバッファを渡します。 + * + * @retval kErpcStatus_SendFailed メッセージバッファの送信に失敗しました。 + * @retval kErpcStatus_Success すべてのデータを正常に送信しました。 + */ + virtual erpc_status_t send(const MessageBuffer *message); + +protected: + /* リモートデバイス */ + struct remote_device *m_rdev; /*!< 2 番目のコアを表すデバイス。*/ + struct rpmsg_channel *m_app_rp_chnl; /*!< 2つのデバイス(2つのコア)間の接続を表します。*/ + unsigned long m_dst_addr; /*!< rpmsg が使用する宛先アドレス。*/ + rpmsg_queue_handle m_rpmsg_queue; /*!< RPMsg キューのハンドル。*/ + struct rpmsg_lite_endpoint *m_rpmsg_ept; /*!< RPMsg Lite エンドポイント構造体へのポインター。*/ + + static struct rpmsg_lite_instance *s_rpmsg; /*!< RPMSG lite のインスタンスへのポインター。*/ + static uint8_t s_initialized; /*!< rpmsg-lite が初期化されたかどうかを表す情報。*/ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ + uint8_t m_freeBufferBitmap; + uint8_t m_buffers[kInitCountMessageBuffers][kRpmsgMessageBufferSize]; + +public: + /*! + * @brief コンストラクター。 + */ + RPMsgMessageBufferFactory() + : m_freeBufferBitmap(0xFF) + { + } + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief この関数は、デバイス間の通信に使用されるメッセージバッファを作成します。 + */ + virtual MessageBuffer create(); + /*! + * @brief この関数は、デバイス間の通信に使用されるメッセージバッファを破棄します。 + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // namespace erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_LITE_RTOS_TRANSPORT_H_ diff --git a/erpc_c/transports/rpmsg_rtos_transport.h b/erpc_c/transports/rpmsg_rtos_transport.h new file mode 100644 index 0000000..ad1d229 --- /dev/null +++ b/erpc_c/transports/rpmsg_rtos_transport.h @@-0,0 +1,147 @@+/*+ * Copyright (c) 2015, Freescale Semiconductor, Inc.+ *+ * ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、+ * 以下の条件を満たす場合に許可されます。+ *+ * o ソースコードの再配布には、上記の著作権表示、この条件のリスト+ * および以下の免責事項を含める必要があります。+ * + * o バイナリ形式での再配布では、上記の著作権表示、この + * 条件リスト、 および以下の免責事項をドキュメントおよび/または 配布物に付属する他の資料に複製する必要があります。 + * + * o Freescale Semiconductor, Inc.の名前もその + *貢献者の名前も、この + *ソフトウェアから派生した製品の推奨または宣伝に使用することは、書面による事前の特別な許可なしにできません。 + * + * このソフトウェアは、著作権所有者およびコントリビューターによって「現状のまま」提供され、 + * 明示的であるかまたは黙示的であるかにかかわらず、商品性および特定目的への適合性に関する黙示の + * 保証を含むがこれに限定されない、いかなる保証も + * 否認されます。いかなる場合も、著作権者またはコントリビューターは、 + * 直接的、間接的、付随的、特別、例示的、または結果的な損害、 + *(代替の商品やサービスの調達を含むがこれらに限定されない、 + * 使用、データ、または利益の喪失、あるいは事業の中断を含むが、これらに限定されない) + * あらゆる責任理論(契約、厳格責任、または不法行為を含む)について、 + *(過失を含むか否かにかかわらず)この + * ソフトウェアの使用から生じるいかなる形で、そのような損害の可能性について知らされていたとしても、責任を負わないものとします。 + */ + +#ifndef _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ +#define _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ + +#include "transport.h" +#include "message_buffer.h" + +extern "C" { +#include "rpmsg.h" +#include "rpmsg_rtos.h" +#include "rpmsg.h" +} + +/*! + * @addtogroup rpmsg_rtos_transport + * @{ + * @file + */ + +//////////////////////////////////////////////////////////////////////////////// +// Definitions +//////////////////////////////////////////////////////////////////////////////// + +enum +{ + kRpmsgMessageBufferSize = RPMSG_BUFFER_SIZE, +}; + +//////////////////////////////////////////////////////////////////////////////// +// Classes +//////////////////////////////////////////////////////////////////////////////// + +namespace erpc +{ +/*! + * @brief プロセッサ間メッセージングに RPMsg RTOS API を使用するトランスポート。 + * + * @ingroup rpmsg_rtos_transport + */ +class RPMsgRTOSTransport : public Transport +{ +public: + /*! + * @brief コンストラクタ。 + * + * この関数はオブジェクトの属性を初期化します。 + */ + RPMsgRTOSTransport(); + + /*! + * @brief RPMsgRTOSTransport destructor + */ + virtual ~RPMsgRTOSTransport(); + + /*! + * @brief この関数は rpmsg rtos init 関数を呼び出します。 + * + * @Param[in] dev_id デバイスID番号。 + * @Param[in] role デバイスロール番号。 + * + * @retval kErpcStatus_Success rpmsg init 関数が正常に実行されたとき。 + * @retval kErpcStatus_InitFailed rpmsg init 関数が正常に実行されなかったとき。 + */ + virtual erpc_status_t init(int dev_id, int role); + + /*! + * @brief 受信メッセージをメッセージバッファに保存します。 + * + * メッセージが送信されない間、ループを繰り返します。 + * + * @Param[in] message 受信メッセージが格納されるメッセージバッファ。 + * + * @retval kErpcStatus_ReceiveFailed メッセージバッファの受信に失敗しました。 + * @retval kErpcStatus_Success すべてのデータを正常に受信しました。 + */ + virtual erpc_status_t receive(MessageBuffer *メッセージ); + + /*! + * @brief 用意されたメッセージを送信する関数。. + * + * @Param[in] message 送信するメッセージバッファを渡します。 + * + * @retval kErpcStatus_SendFailed メッセージバッファの送信に失敗しました。 + * @retval kErpcStatus_Success すべてのデータが正常に送信されました。 + */ + virtual erpc_status_t send(const MessageBuffer *メッセージ); + +protected: + /* リモートデバイス */ + static struct remote_device *m_rdev; /*!< 2 番目のコアを表すデバイス。*/ + static struct rpmsg_channel *m_app_rp_chnl; /*!< 2つのデバイス(2つのコア)間の接続を表します。*/ +}; + +class RPMsgMessageBufferFactory : public MessageBufferFactory +{ +public: + /*! + * @brief コンストラクタ。 + */ + RPMsgMessageBufferFactory() {} + /*! + * @brief RPMsgMessageBufferFactory destructor + */ + virtual ~RPMsgMessageBufferFactory() {} + /*! + * @brief デバイス間の通信に使用するメッセージバッファを作成する関数です。 + */ + virtual MessageBuffer create(); + /*! + * @brief この関数は、デバイス間の通信に使用されるメッセージバッファを破棄します。 + */ + virtual void dispose(MessageBuffer *buf); +}; + +} // namespace erpc + +/*! @} */ + +#endif // _EMBEDDED_RPC__RPMSG_RTOS_TRANSPORT_H_ diff --git a/erpc_python/erpc/transport.py b/erpc_python/erpc/transport.py index 0765e9f..c335943 100644 --- a/erpc_python/erpc/transport.py +++ b/erpc_python/erpc/transport.py @@ -31,6 +31,8 @@ import struct import serial +from rpmsg.sysfs import RpmsgEndpoint +import time import socket import threading from .crc16 import crc16 @@ -107,6 +109,25 @@ class SerialTransport(FramedTransport): class ConnectionClosed(Exception): pass +class RpmsgTransport(Transport): + def __init__(self): + self.ept = RpmsgEndpoint( + RpmsgEndpoint.rpmsg_openamp_channel, + RpmsgEndpoint.LOCAL_DEFAULT_ADDRESS, + RpmsgEndpoint.Types.DATAGRAM) + + def send(self, message): + self.ept.send(message, RpmsgEndpoint.REMOTE_DEFAULT_ADDRESS) + + def receive(self): + while True: + ret = self.ept.recv(2048) + if len(ret[1]) != 0: + return ret[1] + else: + time.sleep(0.001) + return ret[1] + class TCPTransport(FramedTransport): def __init__(self, host, port, isServer): super(TCPTransport, self).__init__() -- 2.7.4 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ドゥシャン、ありがとうございます 。デモが動作したら、プルリクエストを作成いたします。 再度の返信ありがとうございます。Pythonファイルを受け取りました。デモを実行し、すぐに結果をお知らせします。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、その調子です。(笑顔のウィンクの顔文字)必要に応じて、imxデモリポジトリにプルリクエストを作成して修正できます。mareknovak がそれを確認し、リポジトリにマージできます。 Python コードを生成するには、他のアプリケーションと同様に、コマンドラインで「erpcgen --help (-h も機能します)」を実行できます。 python -gpy idl_file -> gpy は Python を生成することを意味します。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 素晴らしいですね。更新まで同じ安定したバージョンで作業を続けることができます。 いくつかの修正により、MCUデモがビルドされ、正常に実行されるようになりました。情報を提供していただき、ありがとうございます。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan 修正したら、MCUデモが正常に動作するようになりました。安定したバージョンを教えてくださり、ありがとうございます。 erpcgen ツールを使用して Python コードを生成する方法を教えていただけますか。 よろしくお願い申し上げます。 チャンディーニ Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、最短で明日です。しかし、明日になるとはお約束できません。私の同僚mareknovakは本日勤務していません。ですが、あまり時間はかからないはずです。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> いつ更新するのか教えていただけますか。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、関心をお寄せいただきありがとうございます。その後、erpc によって生成されたファイルは、Marek がコミットで提供したものとは異なる erpcgen によって生成されたようです(私たちのミスです)。最善の解決策としては、そのデモを最新の安定した erpc および erpcgen バージョンに更新する必要があるようです。GitHub - EmbeddedRPC/erpc: Embedded RPCのマスターブランチからこれを試していただけます(erpcgen プリビルド 1.4.0 もあります)が、どれだけの変更が必要なのかわかりません。代わりに更新を待っていただくことも可能です。 mareknovak Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi Dusan あなたが参照されたのと同じeRPCライブラリを使用していました。 私が従った手順は以下の通りです。  erpc-imx-demosのクローン作成、(eRPC GitHub - 232afb209f0a0cfceb25a1be11879f7d1934e065 の MarekNovakNXP/erpc をクローンする)サブモジュールを含む 1. git clone --recursive https://github.com/EmbeddedRPC/erpc-imx-demos.git 2. erpc-imx-demos/middleware/erpc フォルダに移動し、以下のように erpcgen をビルドしました。 必要なパッケージflex/bisonおよびboostをインストール eprcを作成する eprcgenを作成する sudoメイクインストール erpcgen を正常に取得しました 3.以下のようにerpc_matrix_multiply.erpcを使用して、独自の出力ファイルの作成を試みました。 erpcgen -I erpc-imx-demos/MCU/example_erpc/service -o test/erpc-imx-demos/MCU/example_erpc/service erpc_matrix_multiply.erpc 以下のファイルを正常に取得しました。 erpc_matrix_multiply.h erpc_matrix_multiply_server.cpp erpc_matrix_multiply_server.h erpc_matrix_multiply_client.cpp 4. MCU/example_erpc/build/armgcc/imx7d_sdb_m4/build_all.shのビルドを試みました。 エラーが発生して失敗しました。 /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp: 関数内 'void* create_MatrixMultiplyService_service()': /home/basavarajuc/test/erpc-imx-demos/MCU/example_erpc/service/erpc_matrix_multiply_server.cpp:168:56: エラー: 抽象クラス型 'MatrixMultiplyService_service' の new-expression が無効です new (nothrow) MatrixMultiplyService_service() を返します。 再度質問して申し訳ありませんが、きちんと理解したいと考えています。 1. GitHub の eRPC ライブラリ (232afb209f0a0cfceb25a1be11879f7d1934e065 の MarekNovakNXP/erpc) を使用している場合、 デモを正常に実行するには、デモを更新する必要がありますか。 2.erpc-imx-demos/MCU/example_erpc/service at master · EmbeddedRPC/erpc-imx-demos · GitHub からの出力ファイルは、どのバージョンの erpcgen で生成されているか教えていただけますか? 古いerpcgenを使用して、すぐに自分のファイルを作成できるようにしたいのです。 お手数をおかけしますが、どうぞよろしくお願い申し上げます。 チャンディーニ   Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、コメントをありがとうございます。ご指摘の例は、お使いの erpcgen ビルドよりも古いバージョンです。mareknovak は、当時の公式リリースにはなかったいくつかの小さな変更により、公式 eRPC リポジトリのフォークも作成しました。ミドルウェアフォルダーのerpc-imx-demosリポジトリからeRPC参照をクリックすると、eRPCリポジトリにリダイレクトされます。そのバージョンから erpcgen をビルドする必要があります。将来的にはデモを更新したいと考えています。 お役に立てたなら幸いです。ご不明な点がございましたら、どうぞお気軽にお問い合わせください。 Re: eRPCの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi 基本的な質問であれば申し訳ございません。 NXP の erpcgen ツールの使用方法を理解しようとしています。 サンプルデモを正常に実行しました。こちらを参照しました:https://github.com/EmbeddedRPC/erpc-imx-demos 次のアプローチは、erpcgen をビルドし、同じ erpc_matrix_multiply.erpcを使用して独自の出力ファイルを作成し、同じデモを再度実行して、erpcgen ツールの使用に慣れることでした。 出力ファイルを取得しましたが、同じ erpc_matrix_multiply.erpc を使用しているにもかかわらず、私のファイルはサンプルファイルと異なります。 変更点は以下の通りです: 例示デモの出力ファイルは次のとおりです (erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * in, erpc::Codec * out, uint32_t sequence); 私のファイル(erpc_matrix_multiply_server.h): erpc_status_t erpcMatrixMultiply_shim(erpc::Codec * codec, uint32_t sequence); ファイルが異なる理由、欠けている設定があれば教えてください。 erpc_matrix_multiply_server.h および erpc_matrix_multiply_server.cpp を手動で編集する必要がありますか。 よろしくお願いいたします チャンディーニ
查看全文
CSEc Error I'm using CSEc with S32K144, when does it return KEY_INVAILD error at BOOT_DEFINE? I hope to get answers and have a happy day! Re: CSEc Error Hi @xiaozhi  I can't see a reason for such error when calling BOOT_DEFINE function. This function can be called even if BOOT_MAC_KEY is not provisioned yet, so it does not require a key.  Regards, Lukas
查看全文
CSEC GenerateMACAddrMode 地址范围 圣诞快乐 你好 当我使用 CSEC 的 GenerateMACAddrMode 函数时,当地址值超过 0x7DFFF 时,会发生错误。这正常吗? Re: CSEC GenerateMACAddrMode address range 我的错 我的意思是无法从 512kb CSEC_DRV_GenerateMACAddrMode(CSEC_RAM_KEY,(uint8_t *)0x0007FFFC, 0x00000080, (uint8_t *)cmacout) 中取出; 但我使用 addr = 0x0007FFFC,len = 0x00000080 也没有错误,但超出范围 Re: CSEC GenerateMACAddrMode address range 你好@SaLan 这是 Addr 模式下 CMD_GENERATE_MAC 命令(也称为指针方法)的限制: 分区(即块大小)可以是 128KB、256KB 或 512KB,视衍生产品而定: 此致, Lukas
查看全文
mk64 从闪存 0xE5FF8 读取数据会导致总线故障 你好, 我有一款运行 MK64FN01M 的板,与 frdm_K64 的板类似。 我确实在存储CRC的最后一个字节上存储了闪存中的设置。 对于板上的一个扇区,我在阅读该部分时出现总线故障 该代码调用了从 0xE5FF8 到 RAM 的简单 memcpy,长度为 8 字节。 该代码中的该函数之前被不同的内存部分调用过。 只有在这些位置上,代码才会崩溃。 当我把这个扇区移到其他位置时,它就能正常工作了。 是否知道为什么特定内存会出现问题? 谢谢,阿迪布 Re: mk64 read from flash 0xE5FF8 causes busfault 你好@theadib 请先擦除整个扇区,然后写入与 8 字节边界对齐的设置数据(包括 CRC)。不要对同一 8 字节短语执行部分更新。然后,继续进行读取操作。   BR 爱丽丝 Re: mk64 read from flash 0xE5FF8 causes busfault 你好,爱丽丝,感谢您的回复。 总线故障发生在读取操作期间(来自闪存位置的 memcpy)使用常规闪存地址会导致总线故障的原因 是什么? 之前没有写入操作。 是否有可能持续"阻止/保护" 闪存的读取。 我的程序在其他设备上运行正常。 有什么想法吗? 谢谢,阿迪布 Re: mk64 read from flash 0xE5FF8 causes busfault 你好@theadib 有 FSEC 寄存器。FSEC 中的高效密码学标准(SEC) 位决定了 MCU 处于安全还是不安全状态。虽然它可以控制整个 MCU,但在你的情况中,只有部分内存无法读取,所以我认为这不是原因。 有可能是上一次写入操作过程中发生了错误,因此我建议先擦除内存,然后再次读取以检查是否正常工作。   谢谢!   BR 爱丽丝   Re: mk64 read from flash 0xE5FF8 causes busfault 你好@Alice_Yang, 也许这个问题与我使用世纪佳缘 JLink 时发现的一些奇怪行为有关。 当我在 JLink 中使用 MK64FN1M0XXX12 连接到我的 MK64FN1MOVLQ12 时: 设备 mk64fn1moxxx12 如果 SWD 速度 1000 connect erase loadbin imagefile.bin 0 通常 jLink 会声称设备在擦除后受到保护。 并提出了所附的对话。 我本以为在执行擦除命令后设备不受保护且不安全。 使用 JLink 完全擦除闪存并加载新映像的首选顺序是什么? 。 预先致谢 Re: mk64 read from flash 0xE5FF8 causes busfault 您好@Alice_Yang 很抱歉打扰您...... ,我现在已经找到了根本原因,即向同一地址重复写入相同数据。 这种情况不应该发生在没有错误的代码中 😉 但是, ,第二次写入会返回错误代码 ,但随后即使读取该扇区也会导致 BUS_FAULT 陷阱。 有没有可能在一次访问导致整个程序崩溃之前检查扇区状态? 这样,我就可以再次正确擦除扇区,并将扇区置于正确的状态。 ?? 我已经查看了参考手册第 29.4.10.2 节中的 FSFE 描述闪存命令。 但我没有看到一条命令可以"测试" 程序存储器中的一个扇区。 我是不是漏掉了什么? 这样,我就能制作出更具弹性的应用程序,在重启后检查闪存状态。 预先致谢, Adib Re: mk64 read from flash 0xE5FF8 causes busfault 你好@theadib 使用 J-Link 擦除时,同一芯片有两种选择。请选择没有 “允许网络安全” 的设备名称;这样,擦除后将无法保护设备名称。 谢谢。 BR 爱丽丝 Re: mk64 read from flash 0xE5FF8 causes busfault 你好@theadib 用上市 “擦除闪存扇区” 命令后,FRFE 会擦除所选闪存,然后验证其是否已擦除。如果擦除验证失败,则 FSTAT[MGSTAT0] 位被置位。 在擦除闪存扇区操作 完成后,CCIF 标志被置位。擦除闪存扇区命令可挂起(参见 FCNFG[ERSSUSP] 位和图 29-11)。 BR 爱丽丝
查看全文
CAN MCX Nx4x FlexSPI ポートA とポートB を異なるデバイスで同時に使用できますか。 こんにちは、NXPさん FlexSPI を使用してハードウェアを接続し、両方のデバイスを同時にCAN使用できますか? ポートA->NORフラッシュ ポートB->PSRAM また、参考になる構成例はありますか? どうもありがとうございます MCX N Re: Can we use MCX Nx4x FlexSPI portA and portB with different device at the same time. こんにちは、ハリー。 Spark の説明によると、device_config と clk ソースをチェックする必要がありますか? 私は見た typedef 構造体 _flexspi_config { ...... #定義されている場合(FSL_FEATURE_FLEXSPI_SUPPORT_SEPERATE_RXCLKSRC_PORTB) && FSL_FEATURE_FLEXSPI_SUPPORT_SEPERATE_RXCLKSRC_PORTB flexspi_read_sample_clock_t rxSampleClockPortB; /*!< フラッシュ読み取り用のサンプルクロックsource_bの選択。*/ #endif 1.portA と PortB を使用する場合、別々の rxclksource を使用する必要がありますか? 2. FLEXSPI_SetFlashConfig() に渡される &deviceconfig をチェックする必要がありますか? Re: Can we use MCX Nx4x FlexSPI portA and portB with different device at the same time. こんにちは、ハリー。 サンプル コードでは、PortA の NOR フラッシュ ID にアクセスする方法のみが提供されており、MCX-N5XX-EVK にコネクテッドされた PSRAM を使用して PortB にアクセスするためのコードを追加しようとしています。参考までに実験結果を以下に示します。 FlexSPI 設定: ポートA->NORフラッシュ ポートB->PSRAM テストCASE1:成功 初期PortAおよびPortAフラッシュIDの読み取り(1バイト) テストCASE2: 成功 ポートBの初期値とポートBのフラッシュIDの読み取り(1バイト) テストCASE3: 失敗 最初にポートAとポートBの両方が、アドレスを使用してポートAとポートBのフラッシュID(1バイト)を個別に読み取ります。 以下に参考用のコードスニペットを示します。PortA と PortB の状況で間違いがあったか、さらに設定が必要かどうかを確認してください。 ポートAとポートBの両方のフラッシュデバイスを初期化するためのflexspi_nor_flash_initのコード変更 ポートBデバイスを読み取るためにflashXfer.deviceAddressにオフセットを追加します。 参考までに、変更されたファイルとプロジェクト全体のアーカイブを以下に示します。 Re: Can we use MCX Nx4x FlexSPI portA and portB with different device at the same time. こんにちは SDKs サンプルを参照していますが、同時に 2 つのデバイスではなく 1 つのフラッシュ デバイスにコネクテッドされています。 2 つのデバイスを同時に動作させるには、設定が足りないのではないかと思います。 参考になるサンプル構成はありますか? または、レジスタ レベルから正しい構成を実行したことをどのように確認すればよいでしょうか? よろしくお願いします。 Re: Can we use MCX Nx4x FlexSPI portA and portB with different device at the same time. こんにちは@greatshow_chen はい、NXP MCX Nx4x では、FlexSPI ポート A とポート B の両方を同時に使用して、2 つの異なるメモリ デバイスに接続CAN。 ポートA->NORフラッシュ ポートB->PSRAM 次の点を確認する必要があります。 NOR フラッシュと PSRAM は競合するピンを共有していません。 flexspi_octal_polling_transferをCAN参照します。 BR ハリー Re: Can we use MCX Nx4x FlexSPI portA and portB with different device at the same time. こんにちは、 FlexSPI を搭載した多くの NXP マイクロコントローラ (i.MX RT シリーズなど) には、2 つの独立した FlexSPI チャネル (ポート A とポート B) があります。各ポートは、異なるタイプのメモリ デバイスと通信するように構成CAN。これにより、NOR フラッシュを 1 つのポートに接続し、PSRAM を別のポートに接続できるようになります。
查看全文
关于使用 RTD 进行功能安全配置的问题 你好,团队 请问 S32K314 的热电阻(MCAL/SPD)配置如何? Q1.我没有在 RTD 上找到关于带中断的 PLL LOL 的 "配置"。 哪种配置(来自带有 SPD 的 MCAL RTD)可以配置 LOL 的 RESET 或中断? Q2.对于带中断功能的低压检测 和 HVD,我没看清哪个与低压检测 和 HVD 有关。 请问哪一个是低压检测和 HVD 的中断反应,“MCU_ERROR_ISR_NOTIFICATION” 还是 “MCU_PMC_NOTIFICATION”? Q3.对于 ERM0 配置,如何配置 ERM(使用 RTD/SPD),例如下面的代码? 谢谢! RTD S32_CONFIG_TOOL S32DS Re: Question about Safety configuration using RTD 是的 用户可在 EB Tresos 的此节点中配置其用户通知,MCU_ERROR_ISR_NOTIFICATION 将在 PMC_VoltageError_IRQHandler> 中调用 ...> 然后,Mcu_Ipw_ReportPowerErrorsCallback 将调用此通知 Re: Question about Safety configuration using RTD 你好@congnguyenphu 感谢您的回复。 为了再次确认,低压检测/HVD 与 MCU_ERROR_ISR_NOTIFICATION 有关,不是吗? 谢谢! (我将关闭此票......) Re: Question about Safety configuration using RTD 你好@Luke_Chun 1.要配置 PLL LOL 的中断,Platform 模块中指向的 IRQ 必须正确。应启用 SoC_PLL_IRQn(NVIC 212)。它在参考手册和我们的头文件中提到: 但是,我检查了 RTD 代码包,我们不为这个中断提供 ISR。我在 SPD 包中也找不到。因此,用户需要为该中断处理程序实现自己的 ISR。 2。NVIC 52 参考手册中提及的带中断的低压检测 和 HVD: 在 RTD 的 MCU 集成手册中,我们提供了名为 PMC_VoltageError_IRQHandler 的 ISR 来处理该问题: 您可以在 RTD 平台中通过 IRQ"PMC_IRQn" 配置并启用它。 在 PMC_VoltageError_IRQHandler() 中,它还通过"MCU_ERROR_ISR_NOTIFICATION "宏调用MCU 配置中用户自定义的回调通知 McuErrorIsrNotification。 3.如何配置 ERM: -在 RTD 代码包中:我们在 EB Tresos/S32CT 上没有配置来帮助用户配置 ERM 寄存器的值。但 RTD 在 BaseNXP/header/S32K314_ERM.h 中提供了宏,帮助用户设置该寄存器的值: 用户可以使用这些宏作为裸机代码来设置寄存器的值。 -在 SPD 代码包中:我指的是 emcem 插件,文件 emceM_ERM.C在函数 eMcem_Erm_Init()中,以下宏用于设置 ERM[CR] 寄存器的值:erm_cr_addr32()、safetybase_reg_write32()  
查看全文
汇编程序在 CodeWarrior 中不合法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好   在使用 mwasmeppc.exe 编译汇编文件时,我遇到了一个问题、这是错误信息:   * 编译 s -> o * ### mwasmeppc.exe Assembler: # File: .\output\obj\cstartup.s # --------------------------------- # 88: e_and2i. # Error: ^^^^^^^^ # 当前目标处理器的指令不合法 ### mwasmeppc.exe 汇编器: # 99: sub r4,r3 # 错误: ^^^^^ # 简化助记符子的参数不足 ### mwasmeppc.exe 汇编器: # 114: e_or2i r31,0x4002 # Error: ^^^^^^ # 对于当前目标处理器,指令不合法   某些命令( e_and2i.sub e_or2i)无法识别,但该文件 cstartup.s 可与其他编译器(Greenhills、Windriver 等)配合使用。   CodeWarrior 版本: 适用于 MPC55xxMPC56xx v2.10。 MCU: XPC560XB CPU 类型为 -proc Zen   我不知道是我错过了一些编译器选项,还是我需要包含一些编译器文件?   顺祝商祺! 思佳 概述 Re: Assembler not legal in CodeWarrior 这是一个有趣的问题!这可能与 CodeWarrior 处理旧版汇编指令或项目设置的方式有关。您可以尝试查看编译器配置,检查是否正确设置了所有汇编路径。要更清楚地了解此类程序或法律文件细节,您可以访问迈阿密戴德在线案例,获取有关结构化流程和案件处理的参考式见解。有时,重温文档标准有助于有效确定缺失的配置。 Re: Assembler not legal in CodeWarrior 如果 CodeWarrior 不支持某些工具或功能(如汇编器),就会很麻烦。要获得有关相关规则和合规性的更多指导或验证,刑事法庭数据等资源有时可以提供有用的参考点。探索替代方法或支持模块可确保开发工作更加顺利。随时了解制约因素有助于防止意外错误并简化编码项目。 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 我已将"答案" 贴到您的另一个主题上。请检查。 此致, Martin Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,马丁、 非常感谢。 我还有一个关于汇编代码的问题https://community.nxp.com/thread/434043你能看看吗? 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 请查看附件,我向您发送的是使用 CW 2.10 生成的一些项目的默认链接器文件。您可以将其作为链接文件的指南。 关于调试信息,这里有部分文档介绍了如何在 .elf 中添加调试信息锉刀希望能对您有所帮助。如果没有,请告诉我,我会尝试不同的解决方案。 ------------------------------------------------------------------------------- 调试控制选项 ------------------------------------------------------------------------------- -g[dwarf] # 全局;套用;生成 DWARF 1.x 调试 # 信息;与"-sym dwarf-1,full "相同 -gdwarf-2 # 全局;套用;生成 DWARF 2.x 调试 # 信息;与"-sym dwarf-2,full" 相同 -sym 关键字[,...] # 全局;指定调试选项 off # 不生成调试信息; # 默认值 on|dwarf-1 # 打开 DWARF 1.x 调试信息 dwarf-2 # 打开 DWARF 2.x 调试信息 ----------------------------------------------------------------------------------------------------- 此致, 马丁 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,马丁、 我修改了 lcf 文件,现在项目可以生成地图和精灵了。 现在 lcf 文件仍然有一些错误,当我使用 Trace32 调试代码时,它找不到启动代码,我怎样才能将启动代码(__entry)定义为 0x0 地址? 另一个问题是,我只能在 Trace32 中看到汇编程序,您知道如何才能在 Trace32 中看到 c 文件吗? 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 MAP 文件看起来不完整。在连接项目时是否有任何错误?您是否能获得 .elf文件?您只共享了一个对象文件,因此我无法尝试链接。 因此,能否请您给我回信,最后能否请您分享您想链接到一起的所有对象文件? 此致, Martin Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,马丁、 这些是 .o文件和地图文件。 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 能否请您分享一下生成的地图文件?为什么您认为地图文件不正确? 能否共享您试图链接的对象文件? 此致, Martin Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,马丁、 我使用的是 mwldeppc。 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 您是使用 CodeWarrior IDE 还是 mwldeppc 命令行工具进行链接? 参考资料 Martin Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 这些是我使用的链接选项: LINK_OPT += -proc=Zen #mcu 类型;通用 LINK_OPT += -char=unsigned #设置 "char "的符号;必须与编译器匹配。 LINK_OPT += -srec #生成扩展名为 .mot 的 S 记录文件 LINK_OPT += -map #生成地图文件 LINK_OPT += -code_merging=all,aggressive #代码合并优化 LINK_OPT += -far_near_addressing #启用远近寻址优化 LINK_OPT += -vle_enhance_merging #启用 VLE 增强代码合并优化功能 LINK_OPT += -vle_bl_opt LINK_OPT += -abi eabi LINK_OPT += -gdwarf-2 LINK_OPT += -nostdlib LINK_OPT += -m __entry 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 好的,但现在我无法生成正确的 .Map 文件,是否需要添加一些链接选项?或 .o文件不好吗? 这是生成的地图文件的一部分: __入口的链接地图 代码折叠在文件中:C:\HaoSijia\Projects\498_XPC560XD_XB\test_base\Conformance\IN\Platforms_ConTest_RamNoInit\output\obj\Platforms_ConTest_RamNoInit.o 代码折叠在文件中:C:\HaoSijia\Projects\498_XPC560XD_XB\test_base\Conformance\IN\Platforms_ConTest_RamNoInit\output\obj\main.o 代码折叠在文件中:C:\HaoSijia\Projects\498_XPC560XD_XB\test_base\Conformance\IN\Platforms_ConTest_RamNoInit\output\obj\板.o … 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 是的,你完全可以使用自己的启动程序,而不是 CodeWarrior 启动文件。 此致, Martin Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 感谢您的解决方案,现在我又遇到了一个关于启动代码的问题: CodeWarrior 有自己的启动文件__start.c and __ppc_eabi_init.c、 我能用自己的启动代码代替这两个文件吗? CodeWarrior 版本:适用于 MPC55xxMPC56xx v2.10。 MCU: XPC560XB 顺祝商祺! 思佳 Re: Assembler not legal in CodeWarrior <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,思佳、 我看到了一些不一致的地方,可能是你要编译的代码中存在的问题: 1) 指令e_and2i和e_or2i是 VLE,而sub是 BookE。在使用mwasmeppc.exe 时,不可能在一个文件中编译两种指令。 2) 指令子程序必须有三个参数。 有几种解决方案: 1) 最好的办法是用 se_sub 代替 sub 指令,se_sub 是 VLE 指令,需要 2 个参数。不要忘记使用 -vle 选项编译文件。 2) 可以用 BookE 指令替换 VLE 指令,并在子指令中添加第三个参数。 看看附件,我给你发了 bookE 和 VLE 参考手册,其中详细描述了所有说明。 如果您有任何其他问题,请随时给我回信。 此致, Martin Re: Assembler not legal in CodeWarrior 当 CodeWarrior 抛出汇编程序错误时,尤其是当语法中的所有内容似乎都正确时,会令人沮丧。有时,问题会归结为配置或指令丢失,因此仔细检查项目设置会有所帮助。最近,我在研究文档准确性时遇到了里士满法律服务公司,它提醒我,可靠的参考资料在故障排除中是多么重要。希望分享这样的经验能帮助其他人更快地摆脱困境。 Re: Assembler not legal in CodeWarrior 我在尝试使用 CodeWarrior 中的汇编程序时也遇到了同样的问题,这让我非常沮丧。对于任何需要可靠法院信息的人来说,威尔公共记录都是查询备案和案件详细信息的有用资源。它使某些法律问题的解决变得更加容易,而无需依赖零散的资料来源。如果您想快速查阅官方记录,绝对值得一试。
查看全文
ADC startup time for S32K3 I'm using S32K3 ADC, and my test found that it takes about 30ms from powering up to initialize the ADC, performing calibration, turning on conversion, and completing the acquisition for the first time, is this normal? How to shorten this time? Re: S32K3的ADC启动时间 Hi RTD Quality packages的ProfileReport.xlsx列了各个APIs的执行时间。 (比如...\SW32K3_S32M27x_RTD_R21-11_5.0.0 _D2410_QualityPackage\ADC\RTD_ADC_ProfileReport.xlsx) 建议检查一下具体是哪个函数的执行时间过长导致的。 另外请问Adc_Calibrate的返回结果是什么?如果超时了的话,建议修改超时设置: Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
查看全文
Kinetis (../45/47/43;MCX W71/72/70) および MCX W23 電源プロファイルツール (ローカライズ機能を含む) このページは、Kinetis (KW35/KW38/KW45/KW47) および MCX Wx (MCX W71/72 および MCX W23) 電力プロファイル ツール専用です。 これにより、あなたのアプリケーション(オートモーティブ、IIoT、トラッカー/タグ、連続血糖モニタリング[CGM])の消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、単独製品またはフルシステムアプリケーション向けの専用パワープロファイルツールを提供する4つのマーケットセグメントが含まれています:   1. オートモーティブ Kinetis(KW3x/4x)オートモーティブ用パワープロファイルツール - NXPコミュニティ KW35/36製品用のBluetooth LEをスタンドアロンで使用。 Bluetooth LEはKW37/38/39製品用のスタンドアロン対応です。 KW45/KW47製品用のBluetooth LEをスタンドアロンで使用。 スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ) スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ) 2.IIoT Kinetis MCX Wxx(MCX W71/72 および MCX W23)IIoT用パワープロファイルツール - NXPコミュニティ Bluetooth LEは単体でMCX W71/MCX W72製品用です。 MCX W23製品のBluetooth LEをスタンドアロンで提供します。 スタンドアロン (IIoT) の MCX W71 および W72 マター製品用の 802.15.4 Matter ICD SIT & LIT および ZED。 Aliro Doorlockアプリケーション    3. オートモーティブおよび工業技術向けローカリゼーションアプリケーション(CCC CS) Kinetis MCX Wxx(KW47およびMCX W72)Bluetoothローカライゼーション用パワープロファイルツール - NXPコミュニティ 4.新しいツールが登場: Zephyr・ズボス Zephyr BLE KW45/MCX W71 または KW47/MCX W72 を使用して PCB を構築し、無線の性能と無線認証 (CE/FCC/IC) に関する情報をすべて得るには、次の重要なリンクを参照してください。 KW45(カーアクセサリ)を使ってPCBを構築する最良の方法 - NXPコミュニティ 電力および低電力アプリケーションノートについては、製品ページをご覧ください。便宜上、いくつかの直接リンクを次に示します。 MCXW71 - 電源管理ハードウェア KW45/K32W148 - 電源管理ハードウェア 異なる体験:ワンワイヤレス接続パワープロファイリングツール ワイヤレス・コネクティビティ電力プロファイリングツールをすべて一つにまとめています。 Kinetis(KW3x/4x、MCX W7xおよびMCX W23)One コネクティビティ Power Profile Tool - NXPコミュニティ 注:このツールはHTML形式で、使いやすく、以前のツール形式と比べて反応的(レイテンシなし)です。 製品: K32W0 製品: K32W1 製品: KW 34|35|36 製品: KW 37|38|39 製品: KW41Z |31Z | 21Z 製品: QN9080|SIP 製品: QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、エベレット。 パスワードは、変更や競合他社のベンチマークの詳細が多すぎることを避けるために設定されています。 ご不便をおかけして申し訳ございませんが、それはCANません。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) こんにちは、christophe_menardさん。 @christophe_menardシート保護のパスワードを教えていただけますか。よろしくお願いします。 EverettRao_0-1729134009121.png Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは 、 OneConnectivityPowerProfilingtool_SDK_26_03.zip を使用したいのですが、トロイの木馬が検出されました。 このツールの使い方。 サポートありがとうございます Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer この件を確認するため、社内のIT部門に問い合わせチケットを発行しました。 近いうちにまたご連絡します。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) こんにちは、 @pierre_demeyer IT認証の結果、CrowstrikeやDefenderのソフトウェアを使ってトロイの木馬ウイルスは検出されませんでした。
查看全文
使用 blhost 编程/擦除 LPC54(S)0xx 闪存 注意:本文档提供了简单的描述,有关 flashloader 的详细信息可以在 SDK_2.5.0_LPCXpresso54S018\middleware\mcu-boot\doc 中的 LPC540xx Flashloader 用户指南入门.pdf 中找到 下载LPC54S0xx SDK。 编译flashloader工程,生成flashloader.bin 该项目位于sdk\boards \lpcxpresso54s018\bootloader_examples\flashloader 使用 dfu-util.exe 或 IDE 将 flashloader.bin 加载到 RAM 中。 dfu-util 可以从http://dfu-util.sourceforge.net/releases/下载 配置ISP引脚,然后复位芯片,使芯片进入USB1 DFU启动模式。 Boot mode ISP2 PIO0_6引脚 ISP1 PIO0_5引脚 ISP0 PIO0_4引脚 描述 USB1 DFU启动 低 低 高 USB DFU 类用于通过 USB1 高速端口将图像下载到 SRAM 中。 将LPC54S0xx设备USB1高速口与PC通过USB连接。以下是加载flashloader.bin的命令行: $ dfu-util.exe –D flashloader.bin   使用 blhost 编程/擦除 LPC540xxM/LPC54S0xxM 闪存 一旦下载了闪存加载程序二进制文件并在 LPC54S0xx 平台上开始执行,并且 LPC54S0xx 平台USB1(高速)和主机之间仍然保持物理 USB 连接,闪存加载程序将准备好接收命令。 blhost -u 0x1fc9,0x01a2 --获取属性 12 blhost -u 0x1fc9,0x01a2 --填充内存0x2000d000 4 0xc0000004 blhost -u 0x1fc9,0x01a2 --配置内存 0xa 0x2000d000 blhost -u 0x1fc9,0x01a2 --获取属性 25 0xa blhost -u 0x1fc9,0x01a2 -t 100000 --闪存擦除区域 0x10000000 0x100000 blhost -u 0x1fc9,0x01a2 -t 100000 --写入内存 0x10000000 xxx.bin 注: xxx.bin为需要下载到flash中的目标文件。 作者:刘浩 感谢刘浩。
查看全文
AUT-N1761 自动驾驶汽车的第六感 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 为了实现自动驾驶,车辆需要准确地掌握周围的世界——就像人类驾驶员一样。汽车技术的目标是使车辆具备超越人类驾驶员感知的能力,从而能够实时做出最智能的决策。车辆传感器收集的信息不仅必须实时、准确,而且还必须能够抵御黑客攻击,这样我们才能将生命托付给它们。可靠的 ADAS 和适当的安全措施是自动驾驶汽车的关键因素。Vehicle-to-X 技术将可视范围扩展到驾驶员的视线之外,使驾驶员能够“看清”拐角处和障碍物。来自汽车网络的外部传感器信息和内部数据对于帮助消除全球道路上每年发生的 130 万起道路事故至关重要。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 为了实现自动驾驶,车辆需要准确地掌握周围的世界——就像人类驾驶员一样。汽车技术的目标是使车辆具备超越人类驾驶员感知的能力,从而能够实时做出最智能的决策。车辆传感器收集的信息不仅必须实时、准确,而且还必须能够抵御黑客攻击,这样我们才能将生命托付给它们。可靠的 ADAS 和适当的安全措施是自动驾驶汽车的关键因素。Vehicle-to-X 技术将可视范围扩展到驾驶员的视线之外,使驾驶员能够“看清”拐角处和障碍物。来自汽车网络的外部传感器信息和内部数据对于帮助消除全球道路上每年发生的 130 万起道路事故至关重要。 安全互联汽车和自动化汽车
查看全文
从 S1L 更新 S1L <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的 FDI 板上已经有S1L ,您可以按照以下步骤更新到S1L的早期版本或更高版本。此过程不应用于更新块 0 中的 kickstart 加载程序。 步骤 1:启动系统至S1L提示符。准备好S1L的更新版本。 第 2 步:在S1L提示符下,键入“load term raw 0x90000000”以启动新图像的S1L中的二进制接收。在您的终端程序上,将S1L文件(即 s1l_from_kick_gnu.bin)作为二进制文件发送到开发板。 步骤 3:传输完成后,向主板发送中断以返回提示。在TeraTerm中,可以从控制菜单或按 ALT-B 发送中断。 步骤4:擦除FLASH中用于S1L存储的块。这些是块 1 至 24。要非常小心,不要擦除用于 klickstart 加载程序的块 0。可以使用“erase 1 24”命令来擦除块。 步骤 5:将加载的S1L图像写入从块 1 开始的S1L区域。S1L图像通常在 56K 到 80K 之间,因此它很容易容纳在 1 个块中。命令“write 0x90000000 64 64”将执行此操作。写入命令占用扇区(而不是块) - 扇区 64 是块 1 的起始位置。 步骤 6:重置电路板以验证S1L图像是否已更新。 整个序列如下所示。您可以通过检查 S1L 启动时的构建日期来查看正在运行的不同版本的 S1L 。 FDI3250 快速启动 v1.00 NAND闪存初始化 正在运行第 1 阶段加载器... Future Designs, Inc. DK-xTS-LPC3250 板 构建日期:2010年9月10日 10:12:22 自动启动正在进行中,按任意键停止 linux>加载术语原始 0x90000000 开始终端下载,发送中断停止 文件加载成功 Linux>擦除 1 24 操作将覆盖引导加载程序 - 确定吗?(是/否): 起始块擦除 linux>写入 0x90000000 64 64 Linux>FDI3250 Kickstart v1.00 NAND闪存初始化 正在运行第 1 阶段加载器... 使用默认系统配置 Future Designs, Inc. DK-xTS-LPC3250 板 构建日期:2010年9月13日 11:20:12 FDI3250
查看全文
AUT-N1791 动手实践研讨会:使用 CNN 和其他分类算法识别交通标志 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该练习旨在进行实践,包括使用视觉处理器在各种图片上运行 CNN 来识别交通信号(停止、转弯、让行等)。首先,我们将介绍机器学习中所使用的算法的基本概念。课程结束后,我们将使用视觉处理器运行 CNN 来识别交通标志和无交通标志。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该练习旨在进行实践,包括使用视觉处理器在各种图片上运行 CNN 来识别交通信号(停止、转弯、让行等)。首先,我们将介绍机器学习中所使用的算法的基本概念。课程结束后,我们将使用视觉处理器运行 CNN 来识别交通标志和无交通标志。 安全互联汽车和自动化汽车
查看全文
libvpuwrap 1.0.46 デコーダー テスト用の 1280x720.mjpg テスト入力 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 申し訳ありませんが、この入力ファイルを共有する場所が見つかりません。これは、i.MX6Q VPU上のFSL 3.10.17 BSPを使用したMJPGデコード結果の破損で報告したVPU JPEGデコーダーの問題を再現するためのものです​ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 申し訳ありませんが、この入力ファイルを共有する場所が見つかりません。これは、i.MX6Q VPU上のFSL 3.10.17 BSPを使用したMJPGデコード結果の破損で報告したVPU JPEGデコーダーの問題を再現するためのものです​
查看全文
FRDM-KL02Z I2Cの2つを接続する際のヒント <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このサンプルでは、2つのFRDM-KL02Zを使用してI2Cをテストします。400KHzのボーレートで作業することにより、一部のお客様は、I2C_CLKの端に障害が発生したときにI2C_SDAが掘りを生成することに気付くかもしれません。実際には、それはI2Cポートレイアウトに関連しているはずであり、問題はなぜこれが起こるのか、そしてどのように掘り下げるのかということです。 実際には、I2Cピンはオープンドレインであるため、実際には誰も高い値を駆動しません。高い値は、ライン上のプルアップ抵抗のためだけに存在します。J7に搭載されているI2C0_SCL線とI2C0_SDA線を使用してFRDM-KL02Zを2本接続する場合、基板上の慣性センサーとの接続にもこれらの線を使用し、両線に4.7Kのプルアップがあります。問題は、両方のボードのラインに4.7Kのプルアップがあるため、プルアップが意図したよりも弱いことです。そのため、お客様は、役立つ2つのボードの1つからプルアップ抵抗を取り外す必要があります。さらに、I2C バス上に負荷を追加しているデバイスが増えている場合は、4.7K プルアップをさらに強力なプルアップに置き換える必要があるかもしれません。
查看全文
使用 DMA DS3.5 RTD300 的 S32K312 I2C 发送和接收示例 ******************************************************************************* 本演示应用程序的目的是展示 LPI2C-0作为主设备(MASTER)和LPI2C-1作为从设备(SLAVE),使用DMA进行发送(TX)和接收(RX)的用法,适用于S32K3xx系列MCU。 ------------------------------------------------------------------------------ * 测试硬件:S32K3X2EVB-Q172 * MCU:S32K312 * 编译器:S32DS3.5 * SDK 发布:RTD 3.0.0 * 调试器:PE micro * 目标:internal_FLASH ********************************************************************************
查看全文
S32 Design Studio 3.6.0 - 主要功能 (在 “我的视频” 中查看) 这段短视频介绍了 S32 Design Studio 3.6.0 版本所引入的主要功能。 视频展示了 S32DS 3.5 版本与 3.6 版本在产品架构及版本变更方面的对比,随后简要概述了新引入的主要功能,这些功能会对所有使用该工具集新版本的用户产生影响。 Eclipse IDE 使用和设置 概述
查看全文
Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey
查看全文
S32DS 问题涉及对外部文件的引用 目前,我们正在使用演示项目。项目文件夹 SDK/platform/drivers/src 目录中的文件是外部链接文件,这让我很难与他人共享该项目,因为我找不到这些文件。我想知道是否有办法将链接的文件挂载到项目中(不包括逐个复制的方法)。 Re: S32DS issue regarding the reference to external files 您好@NXP2 , 这是基于旧版 SDK 的 S32DS 项目的预期行为。一些 SDK 驱动程序文件被添加为 Eclipse 链接资源,因此它们会显示在项目树中,但物理文件仍然保留在已安装的 SDK 包位置。   对于共享此类项目,建议的方法是将项目与另一台 PC 上所需的确切 S32DS/SDK 代码包,软件包版本一起提供。如果需要完全独立的项目,则必须将 SDK 文件复制到项目中,并相应地更新链接的资源/版本路径。   请注意,由 S32 配置工具生成的较新的基于 RTD 的项目会在更新代码步骤期间自动将所需/生成的驱动程序文件复制到项目中。 顺祝商祺! 帕维尔 Re: S32DS issue regarding the reference to external files 目前使用的版本是 S32SDK_S32K1XX_RTM_4.0.2。如下图所示,这两个文件来自不同的文件夹。我们需要为此做任何设置吗? Re: S32DS issue regarding the reference to external files 您好@NXP2 , 您使用的是哪个版本的SDK,对应哪个S32K系列? 顺祝商祺! 帕维尔
查看全文