i.MX 95 NNStreamer C++ デモにおける NPU の問題 環境 |コンポーネント |詳細 | |-----------|--------| |ボード|i.MX 95 | |BSP |lf-6.12.49-2.2.0 | |カーネル |Linux...6.12.49-lts-next-gbf3cf0324593 #1 SMP PREEMPT 2026年6月16日火曜日 03:46:26 UTC aarch64 | |NNStreamer |2.4.2 | |テンソルフローライト |2.19.0 | |Neutron Delegate |libneutron_delegate.so レポート v1.0.0-f24d08e5、non-zerocp、2025年11月12日ビルド | |nnstreamer-examples |v1.6(SRCREV 062ebd1)およびv1.9(SRCREV 37d3d86)— 同じ動作 | |カメラ |OV5640 MIPIをlibcamera経由で取得(imx8-isi)、camera ID: /base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c | meta-nxp-demo-experience/recipes-examples/imx-nnstreamer-examples/imx-nnstreamer-examples.bb のバイナリが /opt/gopoint-apps/scripts/machine_learning/nnstreamer/ にインストールされます。 モデル すべてのモデルはYocto gopoint-base-appsのレシピ(downloads.json、lf-6.12.49_2.2.0 ブランチ)、ホスト先: https://github.com/nxp-imx-support/nxp-demo-experience-assets/raw/lf-6.12.49_2.2.0/models/ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/downloads/models/ のターゲットモデル: |課題|CPUモデル |NPUモデル| |------|-----------|-----------| |顔検出 |顔検出/ultraface_slim_uint8_float32.tflite |顔検出/ultraface_slim_uint8_float32_neutron.tflite | |物体検出 |オブジェクト検出/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite |オブジェクト検出/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite | |分類|分類/mobilenet_v1_1.0_224_quant_uint8_float32.tflite |分類/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite | 同じソースからのメタデータ: labels_mobilenet_quant_v1_224.txt、coco_labels_list.txt、box_priors.txt 必須環境変数 i.MX 95 上の OV5640 には libcamera ISI が必要です。 export CAMERA_BACKEND=libcamera export LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c'--- 課題1：顔検出 NPUモード CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --バックエンドNPU \ --model_pathダウンロード/モデル/顔検出/ultraface_slim_uint8_float32_neutron.tflite \ ――display_perf時間 パイプラインログ: 情報：アプリを起動します... デバッグ: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ !video/x-raw、幅=640、高さ=480、フレームレート=30/1、フォーマット=YUY2 !列 ！ティー名=t \ t. !キュー名=Thread-nn 最大サイズバッファ=2 リーキー=2 \ !imxvideoconvert_g2d name=scale_csc_g2d_0 !video/x-raw,width=320,height=240,format=RGB \ !tensor_converter !tensor_filter レイテンシ=1 framework=tensorflow-lite \ モデル=downloads/モデルs/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.SO name=face_filter \ !tensor_sink name=tsink_fd \ t. !キュー名=thread-img max-size-buffers=2 leaky=2 !cairooverlay name=cairooverlay \ !fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate デリゲート: 49 ノードのうち 2 ノードが委任され、2 つのパーティションがあります。 情報:Neutron Delegate バージョン:v1.0.0-f24d08e5、zerocp なし。 [libcamera v0.0.0+6194-lf-6.12.49-2.2.0] [ov5640 パイプライン: ov5640 -> csidev-4ad30000.csi -> formatter@20 -> crossbar] カメラ camera.cpp:1215ストリームの設定: (0) 640x480-YUYV/未設定 デバッグ: パイプラインの状態がNULLからREADYに変更されました。 デバッグ: パイプラインの状態がREADYからPAUSEDに変更されました。 デバッグ: パイプラインの状態が「一時停止」から「再生中」に変更されました。 結果：バウンディングボックスが文字化けした。 CPUモード — 同じパイプライン、異なるモデルとデレジン CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --バックエンド CPU \ --model_pathダウンロード/モデル/顔検出/ultraface_slim_uint8_float32.tflite \ ――display_perf時間 ログ： 情報：アプリを起動します... 情報: CPU 用の TensorFlow Lite XNNPACK デリゲートを作成しました。 デバッグ: [同じカメラパイプライン、同じimxvideoconvert_g2d] ... tensor_converter !tensor_filter レイテンシ=1 framework=tensorflow-lite \ モデル=downloads/モデル/face-detection/ultraface_slim_uint8_float32.tflite \ custom=Delegate:XNNPACK,NumThreads:6 ... DEBUG: パイプライン状態が変更...遊んでる。 結果： ✅ バウンディングボックスは正確です。 同じパイプライン、同じカメラ、同じimxvideoconvert_g2d YUY2→RGB変換。唯一の違い：量子化された.tflite+ XNNPACK 対 _neutron.tflite + Neutron デリゲート。 --- 課題2：物体検出（SSD MobileNetV2） NPUモード CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --バックエンドNPU \ --model_pathダウンロード/モデル/オブジェクト検出/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ --labels_pathダウンロード/モデル/オブジェクト検出/coco_labels_list.txt \ --boxes_pathダウンロード/モデル/オブジェクト検出/box_priors.txt \ ――display_perf時間 パイプラインログ: 情報：アプリを起動します... デバッグ: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ !video/x-raw、幅=640、高さ=480、フレームレート=30/1、フォーマット=YUY2 !列 ！ティー名=t \ t. !キュー名=Thread-nn 最大サイズバッファ=2 リーキー=2 \ !imxvideoconvert_g2d name=scale_csc_g2d_0 !video/x-raw,width=300,height=300,format=RGB \ !tensor_converter !tensor_filter レイテンシ=1 framework=tensorflow-lite \ モデル=downloads/モデル/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=detection_filter \ !tensor_decoder name=tensor_decode_bounding_boxes_1 mode=bounding_boxes option1=mobilenet-ssd \ オプション2=ダウンロード/モデル/オブジェクト検出/coco_labels_list.txt \ Option3=downloads/models/object-detection/box_priors.txt \ Option4=640:480 option5=300:300 !imxvideoconvert_g2d !mix.sink_0 \ t. !キュー名=thread-img max-size-buffers=2 leaky=2 !mix.sink_1 \ imxcompositor_g2d name=mix sink_0::zorder=2 sink_1::zorder=1 latency=200000000 min-upstream-latency=200000000 \ !cairooverlay name=perf !fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate デリゲート: 26 ノードのうち 1 ノードが委任され、1 つのパーティションがあります。 情報:Neutron Delegate バージョン:v1.0.0-f24d08e5、zerocp なし。 カメラ camera.cpp:1215ストリームの設定: (0) 640x480-YUYV/未設定 デバッグ: パイプラインの状態が変更されました...再生中。 結果：カメラの映像エリアが完全に真っ黒になった。バウンディングボックスの精度が低い。 CPUモード — 同じパイプライン、異なるモデルとデレジン CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --バックエンド CPU \ --model_path ダウンロード/モデル/オブジェクト検出/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite \ --labels_pathダウンロード/モデル/オブジェクト検出/coco_labels_list.txt \ --boxes_pathダウンロード/モデル/オブジェクト検出/box_priors.txt \ ――display_perf時間 ログ： 情報：アプリを起動します... 情報: CPU 用の TensorFlow Lite XNNPACK デリゲートを作成しました。 デバッグ: [同じパイプライン、同じimxvideoconvert_g2d、同じimxcompositor_g2d、XNNPACKデリゲート] デバッグ: パイプラインの状態が変更されました...再生中。 結果：カメラの映像領域は依然として完全に真っ黒です（NPUと同じ）。バウンディングボックスは正しい。 CPUとNPUの両方で画面が真っ暗になります。顔検出および分類（imxcompositor_g2dを使用しない場合）では、通常のカメラ映像が表示されます。 --- 課題3：分類（MobileNetV1） NPUモード CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --バックエンドNPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ --labels_pathダウンロード/モデル/分類/labels_mobilenet_quant_v1_224.txt \ ――display_perf時間 パイプラインログ: 情報：アプリを起動します... デバッグ: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ !video/x-raw、幅=640、高さ=480、フレームレート=30/1、フォーマット=YUY2 !列 ！ティー名=t \ t. !キュー名=Thread-nn 最大サイズバッファ=2 リーキー=2 \ !imxvideoconvert_g2d name=scale_csc_g2d_0 !video/x-raw,width=224,height=224,format=RGB \ !tensor_converter !tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=classification_filter \ !tensor_decoder name=tensor_decode_labeling_1 mode=image_labeling \ オプション1=ダウンロード数/モデル/分類/labels_mobilenet_quant_v1_224.txt!オーバーレイテキストシンク\ t. !キュー名=Thread-img 最大サイズバッファ=2 リーキー=2 \ !textoverlay name=overlay font-desc="Sans, 24" valignment=baseline halignment=center \ !imxvideoconvert_g2d !cairooverlay name=perf \ !fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate デリゲート: 4 つのノードのうち 1 つのノードが委任され、1 つのパーティションがあります。 情報:Neutron Delegate バージョン:v1.0.0-f24d08e5、zerocp なし。 カメラ camera.cpp:1215ストリームの設定: (0) 640x480-YUYV/未設定 デバッグ: パイプラインの状態が変更されました...再生中。 結果：カメラ映像は正常です。ラベルを一貫して間違えてつけること。 CPUモード — 同じパイプライン、異なるモデルとデレジン CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --バックエンド CPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite \ --labels_pathダウンロード/モデル/分類/labels_mobilenet_quant_v1_224.txt \ ――display_perf時間 ログ： 情報：アプリを起動します... 情報: CPU 用の TensorFlow Lite XNNPACK デリゲートを作成しました。 デバッグ: [同じパイプライン、同じimxvideoconvert_g2d、XNNPACKデリゲート] デバッグ: パイプラインの状態が変更されました...再生中。 結果： ✅ カメラ映像は正常です。ラベルは正確でカメラシーンに反応します。 --- 概要 3つのデモすべてにおいて、CPUとNPUは同じカメラパイプライン、同じimxvideoconvert_g2d YUY2→RGB変換、同じGStreamerパイプライン構造を使用します。唯一の違いは： |変数 |CPUテスト|NPUテスト| |----------|----------|----------| |モデル |*.tflite (量子化) |*_neutron.tflite | |代表 |XNNPACK (Delegate:XNNPACK) |neutron(Delegate:External, ExtDelegateLib:libneutron_delegate.so)| 結果： | デモ | CPU (量子化された .tflite)+ XNNPACK) |NPU(_neutron.tflite + Neutron) | |------|:---:|:---:| |顔検出 — バウンディングボックス | ✅ 正しい | ❌ 文字化けした | | 物体検出 — バウンディングボックス | ✅ 正しい | ❌ 不正確 | |分類 — ラベル | ✅ 正しい | ❌ 間違い | 物体検出では、CPUとNPUの両方でカメラ映像が黒く表示されることも確認されています。このデモでは、表示にimxcompositor_g2dを使用しています。顔検出と分類にはcairooverlay/textoverlayを使用し、通常どおり表示します。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues こんにちは @Chavira: ボードサポートパッケージ(BSP)のバージョンは 6.12.49です。Yocto経由で nxp-nnstreamer-example(SRCREV: 062ebd1)を別々に作成し、コンパイルしたdebsをターゲットボードにデプロイしました。GoPointアプリからデモを起動する代わりに、付属のdownloads.jsonに従って手動でモデルファイルをダウンロードしました そして、前述のコマンドを使用してプログラムを実行した。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues こんにちは、 @BIG_FLY さん、 GoPointのデモに関する情報、ありがとうございました。 デモをどのように運営しているのか、詳しく教えていただけますか? GoPointアプリケーションで直接実行していますか?それとも自分でクロスコンパイルしましたか? デモの実行方法をステップバイステップで説明していただけますか? BSPバージョン6.12.49を使っていますか? どのボードを使っていますか? この情報は、お客様のシステム構成をより深く理解し、潜在的な問題点を特定するのに役立ちます。 よろしくお願いします、 チャビラ

PN7220のカード読み取り性能は過剰である。 PN7220プロジェクトはカード読み取り性能が非常に高く、Vカードの読み取り範囲は150mm以上です。ARCとDGRM_BBAを調整しても、読み取り範囲は約110mmにしか縮小されません。EMVCo RR2の認証取得が必要なため、現在のところ最大電圧は4.5Vまでしか下げることができません。 カードリーダーのパフォーマンスを低下させる可能性のある他の要因はありますか？ よろしくお願いいたします。 Re: PN7220 读卡性能过剩 ここでは、MAX_READ電圧が4.5V（0x07）に設定され、その後DPCが適用されます。_EMVCoスイッチが機能していません。切り替え後も最大電圧が5.7Vのままです（フォーラムでは最大電圧は4.5Vと記載されています）。これは正常でしょうか？ Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang アンテナの整合インピーダンスを20～22Ωに調整してください。これにはハードウェアの変更が必要です。もう一度試してください。 Re: PN7220 读卡性能过剩 目標電流を200mAに調整した後、電流を100mAに下げ、さらに下げても、Vカードの性能は変化しなかった。 Re: PN7220 读卡性能过剩 このクライアントからは完全版は提供されませんでした。 Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang 別の方法としては、整合インピーダンスを20～21Ωに調整する方法があります。 Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang 目標電流は200mAまで調整可能です。ぜひ試してみてください！ さらに、この回路図はアンテナ部だけでなく、7220の完全な設計も示している。 Re: PN7220 读卡性能过剩 目標電流は240mAです。添付ファイルはデバッグ済みのXMLファイルです。 Re: PN7220 读卡性能过剩 最新のCockpitでは、異なる目標電流を設定できるようになったことに気づきました（テーブル間で共有されます）。これはEMVCo RR2テストに影響しますか？それとも、システムには自動的に切り替える認識メカニズムが備わっているのでしょうか？ Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang DPC表、アンテナスミッチチャート、および回路図を提供していただけますか？ 目標は何ですか？現在の目標は何ですか？ Re: PN7220 读卡性能过剩 DPCのデバッグは完了しましたが、カードリーダーのパフォーマンス低下には効果がありません。現在、クライアントの要件ではパフォーマンスが75mmを超えてはならないと規定されていますが、現状ではそれを50%超過しています。 Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang また、DPCを有効にしてカリブレートすることもできますので、ぜひ試してみてください。 Re: PN7220 读卡性能过剩 こんにちは、 @mark_tang それは普通のことです。

[S32K358] Version for HSM, RTD on s32k358 dear nxp What is version for HSM, RTD on s32k358? Thanks, Bryan Re: [S32K358] Version for HSM, RTD on s32k358 Hi @bryan_hong  It’s recommended to use the latest version of RTD and HSE firmware. That means: - HSE firmware for S32K358 version 0.2.55.0 - RTD 7.x.x As mentioned in the release notes, Crypto driver from RTD 7.x.x is tested with HSE firmware 0.2.55.0. Regards, Lukas

有没有S32K311芯片 modbus协议的参考例程 Re: 有没有S32K311芯片 modbus协议的参考例程 嗨@Finnc 请查看我在这里发布的帖子： https://community.nxp.com/t5/S32K/Modbus-RTU/mp/2184516/highlight/true#M53445 此致， Lukas

Are there any reference examples of Modbus protocol for the S32K311 chip? Re: 有没有S32K311芯片 modbus协议的参考例程 Hi @Finnc  Please take a look at my post here: https://community.nxp.com/t5/S32K/Modbus-RTU/m-p/2184516/highlight/true#M53445 Regards, Lukas

FS26 - 微控制器兼容性 晚上好， 关于 FS26 - S32KXX 系列的兼容性，我有以下几个问题。 1-是否有一个可订购的 FS26 选件，既兼容 s32k344 又兼容 s32k396？ 2. FS26 零件编号的倒数第三位和倒数第四位数字分别代表什么？（IEMFS2633HMDE4AD（指 E4）是否表示与特定微控制器兼容？ 谢谢 Re: FS26 - MICROCONTROLLER COMPATIBILITY 你好，恩里科， 即使 S32K344 的电流消耗较低，但为 S32K396 编程的版本在电压设置、时序、监控阈值和功能安全配置方面仍然可能有所不同，因此不应假定它们可以互换。FS26 数据表中提供了详细的程序版本定义，尤其是在可订购的零件编号表、OTP 描述部分和数据表中引用的完整 OTP 内容表中。 BRs，托马斯 Re: FS26 - MICROCONTROLLER COMPATIBILITY 谢谢你的回答。 -为什么预编程的 FS26 与 s32k396 兼容，而与 s32k344 不兼容，因为 s32k344 的电流消耗比 s32k396 低？ -是否有文档定义了各种程序版本？ 谢谢， 恩里科 Re: FS26 - MICROCONTROLLER COMPATIBILITY 你好，恩里科， 不，目前没有一个预先编程、可订购的 FS26 零件编号能够原生支持这两种 MCU。 关于零件编号后缀（例如 MFS2633HMDE4AD 中的 E4），此后缀代表特定的 OTP/编程变体。它本身并不是一个通用的MCU兼容性字段。实际基本设备功能主要由部件号中的 FS26xyB/FS26xyD 部分定义，该部分定义了硅特性集（例如 VCORE 功能、跟踪器数量、LDT/FS1B 存在情况以及 ASIL B 与 ASIL D），而后缀标识了确切的编程版本。 BRs，托马斯

FS26 - MICROCONTROLLER COMPATIBILITY Good evening, I have the following questions regarding the FS26 - S32KXX family compatibility.  1-Is there a single orderable FS26 option compatible both with a s32k344 and s32k396? 2-what do the third and fourth last digits of the FS26 part number stand for? (i.e. MFS2633HMDE4AD referring to E4)  Is the compatibility with a specific microcontroller defined in those digits? Thank you Re: FS26 - MICROCONTROLLER COMPATIBILITY Hello Enrico, Even if S32K344 has lower current consumption, a version programmed for S32K396 may still differ in voltage settings, sequencing, monitoring thresholds and safety configuration, so it should not be assumed to be interchangeable. The detailed programmed-version definition is provided in the FS26 datasheet, especially in the orderable part number tables, the OTP description section and the complete OTP content table referenced by the datasheet.  BRs, Tomas Re: FS26 - MICROCONTROLLER COMPATIBILITY Thank you for your answer. -What makes a preprogrammed FS26 compatible with the s32k396 non-compatible with the s32k344, since the s32k344 has less current consumption compared to the s32k396? -Is there a document that defines the various programmed versions? Thanks, Enrico Re: FS26 - MICROCONTROLLER COMPATIBILITY Hello Enrico, No, there is no single pre-programmed, orderable FS26 part number that natively supports both MCUs. Regarding the part number suffix (for example E4 in MFS2633HMDE4AD), this suffix represents a specific OTP/programmed variant. It is not by itself a generic MCU compatibility field. The actual base device capability is mainly defined by the FS26xyB/FS26xyD portion of the part number, which defines the silicon feature set (for example VCORE capability, number of trackers, LDT/FS1B presence and ASIL B vs ASIL D), while the suffix identifies the exact programmed version. BRs, Tomas

FS26 - マイクロコントローラ互換性 こんばんは、 FS26とS32KXXファミリの互換性について、以下の質問があります。 1. s32k344とs32k396の両方に対応する、注文可能なFS26オプションは1つだけありますか？ 2. FS26という部品番号の最後の3桁目と4桁目は何を表していますか？（つまり）MFS2633HMDE4AD E4のことを指しています)特定のマイクロコントローラとの互換性はこれらの数字で定義されていますか? ありがとう Re: FS26 - MICROCONTROLLER COMPATIBILITY こんにちは、エンリコさん。 S32K344電流消費が少なくても、S32K396向けにプログラムされたバージョンは電圧設定、シーケンス、モニタリング閾値、セーフティ設定に異なる可能性があるため、互換性があると考えるべきではありません。プログラムバージョンの詳細な定義は、FS26データシート、特に注文可能な部品番号表、OTP説明セクション、およびデータシートで参照されている完全なOTPコンテンツ表に記載されています。 BRs、トーマス Re: FS26 - MICROCONTROLLER COMPATIBILITY ご回答ありがとうございます。 -s32k396と互換性のあるプリプログラム済みのFS26が、s32k344とは互換性がないのはなぜですか？s32k344はs32k396に比べて消費電流が少ないのに。 各種プログラム版を定義した文書はありますか？ ありがとう、 エンリコ Re: FS26 - MICROCONTROLLER COMPATIBILITY こんにちは、エンリコさん。 いいえ、両方のMCUをネイティブにサポートする単一の事前プログラムされた注文可能なFS26部品番号は存在しません。 部品番号の接尾辞（例えば、MFS2633HMDE4ADのE4）は、特定のOTP/プログラム済みバリアントを表します。それ自体は一般的なMCU互換性フィールドではありません。実際の基本デバイスの機能は、主に部品番号のFS26xyB/FS26xyDの部分によって定義され、これはシリコンの機能セット（例えば、VCORE機能、トラッカーの数、LDT/FS1Bの有無、ASIL BかASIL Dかなど）を定義します。一方、サフィックスは正確なプログラム済みバージョンを識別します。 BRs、トーマス

S32K311チップ用のModbusプロトコルの参考例はありますか？ Re: 有没有S32K311芯片 modbus协议的参考例程 こんにちは、 @Finnc 私の投稿をこちらでご覧ください。 https://community.nxp.com/t5/S32K/Modbus-RTU/mp/2184516/highlight/true#M53445 よろしくお願いいたします。 ルーカス

Unifiのようなソフトウェアではなく、OpenWrtを使ったことを後悔していますか？ 私の無知をお許しください。UnifiではなくOpenWrtを使ったことを後悔していますか？OpenWrtを使って、自宅の実験室用にルーターを設定しています。多くのことを学びつつありますが、時間がかかるので、Unifiのようなきれいな結果には絶対にならないでしょう。 OpenWrtで一番気に入っているのは、安価なデバイスでケーキを設定できて、1Gbpsのルーティングを代わりに行ってくれることです。また、自分のニーズに合わせてUnboundをカスタマイズできるのは素晴らしいです。 Re: Do you regret using OpenWrt instead of something like Unifi? こんにちは、 どのプロセッサを使っていますか? よろしくお願いします。

The PN7220's card reading performance is excessive. The PN7220 project has excessive card reading performance; the V-card reading range is ≥150mm. Adjusting ARC and DGRM_BBA only reduces the reading range to around 110mm. Due to the need to pass EMVCo RR2, the maximum voltage can currently only be reduced to 4.5V. Are there any other parameters that can reduce card reader performance? Thank you. Re: PN7220 读卡性能过剩 Here, the MAX_READ voltage is set to 4.5V (0x07), then DPC is applied. The _EMVCo switch is not working; after switching, the maximum voltage is still 5.7V (the forum shows the maximum voltage is 4.5V). Is this normal? Re: PN7220 读卡性能过剩 Hello @mark_tang Adjust the antenna matching impedance to 20~22 Ω. This requires hardware modification; try again. Re: PN7220 读卡性能过剩 After adjusting the target current to 200mA, the V-card's performance remained unchanged when the current was reduced to 100mA and then further reduced. Re: PN7220 读卡性能过剩 The complete version was not released to us by this client. Re: PN7220 读卡性能过剩 Hello @mark_tang Another option is to adjust the matching impedance to 20~21 Ω. Re: PN7220 读卡性能过剩 Hello @mark_tang The target current can be adjusted to 200mA, give it a try! Furthermore, the schematic diagram does not only show the antenna section, but also the complete 7220 design. Re: PN7220 读卡性能过剩 The target current is 240mA. The attached file is the debugged XML file. Re: PN7220 读卡性能过剩 I noticed that the latest Cockpit allows setting different target currents (shared across tables). Will this affect the EMVCo RR2 test, or does the system have a recognition mechanism that automatically switches between them? Re: PN7220 读卡性能过剩 Hello @mark_tang Could you please provide the DPC table, the antenna smitch chart, and the schematic diagram? What is the target? What is the current target? Re: PN7220 读卡性能过剩 DPC has been debugged, but it doesn't help reduce card reader performance. Currently, client requirements stipulate performance cannot exceed 75mm, and it's currently exceeding that by 50%. Re: PN7220 读卡性能过剩 Hello @mark_tang  Also, you can enable  and calibratie DPC, please try. Re: PN7220 读卡性能过剩 Hello @mark_tang  it's normal.

PN7220 读卡性能过剩 PN7220 项目读卡性能过剩，V卡性能≥150mm，调整ARC ，DGRM_BBA，性能只能降到110mm左右；由于需要过EMVCo RR2 ，目前最大电压只能降到4.5V 请问是否还有其他参数可以把读卡性能降下来，谢谢 Re: PN7220 读卡性能过剩 这边设置0x07 MAX_READ电压4.5，再DPC _EMVCo这边没有生效，切换后，最大电压还是5.7V（forum这边max电压生效为4.5V），这个是正常的吗 Re: PN7220 读卡性能过剩 Hello @mark_tang  将天线匹配阻抗调整到20~22 Ω. 这个需要修改硬件，再试试吧 Re: PN7220 读卡性能过剩 Forum 目标电流调整到200mA后，V卡降到100，再进一步降低电流，V卡性能没有变化 Re: PN7220 读卡性能过剩 完整的，这个客户没有释放给我们 Re: PN7220 读卡性能过剩 Hello @mark_tang  还有一个方案可以将匹配阻抗调整到20~21 Ω. Re: PN7220 读卡性能过剩 Hello @mark_tang  目标电流可以调整到200mA，试试！ 另外，原理图不是仅天线部分，完整的7220设计部分 Re: PN7220 读卡性能过剩 目标电流240mA,附件是调试后的xml Re: PN7220 读卡性能过剩 我看最新的cockpit里目标电流可设置不同的（table共用），这个会影响到EMVCo RR2测试吗，还是系统有识别机制，自动切换 Re: PN7220 读卡性能过剩 Hello @mark_tang  那么您提供下DPC table，天线的smitch chart 和原理图！ 目标是多少？当前是多少？ Re: PN7220 读卡性能过剩 DPC已调试，对降读卡性能没什么帮助，现在客户端要求性能不能超过75mm，目前超了50% Re: PN7220 读卡性能过剩 你好@mark_tang 另外，您还可以启用并校准DPC，请尝试一下。 Re: PN7220 读卡性能过剩 你好@mark_tang 这是正常的。

[S32K358] 适用于 HSM、RTD 的 s32k358 版本 亲爱的恩智浦 s32k358 上的 HSM 和 RTD 版本是什么？ 谢谢， 布莱恩 Re: [S32K358] Version for HSM, RTD on s32k358 嗨@bryan_hong 建议使用最新版本的RTD和HSE固件。这意味着： - S32K358 的 HSE 固件版本 0.2.55.0 - RTD 7.xx 如发行说明中所述，RTD 7.xx 中的 Crypto 驱动程序已使用 HSE 固件 0.2.55.0 进行测试。 此致， Lukas

你后悔使用 OpenWrt 而不是像 Unifi 这样的固件吗？ 请原谅我的无知，但您是否后悔使用 OpenWrt 而不是 Unifi？我正在为我的家庭实验室配置一台运行 OpenWRT 的路由器。我确实学到了很多东西，别误会，但这太耗时了，而且最终结果肯定不会像 Unifi 那样呈现一个漂亮的界面。 我最喜欢 OpenWrt 的一点是，我可以在一台廉价设备上配置 Cake，它就能帮我完成 1Gbps 的路由。此外，能够根据我的需求定制 Unbound 也非常棒。 Re: Do you regret using OpenWrt instead of something like Unifi? 你好， 你使用的是哪款处理器？ 此致

i.MX 95 NNStreamer C++ Demo NPU Issues Environment | Component | Detail | |-----------|--------| | Board | i.MX 95 | | BSP | lf-6.12.49-2.2.0 | | Kernel | Linux ... 6.12.49-lts-next-gbf3cf0324593 #1 SMP PREEMPT Tue Jun 16 03:46:26 UTC 2026 aarch64 | | NNStreamer | 2.4.2 | | TensorFlow Lite | 2.19.0 | | Neutron Delegate | libneutron_delegate.so reports v1.0.0-f24d08e5, non-zerocp, built Nov 12 2025 | | nnstreamer-examples | v1.6 (SRCREV 062ebd1) and v1.9 (SRCREV 37d3d86) — same behavior | | Camera | OV5640 MIPI via libcamera (imx8-isi), camera ID: /base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c | Binaries from meta-nxp-demo-experience/recipes-examples/imx-nnstreamer-examples/imx-nnstreamer-examples.bb, installed at /opt/gopoint-apps/scripts/machine_learning/nnstreamer/. Models All models are from the Yocto gopoint-base-apps recipe (downloads.json, lf-6.12.49_2.2.0 branch), hosted at: https://github.com/nxp-imx-support/nxp-demo-experience-assets/raw/lf-6.12.49_2.2.0/models/ Models on target at /opt/gopoint-apps/scripts/machine_learning/nnstreamer/downloads/models/: | Task | CPU model | NPU model | |------|-----------|-----------| | Face Detection | face-detection/ultraface_slim_uint8_float32.tflite | face-detection/ultraface_slim_uint8_float32_neutron.tflite | | Object Detection | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite | | Classification | classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite | classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite | Metadata from same source: labels_mobilenet_quant_v1_224.txt, coco_labels_list.txt, box_priors.txt. Required Environment Variables OV5640 on i.MX 95 requires libcamera ISI: export CAMERA_BACKEND=libcamera export LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c'--- Issue 1: Face Detection NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --backend NPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=320,height=240,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=face_filter \ ! tensor_sink name=tsink_fd \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 ! cairooverlay name=cairooverlay \ ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 2 nodes delegated out of 49 nodes with 2 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. [libcamera v0.0.0+6194-lf-6.12.49-2.2.0] [ov5640 pipeline: ov5640 -> csidev-4ad30000.csi -> formatter@20 -> crossbar] Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed from NULL to READY. DEBUG: Pipeline state changed from READY to PAUSED. DEBUG: Pipeline state changed from PAUSED to PLAYING. Result: Bounding boxes garbled. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --backend CPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same camera pipeline, same imxvideoconvert_g2d] ... tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ custom=Delegate:XNNPACK,NumThreads:6 ... DEBUG: Pipeline state changed ... PLAYING. Result: ✅ Bounding boxes accurate. Same pipeline, same camera, same imxvideoconvert_g2d YUY2→RGB conversion. Only difference: quantized .tflite + XNNPACK vs _neutron.tflite + neutron delegate. --- Issue 2: Object Detection (SSD MobileNetV2) NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --backend NPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=300,height=300,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=detection_filter \ ! tensor_decoder name=tensor_decode_bounding_boxes_1 mode=bounding_boxes option1=mobilenet-ssd \ option2=downloads/models/object-detection/coco_labels_list.txt \ option3=downloads/models/object-detection/box_priors.txt \ option4=640:480 option5=300:300 ! imxvideoconvert_g2d ! mix.sink_0 \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 ! mix.sink_1 \ imxcompositor_g2d name=mix sink_0::zorder=2 sink_1::zorder=1 latency=20000000 min-upstream-latency=20000000 \ ! cairooverlay name=perf ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 1 nodes delegated out of 26 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed area completely black. Bounding boxes inaccurate. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --backend CPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same pipeline, same imxvideoconvert_g2d, same imxcompositor_g2d, XNNPACK delegate] DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed area still completely black (same as NPU). Bounding boxes correct. Black screen in both CPU and NPU. Face detection and classification (which do not use imxcompositor_g2d) display normal camera feed. --- Issue 3: Classification (MobileNetV1) NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --backend NPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=224,height=224,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=classification_filter \ ! tensor_decoder name=tensor_decode_labeling_1 mode=image_labeling \ option1=downloads/models/classification/labels_mobilenet_quant_v1_224.txt ! overlay.text_sink \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 \ ! textoverlay name=overlay font-desc="Sans, 24" valignment=baseline halignment=center \ ! imxvideoconvert_g2d ! cairooverlay name=perf \ ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 1 nodes delegated out of 4 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed normal. Label consistently wrong. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --backend CPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same pipeline, same imxvideoconvert_g2d, XNNPACK delegate] DEBUG: Pipeline state changed ... PLAYING. Result: ✅ Camera feed normal. Label correct and responsive to camera scene. --- Summary In all three demos, CPU and NPU use the same camera pipeline, same imxvideoconvert_g2d YUY2→RGB conversion, same GStreamer pipeline structure. The only difference is: | Variable | CPU test | NPU test | |----------|----------|----------| | Model | *.tflite (quantized) | *_neutron.tflite | | Delegate | XNNPACK (Delegate:XNNPACK) | neutron (Delegate:External,ExtDelegateLib:libneutron_delegate.so) | Results: | Demo | CPU (quantized .tflite + XNNPACK) | NPU (_neutron.tflite + neutron) | |------|:---:|:---:| | Face Detection — bounding boxes | ✅ correct | ❌ garbled | | Object Detection — bounding boxes | ✅ correct | ❌ inaccurate | | Classification — label | ✅ correct | ❌ wrong | Object detection also shows black camera feed in both CPU and NPU. This demo uses imxcompositor_g2d for display; face detection and classification use cairooverlay/textoverlay and display normally. Re: i.MX 95 NNStreamer C++ Demo NPU Issues Hi @Chavira : The Board Support Package (BSP) version is 6.12.49. I built nxp-nnstreamer-examples (SRCREV: 062ebd1) separately via Yocto, then deployed the compiled debs onto the target board. Instead of launching the demos via the GoPoint application, I manually downloaded the model files according to the accompanying downloads.json  and ran the programs using the commands mentioned earlier. Re: i.MX 95 NNStreamer C++ Demo NPU Issues Hi @BIG_FLY,  Thanks for the information regarding the GoPoint demos. Could you please clarify how you are running the demos? Are you running them directly using the GoPoint application, or did you cross compile them yourself? Could you describe step by step how you are executing the demos on your side? Are you using BSP version 6.12.49? Which board are you using? This information will help us better understand your setup and identify any potential issues. Best regards, Chavira

i.MX 95 NNStreamer C++ 演示 NPU 问题 环境 | 元器件 | 细节 | |-----------|--------| | 主板 | i.MX 95 | | 电路板支持包。 | lf-6.12.49-2.2.0 | | 内核 | Linux ... 6.12.49-lts-next-gbf3cf0324593 #1 SMP PREEMPT 2026年6月16日星期二 03:46:26 UTC aarch64 | | NNStreamer | 2.4.2 | | TensorFlow Lite | 2.19.0 | | Neutron 委托 | libneutron_delegate.so 报告版本为 v1.0.0-f24d08e5，非零cp，构建于 2025 年 11 月 12 日 | | nnstreamer-examples | v1.6 (SRCREV 062ebd1) 和 v1.9 (SRCREV 37d3d86) — 行为相同 | |相机 | OV5640 MIPI 通过 libcamera (imx8-isi)，相机 ID：/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c | 从 meta-nxp-demo-experience/配方示例/imx-nnstreamer-examples/imx-nnstreamer-examples.bb 获取二进制文件，安装在 /opt/gopoint-apps/scripts/machine_learning/nnstreamer/。 模型 所有模型均来自 Yocto gopoint-base-apps 配方（downloads.json，lf-6.12.49_2.2.0 分支），托管于： https://github.com/nxp-imx-support/nxp-demo-experience-assets/raw/lf-6.12.49_2.2.0/models/ 目标模型位于 /opt/gopoint-apps/scripts/machine_learning/nnstreamer/downloads/models/： | 任务 | CPU 型号 | NPU 型号 | |------|-----------|-----------| | 人脸检测 | face-detection/ultraface_slim_uint8_float32.tflite | face-detection/ultraface_slim_uint8_float32_neutron.tflite | | 目标检测 | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite | | 分类 | classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite | classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite | 来自同一来源的元数据：labels_mobilenet_quant_v1_224.txtcoco_labels_list.txt，box_priors.txt。 必需的环境变量 i.MX 95 上的 OV5640 需要 libcamera ISI： export CAMERA_BACKEND=libcamera export LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c'--- 问题 1：人脸检测 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --后端 NPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=320,height=240,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=face_filter \ ！张量接收器名称=tsink_fd \ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 ！cairooverlay 名称=cairooverlay \ ！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：49 个节点中有 2 个节点被委托，共 2 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 [libcamera v0.0.0+6194-lf-6.12.49-2.2.0] [ov5640 管道：ov5640 -> csidev-4ad30000.csi -> formatter@20 -> crossbar] 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态从 NULL 变为 READY。 调试：管道状态从就绪变为暂停。 调试：管道状态从暂停变为播放。 结果：边界框错乱。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --后端 CPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试信息：[相同的相机流程，相同的 imxvideoconvert_g2d] ... tensor_converter！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ custom=Delegate:XNNPACK,NumThreads:6 ... 调试：管道状态已更改……正在播放。 结果： ✅ 边界框准确。 相同的流程，相同的摄像机，相同的 imxvideoconvert_g2d YUY2→RGB 转换。唯一区别：量化的 .tflite+ XNNPACK 与 _neutron.tflite + neutron 委托。 --- 问题 2：目标检测（SSD MobileNetV2） 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --后端 NPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=300,height=300,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=detection_filter \ ！tensor_decoder name=tensor_decode_bounding_boxes_1 mode=bounding_boxes option1=mobilenet-ssd \ option2=downloads/models/object-detection/coco_labels_list.txt \ option3=downloads/models/object-detection/box_priors.txt \ 选项4=640:480 选项5=300:300 ！imxvideoconvert_g2d！mix.sink_0 \ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 ！mix.sink_1 \ imxcompositor_g2d name=mix sink_0::zorder=2 sink_1::zorder=1 latency=20000000 min-upstream-latency=20000000 \ ！cairooverlay 名称=perf！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：26 个节点中有 1 个节点被委托，共 1 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态已更改……正在播放。 结果：摄像头画面区域完全黑屏。边界框不准确。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --后端 CPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试：[相同的管道，相同的 imxvideoconvert_g2d，相同的 imxcompositor_g2d，XNNPACK 代理] 调试：管道状态已更改……正在播放。 结果：摄像头画面区域仍然完全是黑色的（与 NPU 相同）。边界框正确。 CPU和NPU均出现黑屏。人脸检测和分类（不使用 imxcompositor_g2d）显示正常的摄像头画面。 --- 问题 3：分类（MobileNetV1） 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --后端 NPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=224,height=224,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=classification_filter \ ！张量解码器名称=tensor_decode_labeling_1 模式=图像标注 \ option1=downloads/models/classification/labels_mobilenet_quant_v1_224.txt ！overlay.text_sink\ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 \ ！textoverlay name=overlay font-desc="Sans, 24" valignment=baseline halignment=center \ ！imxvideoconvert_g2d！cairooverlay name=perf \ ！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：4 个节点中有 1 个节点被委托，共 1 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态已更改……正在播放。 结果：摄像头画面正常。标签始终错误。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --后端 CPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试信息：[相同的管道，相同的 imxvideoconvert_g2d，XNNPACK 代理] 调试：管道状态已更改……正在播放。 结果： ✅ 摄像头画面正常。标签正确且能根据摄像机画面做出响应。 --- 摘要 在这三个演示中，CPU 和 NPU 都使用相同的相机管线、相同的 imxvideoconvert_g2d YUY2→RGB 转换以及相同的 GStreamer 管线结构。唯一的区别在于： | 变量 | CPU 测试 | NPU 测试 | |----------|----------|----------| | 模型 | *.tflite（量子化） | *_neutron.tflite | | 委托 | XNNPACK (委托:XNNPACK) | neutron (委托:External,ExtDelegateLib:libneutron_delegate.so)| 结果： | 演示 | CPU（量化 .tflite）+ XNNPACK) | NPU (_neutron.tflite + neutron) | |------|:---:|:---:| 人脸检测——边界框 | ✅ 正确 | ❌ 乱码 | | 目标检测 — 边界框 | ✅ 正确 | ❌ 不准确 | | 分类 — 标签 | ✅ 正确 | ❌ 错误 | 目标检测结果显示，CPU 和 NPU 中的摄像头画面均为黑色。此演示使用 imxcompositor_g2d 进行显示；人脸检测和分类使用 cairooverlay/textoverlay 并正常显示。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues 嗨@Chavira ： 板级支持包（BSP）版本为6.12.49 。我通过 Yocto 单独构建了nxp-nnstreamer-examples (SRCREV: 062ebd1 )，然后将编译好的 deb 部署到目标板上。我没有通过 GoPoint 应用程序启动演示程序，而是根据随附的downloads.json文件手动下载了模型文件。并使用前面提到的命令运行程序。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues 嗨@BIG_FLY ， 感谢您提供的有关 GoPoint 演示的信息。 请问您能否详细说明一下您是如何运行演示的？ 您是直接使用 GoPoint 应用程序运行这些程序，还是自己交叉编译的？ 您能否一步一步地描述一下您那边是如何进行演示的？ 您使用的是 电路板支持包。 版本 6.12.49 吗？ 你用的是哪款板？ 这些信息将有助于我们更好地了解您的设备配置并发现任何潜在问题。 此致， 查维拉

[S32K358] HSM、RTD対応バージョン（S32K358） 親愛なるNXP s32k358におけるHSM、RTDのバージョンは何ですか？ ありがとう、 ブライアン Re: [S32K358] Version for HSM, RTD on s32k358 こんにちは、 @bryan_hong さん。 RTDおよびHSEファームウェアは最新バージョンを使用することをお勧めします。つまり、次のようになるということです。 - S32K358用HSEファームウェア バージョン0.2.55.0 - RTD 7.xx リリースノートにもあるように、RTD 7.x.xのCryptoドライバはHSEファームウェア0.2.55.0でテストされています。 よろしくお願いいたします。 ルーカス

RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 2. 図2：モジュールAの100kHzにおけるロジックアナライザの波形 3. 図3：モジュールBの400kHzにおける波形 i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート：400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V～5V サブボード：ADUM1251 - モジュールA 5V～3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー 疑い： 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。（第47.3.1.4章を参照）タイミングパラメータ） マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月

S32K144チップにはクロック構成の問題があり、クロックを変更するとタイミング周期が変わってしまう。 S32K144の開発中に、以下の問題に遭遇しました。 初期化タイマーの割り込みオーバーフロー期間は1秒に設定する必要があります。 前提として、私のクロック設定は8MHzです。 しかし、時計を20Mの時計に変えた後… タイマーのオーバーフロー期間が1秒ではなく、400ミリ秒になっていることに気づきました。 しかし、タイマーのクロック設定は依然として8MHzの内部クロックに設定されたままです。 PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* クロックソース=1、8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* FTMレジスタのクロックを有効にする */ この問題の原因となっている設定上の問題が何なのか、私には分かりません。 Re: S32K144芯片的时钟配置问题，更改时钟后定时周期出现变化 ハイ 次の S32K1 RM の表 27-9 を参照してください。peripheral module clocking (continued),FTM具体選択哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1 Register (PCC_FTM1)的PCS位。 プロセッサ エキスパートがコンフィギュレーションを生成し、ベアメタル モードでレジスタを直接操作しました。SDK サイトを使用した API が原因でベアメタル プログラムがクラッシュしたかどうかはわかりません。 さらに、ProcessorExpert 搭載 SDK の API を使用する場合は、ベアメタルの直接操作レジスタの構築リファレンス S32K144_Project_FTM サンプル ftm_periodic_interrupt_s32k144 を参照してください。 よろしくお願いいたします ロビン

如何通过 I2C 从 NTP5332 读取 UID 我有一个问题，如何通过 I2C 接口从 NTP5332 读取 UID？我在数据手册中没有找到 UID 的块地址。 Re: How to read UID from NTP5332 through I2C Hello @zhjyang  UID 是芯片内部唯一标识，不在任何 memory block 中，只能通过 NFC接口RF 命令读取,比如 INVENTORY （ISO15693）