Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
S32DS環境とSDKパッケージを再インストールしたことで、以前のプロジェクトがコンパイルに失敗する原因となりました S32DS環境とSDKパッケージを再インストールしたことで、以前のプロジェクトがコンパイルに失敗する原因が発生しました。 以前はS32DS V2.2とSDK RTM 2.0.0を使っていました。今は再インストール後、S32DSを使っています。ARM.2018.R1もインストールし、SDK RTM 2.0.0もインストールしています。しかし今はプロジェクトをコンパイルできません。プロジェクト自体を認識できないようです。写真で詳細が見て取れます。 Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi こんにちは、@yangcao1234さん なお、S32K1 SDK RTM 2.0.0はARM 2018.R1 Update 6向けにS32DS専用にリリースされたものであることにご注意ください。ARM 2.2用のS32DSでの使用を想定しておらず、そのバージョンとの互換性は保証されていません。 BR、VaneB
記事全体を表示
RTDアップデートの問題 - MBDT S32 Design Studioバージョン3.6.1では、RTDバージョン7.0.0をアップデートしたいのですが、5.0.0までしかアップデートできず、RTDバージョン6.0.0以降の更新を試みるとエラーが表示されます。 Screenshot 2026-08-06 143602.png Eclipse IDEの使用と設定 SDK Re: RTD update issue - MBDT Screenshot 2026-08-07 101727.png IDE 3.6.10をインストールしましたRTDバージョン7.0.1をダウンロードしようとしましたができませんでした。システムネットワークは正常に接続されており、ネットワークの問題はこのバージョンと以前のバージョン3.6.0で作業していた時のみ表示されますネットワークの問題は一切発生しませんでした。S32 IDEアプリケーションを開くと、添付されたメッセージボックスが表示されます。もしネットワーク設定の変更が同じ場合、設定で何を有効にしたり無効にしたりするのか教えてもらえますか? Screenshot 2026-08-07 095218.png Screenshot 2026-08-07 102413.png RTDがインストールされ、例のプロジェクト(DIO S32k344)で確認しようとすると上記のエラーが表示され、新しいプロジェクトを作成してもSDKのオプションが見つかりませんでした。 Screenshot 2026-08-07 102457.png Re: RTD update issue - MBDT こんにちは、 @Rathidevi さん。 まず、S32DSのインストールをバージョン3.6.10にアップデートすることをお勧めします。既存のS32DSインストールのアップデートとしてインストールできるため、別インスタンスとしてインストールする必要はありません。詳細な手順はS32 Design Studio 3.6.10で入手可能ですRFPインストールガイドは、S32DSインストーラーと同じダウンロードページで入手可能です。 RTD 7.0.1はS32DS 3.6.4を使用して開発および検証されているため、今回のアップデートを推奨します。互換性と適切な機能を確保するために、IDEのバージョンは検証に使用されるバージョンと同じかそれ以上に設定すべきです。さらに、この要件は共有イメージの「不足している要件」にも記載されています。 RTD 7.0.1のインストールに関しては、まず現在インストールされているRTDバージョンをアンインストールしてから、RTD 7.0.1をインストールすることをお勧めします。これは、異なるRTDバージョン間の潜在的な競合を回避するのに役立ちます。 BR、VaneB Re: RTD update issue - MBDT こんにちは、 @Rathidevi さん。 RTDに必要なツールチェーンがインストール環境に含まれていないようです。Arm Release バージョン10.2 ビルド1728用にNXP GCCをインストールしてください。 これにより、サンプルの問題は解決され、GCC 10.2をツールチェーンとして選択すれば、新しいプロジェクトを作成する際にRTD 7.0.1がSDKオプションとして利用可能になるはずです。
記事全体を表示
GUI Guider v2.0.0におけるUIエディタのバグに関するフィードバック GUI Guider v [お使いのバージョン番号]の使用中に、開発効率に影響を与えるいくつかのバグに遭遇しましたので、開発チームに報告したいと思います。 ドラッグアンドドロップによるレイアウトの消失:UIエディタでコントロールをドラッグしてレイアウトを調整すると、操作が時々失敗し、最新のレイアウト変更が失われ、インターフェースが以前の状態に戻ってしまいます。 重複した削除不可能なコントロール名:操作中に、同じ名前のコントロールが複数表示されることがあります。これらのコントロールは、右クリックメニューやDeleteキーでは削除できません。唯一の解決策は、ソフトウェアに再度ログインすることです。そうすれば、これらの「ゴースト」コントロールは消えます。 Re: 关于GUI Guider v2.0.0的UI编辑器Bug反馈 こんにちは、 @CN10086さん 貴重なご意見をお寄せいただき、誠にありがとうございます。 スクリーンショット、動画、再現手順などの追加情報があれば大変ありがたいです。 BR ハリー
記事全体を表示
编码器 有谁知道在哪里可以下载可在 Linux(Ubuntu)下运行的 8 位处理器 CodeWarrior 副本?一般查询显示,C/W 确实可以在 linux 下运行,但所有链接都是针对 windows 的。 Re: CodeWarror 你好 很抱歉给您带来不便,适用于 8 位处理器的 CodeWarrior 版本 [CodeWarrior v11.1] 不适用于 Linux,仅适用于 Windows。 最诚挚的问候,路易斯 Re: CodeWarror 我知道!我使用 CW 已经“很多年了”,它是在我的 Intel 架构 MAC 电脑上运行的,而 Windows 7 系统又运行在 Dropbox 系统下,Dropbox 系统又运行在 OSX 系统下。我只想在我的新ARM架构Mac电脑上做同样的事情。目前我已经安装了 Dropbox 并安装了 Windows 11。(早期版本的 Windows 与新款 MAC 不兼容)。我在Windows系统上安装了CW 11.1,它可以正常运行。 正如我在原帖中所说,CW 无法识别 Multilik 调试探针,因为没有安装设备驱动程序。请参阅我的原帖了解具体要求。
記事全体を表示
コードウォーラー Linux (Ubuntu) で動作する 8 ビット プロセッサ用の CodeWarrior のコピーをどこからダウンロードできるか知っている人はいませんか?一般的な調査の結果、C/W は Linux でも実行できることがわかりましたが、リンクはすべて Windows 用です。 Re: CodeWarror こんにちは、 ご不便をおかけして申し訳ございませんが、8 ビット プロセッサ用の CodeWarrior バージョン [CodeWarrior v11.1] は Linux のみの Windows ではご利用いただけません。 敬具、ルイス Re: CodeWarror 私はそれを知っています!私は長年CWを使用しており、Windows 7上で動作させ、そのWindows 7上でDropboxを実行し、さらにDropbox上でOSX上で動作させているという構成で、私のIntelベースのMacを使用しています。私が望んでいるのは、新しいARMベースのMACでも同じことをすることです。これまでにDropboxをインストールし、Windows 11をインストールしました。(以前のWindowsバージョンは新しいMACと互換性がありません。)WindowsにCW 11.1をインストールしましたが、正常に動作します。 元の投稿でも述べたように、CWはデバイスドライバーがインストールされていないためMultilikデバッグプローブを認識していません。必要な事項の詳細については、私の元の投稿を参照してください。
記事全体を表示
SWO 数据跟踪功能(在 MCXA156 上) 你好,恩智浦社区、 我一直在试验 MCXA156 控制器及其相应的开发板的调试功能。 我的设置 (FRDM-MCXA156) 以及定制板中的 MCXA156。 MCUXpresso IDE v25.6 [内部版本 136] [2025-06-27] MCU Link pro 调试器 到目前为止,通过恩智浦 Expresso SDK 中的各种示例,我能够满足大部分调试需求。(断点、数据监视点、ITM 打印重定向、中断跟踪等)。 不知何故,我只能在 SWO 上使用 Data Watch Trace/Stream。我想我误解了 MXCA156 调试功能的功能。 据我所知,MCXA156 支持 ITM 和 DWT。 有了它,就可以添加读/写数据编译器,并通过 SWO 引脚流出/跟踪相应的数据。在我的设置中,我似乎无法使用"SWO Data" 窗口,即使所有其他跟踪功能似乎都能正常工作。 我的设置是否正确,还是 MCUXpresso IDE 还不支持我的使用情况? 顺祝商祺! 亚历克斯 Re: SWO Data Trace functionallity (on MCXA156) 你好@AlexRu 要使用 SWO,您可以按照提供的步骤指南进行操作。 硬件要求: 确保芯片的 SWO 引脚连接到调试器的 SWO 接口。 (这是 FRDM-MCXN947 板)。 Alice_Yang_0-1764234995466.png 软件配置: 创建新项目时,选择 "重定向 printf/scanf 至 ITM",将 printf/scanf 输出重定向至 ITM。 Alice_Yang_1-1764235038209.png 2.配置跟踪时钟: Alice_Yang_2-1764235054451.png CLOCK_AttachClk(kTRACE_DIV_to_TRACE); /*!将 TRACE 切换到 TRACE_DIV */ /*!安装分频器 */ clock_setclkdiv (kclock_divtraceCLK,3U); /*!将 TRACECLKDIV 分频器设置为值 3 */ 3.在 MCUXpresso IDE 中配置 ITM 控制台视图: 打开 SWO ITM 控制台。 在 IDE 设置和代码中配置相应的核心时钟和跟踪时钟 。 Alice_Yang_4-1764235140283.png Alice_Yang_5-1764235162015.png Alice_Yang_6-1764235196129.png Alice_Yang_7-1764235214710.png Alice_Yang_8-1764235219324.png 4.查看输出结果。 Alice_Yang_9-1764235228270.png 有关 SWO 和 DWT 使用的详细信息,请参阅MCUXpresso_IDE_25.06_Instruction_Trace_Guide.pdf 。您可以在 MCUXpresso IDE 安装路径下找到该指南。 BR 爱丽丝   Re: SWO Data Trace functionallity (on MCXA156) 嗨,爱丽丝、 非常感谢你对如何设置 SWO 跟踪的详细可视化说明。 就我而言,我已经验证了 SWO 引脚(MXCA-156 PCB)与我的 MCU-Link Pro 调试探针的电连接。您提到的 PDF 文件确实提供了更详细的信息,扩展了我的知识面。尽管如此,这并不能真正解释/反驳我对使用 DWT 的假设。 在我的设置中,我已经在"SWO Interrupts" 窗口中看到了中断返回和中断入口点的数据:(这是我的 SW 的实时数据!有意义的数据和正确的时间信息)。 AlexRu_0-1764332623019.png 有了这些信息,我验证了我通过SWO引脚的电连接是否正常,跟踪时钟已启用,频率符合我的SWO Trace Config中的预期。 我错过了什么(或者我这边可能有误会?)是通过数据观察比较器 (DWT) 将数据追踪到窗口 " SWO Data " 中的 SWO 跟踪引脚的功能。 在启用"play" 按钮后,我没有收到任何跟踪信息: AlexRu_1-1764333027216.png 我甚至证实,在我的 MXCA156 配置中,数据监视点仅限于 2 个比较器,因此 IDE 似乎能够设置它们并警告设置的数据观察点过多(我故意这样做是为了检查其合理性): AlexRu_2-1764333135738.png 所以我的问题是是集成开发环境支持这种调试方法,还是我理解错了,DWT 完全不提供这种数据跟踪功能? Re: SWO Data Trace functionallity (on MCXA156) 你好@AlexRu 感谢您的回复。 请告诉我您想使用 DWT 观察哪些数据? 另外,请共享一个可以重现该问题的项目,并提供一段视频,展示您所采取的所有步骤。 我将利用这些信息来重现和检查我这边的问题。 谢谢! BR 爱丽丝 Re: SWO Data Trace functionallity (on MCXA156) 你好@Alice_Yang、 我确实根据 SDK 示例(LED Blinky)为 FRDM-MCXN236 演示板准备了一个极简主义项目。(demo_apps -> LED_BLINKY_PERIPHERAL) MCXN236 板设置显示的效果似乎与我之前使用的 MCXA156 板相同。我只是想在另一个板确认这种行为。 引脚配置设置 P0_2 -> 输出 SWO(本例中为默认值) 启用 TRACECLK 和 TRACECLKDIV (1),因为本例使用 BOARD_BootClockFRO12M() 添加了以下代码,以查看 glocal ram 变量的一些操作: volatile uint32_t debug_cnt = 0; void SysTick_Handler(void) { /* Toggle pin connected to LED */ GPIO_PortToggle(BOARD_LED_GPIO, 1u << BOARD_LED_GPIO_PIN); debug_cnt++; //<- added for demonstration purpose } 附件:包含演示项目和调试视频的压缩包。 您可以看到"SWO Data" 没有显示任何跟踪数据。全局变量窗口显示在 ~1 秒的 SysTick_Handler 周期内 debug_cnt 的增量。" SWO Interrupts " 还能可靠地显示 systick_Handler () 的进入和退出,因此 SWO 跟踪的电连接似乎可以正常工作。 如果我能提供更多信息以缩小问题范围,请告诉我。 如果您能确认我所期望的用 DWT 追踪全局/静态 RAM 变量是否可行,我也将非常高兴。或者是我理解错了。 Re: SWO Data Trace functionallity (on MCXA156) 你好@AlexRu 我在自己这边做了测试。这无法实时输出变量的值。它只能在暂停调试时检查变量的值。 Alice_Yang_0-1765449677747.png BR 爱丽丝 Re: SWO Data Trace functionallity (on MCXA156) 嗨,爱丽丝,谢谢你的努力。这样看来,MCUXpresso 目前不支持"数据跟踪" 调试。可以在将来的版本中申请这个吗? 从我这个局外人的角度来看,似乎并不缺少使其发挥作用的因素。SWO 中断似乎可以正常工作,并可扩展到高级调试功能。 SWO 数据跟踪可进一步扩展恩智浦 Xpresso 工具链中的调试功能。 问候 Alex Re: SWO Data Trace functionallity (on MCXA156) 你好@AlexRu 谢谢您的答复。我会将此请求转发给 MCUXpresso 开发团队,并随时向您通报最新进展。谢谢。   BR 爱丽丝 Re: SWO Data Trace functionallity (on MCXA156) 你好@Alice_Yang @AlexRu 我目前正在使用FRDM-MCXA156开发板,在调试过程中遇到了SWO(串行线输出)问题。 虽然应用程序调试成功,但我无法在SWO 跟踪窗口中接收任何数据,包括: SWO 数据 SWO概况 SWO中断跟踪 ITM控制台 为了排查问题,我已经核实了以下内容: 使用配置工具已正确配置SWO 引脚。 TRACE 时钟已启用并配置为96 MHz ,与 MCU 内核时钟匹配(MCXA156 运行频率为 96 MHz)。 该项目正在使用LinkServer和板载MCU-Link探针进行调试。 尽管进行了这些配置,但在调试过程中所有 SWO 跟踪窗口仍然为空。 为了方便参考,我附上了SWO 跟踪配置、 SWO 数据、 SWO 配置文件和SWO 中断跟踪窗口的截图。 对于可能导致此问题的原因,或者在FRDM-MCXA156上启用 SWO 跟踪是否需要任何额外的配置步骤,我非常感谢您能提供任何指导或建议。 感谢您抽出时间提供帮助。
記事全体を表示
RTD 更新问题 - MBDT 在 S32 设计工作室 3.6.1 版本中,我想将 RTD 版本更新到 7.0.0,但我只能更新到 5.0.0,当我尝试更新到 RTD 版本 6.0.0 及更高版本时,出现错误。 Screenshot 2026-08-06 143602.png Eclipse IDE 使用和设置 SDK Re: RTD update issue - MBDT Screenshot 2026-08-07 101727.png 我已经安装了IDE 3.6.10。我尝试下载 rtd 7.0.1 版本,但失败了。系统网络连接正常,只有在这个版本上以及我之前使用 3.6.0 版本时才会出现网络问题。我没有遇到任何网络问题。每当我打开 S32 IDE 应用程序时,都会弹出附件中的消息框。如果这是更改网络偏好设置导致的问题,您能告诉我需要在设置中启用和禁用哪些选项吗? Screenshot 2026-08-07 095218.png Screenshot 2026-08-07 102413.png RTD 安装完成后,当我尝试使用示例项目 (DIO S32k344) 进行检查时,出现附件中的上述错误。在创建新项目时,我找不到任何 SDK 选项。 Screenshot 2026-08-07 102457.png Re: RTD update issue - MBDT 嗨@Rathidevi 首先,我们建议您将 S32DS 版本更新到 3.6.10。无需将其作为单独的实例安装,因为它可以作为现有 S32DS 安装的更新进行安装。详细说明请参见 S32 设计工作室 3.6.10 版本。RFP 安装指南,可在与 S32DS 安装程序相同的下载页面上找到。 推荐此更新是因为RTD 7.0.1是基于S32DS 3.6.4开发和验证的。为了确保兼容性和正常功能,IDE 版本应与用于验证的版本相同或更新。此外,共享镜像的“缺失要求”中也提到了这一要求。 关于 RTD 7.0.1 的安装,我们建议先卸载当前已安装的 RTD 版本,然后再安装 RTD 7.0.1。这有助于避免不同RTD版本之间可能存在的冲突。 BR,VaneB Re: RTD update issue - MBDT 嗨@Rathidevi 您的安装似乎缺少RTD所需的工具链。请安装 NXP GCC for Arm Release 版本 10.2 build 1728。 这样应该可以解决示例中的问题,并且只要选择 GCC 10.2 作为项目的工具链,就可以在创建新项目时将 RTD 7.0.1 作为 SDK 选项使用。
記事全体を表示
i.MX95 Neutron NPU用にYOLOv8/YOLO11 TFLiteモデルをコンパイルできません こんにちは、NXPサポートチームの皆さん、 私たちはNeutron SDK v3.1.3を用いてFRDM i.MX95プラットフォーム上の物体検出を評価していますまた、NPU互換モデルを生成できません。Neutronコンバータはモデルを正常にロードしますが、 Neutron NPUに割り当てられたオペレーターは0個と報告します。 環境 対象ボード:FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: YOLO11とYOLOv8の両方でテスト済み eIQツールキット:ONNXからTFLiteへの変換に使用 モデル:カスタムの単一クラスペグ検出器 トレーニング司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=モデル \ name=peg_detector_v8 エクスポートコマンド $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml また、別のワークフローもテストしました。 PyTorchをエクスポート → ONNX NXP eIQツールキットを使用してONNXをINT8 TFLiteに変換する Neutron SDKでコンパイルした場合、両方のワークフローは同じ結果を生み出しました。   Neutron コンパイル ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   コンバータ出力 コンバーターは次のように報告しています: インポート後のオペレーター数:341 最適化後の演算子数:367 変換された演算子: 0 オペレーター変換率:0 / 367 Number of Neutron graphs: 0 警告: 警告:グラフの演算子はニュートロンにマッピングされていません。 警告:変換されたモデルは入力モデルと同じで、演算子が中性子にマッピングされていないためです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています!これによりコンバージョン率が低くなることがあります。 その他の情報 以下のケースでも同様の挙動が観察されました。 YOLO11 YOLOv8 ダイレクトUltralytics TFLiteエクスポート ONNX → eIQ ツールキット → INT8 TFLite 生成されたすべてのTFLiteモデルは、Neutronコンパイラによって 0演算子をマッピング します。 質問 YOLOv8またはYOLO11のオブジェクト検出モデルは、i.MX95用のNeutronコンパイラで公式にサポートされているのでしょうか? i.MX95 NPUをターゲットにしたYOLOモデル向けの推奨エクスポートパイプラインはありますか? 現在のNeutron SDK(v3.1.3)には既知の制限はありますか?YOLO検出ヘッドに関してですか? NXPはi.MX95 NPU向けに正常にコンパイルできるリファレンスYOLOv8/YOLO11モデルを提供していますか? 演算子マッピングを有効にするために、追加のコンパイラオプションや前処理手順が必要ですか? i.MX95 Neutron NPUで動作することが知られているガイダンス、推奨ワークフロー、または参照モデルがあればぜひ教えていただけるとありがたいです。 よろしくお願いします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU そして、あなたの人生を本当に大切にしてください。 もし本当に 、私がこのゲームを望むなら、私はこのゲームを L に x x 95 でイノシシd. 私たちは今、AR A2 を手に入れたので、そのキャパビリのつながりと 、あなたたちの兄弟の絆を活用します。 私たちはNXで実際にデモを作ったことがあるし、あなたはこのマットで最初に知られるだろうと、もっと早くアプリに報告されるだろう. あなたの LPに感謝します。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Model zooのyolo8mモデルをimx95ボードで試し、LF 2026年Q2リリースイメージを使いました。カーネルバージョンはNeutron SDK 3.1.2を使用して6.18.2です。うまくいく。 xing_lei_0-1783672312304 (1).png     まずは以下から試してみることもできます: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-Smart.imx95.tflite --external_delegate_path=/USR/LIB/libneutron_delegate.so 詳細はREADMEのeiq-model-zoo/tasks/ビジョン/object-detection/yolov8を参照してください。NXP/eiq-model-zoo さらに、モデルやコンプリエーションの詳細なログを添付することもできます。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU コンバーターログに基づくと、最初に解決すべき問題は、生成されたTFLiteモデルに依然としてFLOAT演算子が含まれていることです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! i.MX95 Neutronの場合、ニュートロンコンバータへの入力は、演算子と量子化フォーマットがNeutronコンパイラと互換性のあるTFLiteモデルでなければなりません。特に、i.MX95中性子流は量子化されたTFLiteと対称int8重みを期待しています。UltralyticsエクスポートやONNXからTFLiteへの変換後もモデルにFLOAT演算子/テンソルが残っている場合、コンバーターは報告された結果と整合するNeutron互換の部分グラフを作成できない可能性があります。 変換された演算子: 0 中性子グラフの数:0 YOLOv8はi.MX95上で一部のフローにおいて評価されていますが、任意のUltralyticsエクスポートにおいて、エンドツーエンドのYOLOv8/YOLO11オフロードが完全に実現されるとは限りません。エクスポートされたTFLiteグラフによっては、モデルの一部のみがNeutronGraphに変換され、サポートされていない演算子はCPU上に残ります。したがって、次の推奨ステップは生成されたTFLiteモデルを検査・プロファイリングし、以下のことを確認することです: グラフは完全に量子化されており、 FLOAT演算子はありません。 重みは対称な int8、 入出力テンソルタイプは互換性があり、該当する場合はNeutron変換器のuint8からint8への変換オプションで変換されます。 デコードやNMSなどのYOLO後処理は、SDKで正確な演算子がサポートされていることが確認されない限り、NPUグラフの外に保管されます。 また、Neutron-Converter版とボード上のNeutronランタイム/ファームウェア/デリゲートが同じ互換性のあるSDK/BSPリリースから来ていることも確認してください。 推奨される手順として、NXP/eIQ変換パスをお試しください。 PyTorch -> 静的入力形状のONNX -> 代表的な較正データを用いたNXP/eIQ量子化 ->量子化されたTFLite -> Neutron-converter --ターゲットIMX95 モデルにuint8の入力/出力テンソルがある場合は、以下もテストしてください: --入力値をuint8からint8に変換 --出力をuint8からint8に変換 FLOAT演算子を削除した後も変換結果にマッピングされた演算子が0と表示される場合は、以下の情報を共有してください。 - 詳細/プロファイリング出力を含む完全な中性子変換ログ - TFLiteオペレーターリスト、 - テンソルデータ型と量子化パラメータ、 - FRDM i.MX95ボード上のBSP/実行時Neutronデリゲート/ファームウェアバージョンの正確なバージョン、 - YOLO検出ヘッドにNMSやその他の後処理が含まれているかどうか。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 私のテストでは、 自分でトレーニングもエクスポートもしていません。eIQ Model Zooのプリ生成されたYOLOv8モデルを使い、i.MX95プラットフォームで動作することを確認しました。 私が実際に使用したコマンドはこれだけです。 ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 モデルでは: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite カスタムモデルの場合、推奨されるNXPフローは以下の通りです: PyTorch ↓ ONNX(静的入力形状) ↓ eIQツールキット ONNX2Quant ↓ eIQツールキット ONNX2TFLite ↓ 量子化されたTFLite ↓ Neutron-converter --ターゲットIMX95 あなたのモデルが報告しているので: プレーンテキスト 変換された演算子: 0 Number of Neutron graphs: 0 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! あなたの生成されたTFLiteグラフは、eIQ Model Zooの参照モデルとは構造的に異なるのではないかと推測しています。まず最初におすすめしたいのは、以下の2つのモデルを比較することです: 入力/出力テンソル型(INT8 vs UINT8) FLOAT演算子の存在 グラフ内のデコード/NMSレイヤー Netron / TFLiteアナライザーによって報告されたオペレーターリスト Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推奨されるエンドツーエンドのワークフロー モデルトレーニング(PC) お好みのフレームワークを使用してトレーニングしてください。 ウルトラリティクス YOLOv8 PyTorch テンソルフロー ONNXネイティブワークフロー 物体検出に関しては、NXPはすでにeIQモデルズーでYOLO参照レシピを提供しており、YOLOv8オブジェクト検出モデルも含まれています。[github.com] 、[github.com] 例: シェル YOLO検出トレーニング model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ エポック数=100 ` ONNX形式でエクスポート NXPは一般的に、量子化および展開の前に、交換フォーマットとしてONNXを使用することを推奨しています。 YOLOエクスポート model=best.pt \ フォーマット=onnx Neutron イネーブルメントのプレゼンテーションは、以下に基づくフローを明示的に記述しています: プレーンテキスト PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ Neutron コンバータ 訓練アーティファクトから直接展開を狙うのではなく、 eIQツールキットを使用した量子化 Neutronのワークフロードキュメントでは、eIQ Toolkitの量子化ユーティリティの使用を推奨しています: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: 「 に続く: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite もっと行を表示 この流れはi.MX95 Neutron イネーブルメント材料に明示的に記録されています。 i.MX95 Neutron NPU用にコンパイル Neutron-converter \ --ターゲット imx95 \ --input model_int8.tflite \ --出力 model_neutron.tflite ニュートロンコンバーターは、NPUにオフロードできるNeutron特有のグラフパーティションを作成します。 コンバージョン率の検証 NPUのデプロイが成功すると、以下のようなレポートが表示されます。 変換されたオペレーターの数 > 0 Number of Neutron graphs > 0 次のような場合: 変換された演算子: 0 Number of Neutron graphs: 0 この場合、モデルはNPUによって加速されていません。 あなたの抱えている問題は、このカテゴリーに該当します。 FRDM-i.MX95に展開する TensorFlow LiteでNeutronデリゲートを使い実行します: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 または ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX Machine Learning User Guideでは、 Neutron Delegate がi.MX95 TensorFlow Liteモデルの加速機構として特定されています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU yolov8m_full_integer_quant.tfliteをどのように変換してIMX95のNPUで動作させたのか教えてもらえますか? 手順に従って環境設定データ(HOST)を経て...私たちにとって大いに助けになるでしょう。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは 私はUbuntu 24.04を使用していますが、eiq_toolkitは20.04.03でのみ利用可能です。 eiqToolkitとeIQ Toolkitを使った量子化の使い方 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ ToolkitはUbuntu 20.04で検証済みであるため、最も安全な方法は以下のとおりです。 Docker Ubuntu 24.04ホスト上でUbuntu 20.04コンテナを実行します。 docker run -it --name eiq \ ubuntu:20.04 /bin/bash 次に、コンテナ内に必要な依存関係とeIQ Toolkitをインストールします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Toolkit(onnx2quant)を使ってカスタムYOLOv8 ONNXモデルを変換する際に信頼度を維持できない 概要 こんにちは、NXPチームの皆さん、 私はfdm i.MX95上でeIQ Toolkitを使ってカスタムYOLOv8単一クラスオブジェクト検出モデルを展開しようとしています。 変換パイプライン全体は正常に実行されますが、onnx2quant の後、信頼度出力がすべてゼロになり、バウンディングボックス出力は有効なままです。 環境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX ランタイム 1.21.1 - テンソルフロー 2.21 - Neutron-コンバータ 3.1.3 - ターゲット:FRDM i.MX95(tflite_runtime 2.19+Neutronデリゲート) 変換パイプライン 1. 列車 Yolo Detect Train Model=yolov8N.pt data=dataset.yaml imgsz=640 epochs=50 2. ONNXのエクスポート Yolo export model=best.pt format=onnx opset=13 3. ONNXの検証 入力:(1,3,640,640) 出力:(1,5,8400) ONNXランタイム推論: 信頼チャネル最大値 = 0.773 4. キャリブレーションデータセットの生成 形状:(1,3,640,640) dtype : float32 範囲:0.0 - 1.0 5. 量子化 onnx2quant best.onnx -c "images;キャリブレーション/画像」 -o best_quant.onnx また、以下の項目もテストしました。 onnx2quant best.onnx -u どちらも同じ結果を生み出す。 6. 量子化されたONNXの検証 出力:(1,5,8400) バウンディングボックスチャネルは有効のままです。 自信: 最小値 = 0 最大値 = 0 平均 = 0 デコードされた検出数 = 0 7. TFLite形式に変換する onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron Neutron-converter --ターゲット IMX95 --入力 best.tflite --出力 best_neutron.tflite コンパイルに成功しました。 オペレーター変換率:278 / 325 (85.5%) 調査実施 検証済み: • PyTorchモデルの動作 • ONNX輸出作品 • ONNXランタイム推論の動作 • キャリブレーションデータセットは正確です • 実数およびランダムキャリブレーションで同一の結果が得られます • TFLiteは量子化されたONNX出力を再現します • NeutronはTFLite出力を再現します この問題は以下以下に初めて現れます: ONNX ↓ onnx2quant ↓ 量子化されたONNX(信頼度がゼロになる) 追加の観察 NXPの参照モデル: 入力:(1,640,640,3) INT8 出力:(1,84,8400)INT8 私の改造モデル: 入力:(1,3,640,640) FLOAT32 出力:(1,5,8400) FLOAT32 カスタムYOLOv8モデルの信頼度を保つ推奨されるエクスポートや量子化のワークフローはありますか? これは、(1,5,8400)出力を持つモデルのonnx2quantの制限やバグでしょうか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU AEチームと話し合っています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240のエンドツーエンド評価は実施されましたか?データシートには、シグモイドやNMSなどの後処理操作を実行できる2つのベクターコアが記載されています。コンパイラはNMSの操作をベクターコアにマッピングできますか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU YOLOv8の出力テンソルに適用される完全なINT8量子化( inference_output_type=tf.int8 )の根本的な制限により、信頼度出力が失われます。 YOLOv8 は、境界ボックスの座標と信頼度スコアを (1, 5, 8400) の形状の単一の出力テンソルにパックします。bboxの値は広いダイナミックレンジ(約640ピクセル)を持ち、信頼度スコアは約0から1の範囲にあります。出力テンソル全体が単一の量子化スケールを共有する場合、そのスケールは大きなbbox値(約640)によって支配され、信頼区間全体(約1)を表すために1つの整数レベルのごく一部しか残されません。その結果、INT8量子化後、すべての信頼度値は実質的にゼロに丸められます。 推奨される解決策   onnx2quant を通す代わりに、Ultralyticsを使って訓練した  .pt  モデルからINT8 TFLiteを直接エクスポートし、それを  neutron-converter に入力します: # INT8 TFLite 直接エクスポート(キャリブレーションはトレーニングデータセットを使用) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # ニュートロン 用 にコンパイル(変更なし) ニュートロンコンバーター --target imx95 --input best_int8.tflite --output best_neutron.tflite 入力および出力データの型は、np.int8であることを確認してください。 interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale、inp_zp = inp_d[ "quantization" ] out_d = out_ds[0] out_scale、out_zp = out_d[ "quantization" ] print(f " 入力 dtype={inp_d['dtype']} shape={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 出力 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 形状から入力フォーマットを決定します in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] または [1,640,640,3] in_shape[1] == 3 の場合: #NCHW src=img_nchw それ以外: #NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ "インデックス" ],src_int8) それ以外: interp.set_tensor(inp_d[ "インデックス" ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# int8 または float32 の可能性があります if out_d[ "dtype" ] == np.int8: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale それ以外: dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 正規化 # 表示用にバウンディングボックスをピクセル座標に再スケーリング BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 遅れてごめんなさい。変換ワークフローを再現しようとしています。 今のところ一つ質問ですが、なぜ変換されたモデルのデータ型がFLOAT32なのか?INT8形式への変換を試してみましたか?ニュートロンNPUはINT8型を入力データとして必要とします。他のモデルの変換でも似たエラーに遭遇しましたが、根本原因はデータ型にあります。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは、あなたが共有してくれたコマンドを試しました... しかしNeutron変換器はモデルの変換に失敗している... 参照用に添付のログをご覧ください Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU ログを提供してください。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは、 添付のログファイルをご確認ください。 モデルのトレーニングは成功し、i.MX95のNPUで動作させることができました。しかし、量子化パラメータに関して、ある点に気づきました。 量: (0.003921568859368563, -128) 負の量子化零点値が気になったのですが、これは想定される動作なのでしょうか? ご参考までに、添付のログファイルをご確認ください。 よろしくお願いします。
記事全体を表示
Guiguiderライセンスのコンプライアンスに関する懸念 親愛なるNXPセミコンダクターズへ、 私は、あなたのGuiderソフトウェアのライセンス契約違反の可能性を報告するために書いています。 理解している限り、あなたのGuiderソフトウェアのライセンスは、NXPシリーズ以外のチップをベースにした製品開発における商業利用を明確に禁止しています。しかし、現在、大手多国籍企業がこのソフトウェアをRockchipシリーズのメインコントロールチップをベースにした商用製品の開発に使用しており、これはあなたのライセンス条項に明らかな違反と思われます。 お聞きしたいのですが、NXPはこの件に関して知的財産権を保護するために何らかの執行措置を講じる予定はありますか?また、この違反に関して正式な苦情を申し立てる場合、調査を開始するために具体的にどのような証拠が必要となりますか? ご回答をお待ちしております。 回复: Concern about Guiguider License Compliance Guiguiderはライセンスに違反して使用されています。 貴社のGuiderソフトウェアのライセンスでは、NXPシリーズ以外のチップの商用開発における使用を明確に禁止しています。ある大手多国籍企業が、Rockchip社のメイン制御チップを使用した商用製品にこのソフトウェアを適用することで、このライセンスに違反しました。貴社は法的措置を取る予定ですか?苦情を申し立てる場合、どのような証拠を提出すればよいでしょうか? Re: Concern about Guiguider License Compliance この件をご指摘いただきありがとうございます。 GUI Guiderは、その許可された使用を規定するライセンス条件のもとで提供されており、サポートするハードウェアプラットフォームに関する制限も含まれています。NXPは、ソフトウェアツールのユーザーが適用されるライセンス条件を遵守することを期待しています。 投稿で言及された具体的な状況については把握していないため、特定の会社、製品、または主張される活動についてコメントすることはできません。GUIガイドの悪用の可能性に関する具体的な情報がある場合は、コミュニティ投稿ではなく適切なNXPの直接チャネルを通じて追加情報を提供し、情報の確認に応じてください。役立つ情報の例としては、関係する組織の身元、製品やプロジェクトの詳細、その他の補足情報が挙げられます。 NXP製品やソフトウェアツールへのご関心に感謝いたします。
記事全体を表示
RT1171CVM8BでのモバイルSDRAM(1V8)サポート 私たちは新製品に使われるRT1171CVM8Bを調査しています。 このRTファミリーのメンバー i.MX モバイル(低消費電力、1.8V)SDRAMに対応していますか? データシート、リファレンスマニュアル、利用可能なアプリケーションノートや回路図からは、それがすぐには明確ではありません。これは1V8および3V3の両方で指定されているポートドライバ(NVCC_EMC1,2)によって推論されます。また、RT1060およびRT1050 i.MX の類似の質問や回答から肯定の推論も得られます。 EMCやSDRAMインターフェースの特殊な部分が1V8の部品で故障するようなトラブルは避けたいです。 そうでなければ、なぜデータシートに明確に記載されていないのでしょうか!? 敬具 ジョージ・ツァナトス。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B @georgetzanatos様、 RT1171はモバイルSDRAM(低消費電力1.8V SDRAM)をサポートしています。 現在のドキュメントにはこれを明確に記載していないことには同意します。データシートおよびリファレンスマニュアルでは、メモリプロトコルのサポートとI/O電圧モードが別々に説明されており、単一の「モバイルSDRAMサポート」文にまとめられているわけではありません。 ご心配は理解できます。RT1171のモバイル SDRAMを使っても構いません。重要な要件は、関連するNVCC_EMC1/2電源ドメインを1.8V動作用に設定し、SDRAMのI/O電圧レベルに合わせることです。   よろしくお願いいたします。 シェリー
記事全体を表示
IMX8 ISP 仅在 ROI 上运行 你好。 我们的 IMX8 产品在 ISP 服务方面遇到了一些问题。 我们应该能够让 ISP 仅在 MIPI 提供的图像达到确定的投资回报率时才工作。 事实上,现在我们只能对来自 ISP 的整个图像使用 ISP。 例如,在我们的例子中,我们有一个大小为 1120x1376 的图像,但最后 16 行是嵌入数据,我们无法将其发送到另一个 VC 中。ISP 应该处理图像(1120x1360),而不是处理嵌入的数据(这些数据始终位于图像底部)。 这样做可行吗? 提前致谢! 祝你今天过得愉快。 Federico Rachelli,Datalogic得利捷有限公司 Re: IMX8 ISP operating only on ROI 你好@federico_rachelli 希望你一切都好。 我们没有这方面的例子,但这让我觉得你可以在驾驶员层面做到这一点。 例如,ACQ 模块使用bounds_width和bounds_height参数来了解原始 MIPI 有效载荷尺寸,然后使用top 、 left 、 width和height来提取有效的感兴趣区域 (ROI)。 你可以在 i.MX 8M Plus相机与显示器指南中看到这些信息。 要丢弃 1120x1376 图像框底部的 16 行嵌入数据,您需要设置 .size 属性。传感器ISP驱动程序配置中的属性: .size = { .bounds_width = 1120, .bounds_height = 1376, /* Total MIPI payload including embedded data */ .top = 0, .left = 0, .width = 1120, .height = 1360, /* Effective image height (1376 - 16) */ }, 请参阅第 4.1.2 节。上述文档中驱动程序的传感器尺寸配置。 顺祝商祺! 萨拉斯。
記事全体を表示
重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 过去,我的项目使用了 S32DS V2.2 和 SDK RTM 2.0.0。现在,重新安装后,我使用的是 S32DS.ARM.2018.R1,并且也安装了 SDK RTM 2.0.0。但我现在无法编译这个项目。它似乎无法识别该项目本身。图片中可以看到细节。 Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi 你好@yangcao1234 请注意,S32K1 SDK RTM 2.0.0 是专门为 S32DS for ARM 2018.R1 Update 6 发布的。它并非设计用于 ARM 2.2 的 S32DS,并且不能保证与该版本兼容。 BR,VaneB
記事全体を表示
IMX8 ISPはROIでのみ動作します こんにちは。 IMX8製品のISPサービスに関していくつかの問題に直面しています。 MIPIから送られてくる画像のうち、特定のROI(関心領域)のみを対象にISPを動作させるようにすべきである。 実際、今ではISPからの画像全体に対してしかISPを使えません。 例として、私たちの場合、サイズは1120x1376の画像ですが、最後の16行は埋め込みデータで、他のVCに送信できません。ISPは、画像(1120x1360)自体に対して処理を行うべきであり、画像下部に常に存在する埋め込みデータに対して処理を行うべきではない。 これは可能でしょうか? 前もって感謝します! 良い1日を。 Federico Rachelli、Datalogic S.r.l. Re: IMX8 ISP operating only on ROI こんにちは、 @federico_rachelli さん。 お元気でお過ごしのことと思います。 例はありませんが、ドライバーレベルではできるのではないかと思います。 例えば、ACQモジュールはbounds_widthとbounds_heightパラメータを使用して生のMIPIペイロードの寸法を理解し、その後top 、 left 、 width 、 heightを使用して有効な関心領域(ROI)を抽出します。 その情報は i.MX 8M Plusカメラ&ディスプレイガイドでご覧いただけます。 1120x1376 フレームの下部にある 16 行の埋め込みデータを破棄するには、.size を設定する必要があります。センサーのISPドライバ設定における性質: .size = { .bounds_width = 1120, .bounds_height = 1376, /* Total MIPI payload including embedded data */ .top = 0, .left = 0, .width = 1120, .height = 1360, /* Effective image height (1376 - 16) */ }, 第4.1.2章をご覧ください。上記のドキュメントのドライバにおけるセンササイズ設定。 よろしくお願いいたします。 サラス。
記事全体を表示
imx95lpddr5 evk の全負荷状態をシミュレートするために i.MX95 LPDDR5 EVKボード上で、フルロード動作状態をシミュレートする方法。画像や事前コンパイルされたアプリケーションはありますか?私はLinuxのマルチメディアイメージを使っています。 Re: To simulate full load condition on the imx95lpddr5 evk こんにちは、 参考として、以下のアプリケーションノートをご利用ください: https://www.nxp.com/docs/en/application-note/AN14449.pdf 高負荷CPUテストを達成するためのユースケースはいくつかあります。 ぜひご覧になってみてください。 CA55 コアマーク eIQベンチマーク(GPU) eIQベンチマーク(NPU) よろしくお願いいたします。 
記事全体を表示
RT1171CVM8B 支持移动 同步动态随机存取存储器(SDRAM) (1V8) 我们正在研究将 RT1171CVM8B 用于新产品。 这款 i.MX RT 系列产品是否支持移动(低功耗,1.8V)同步动态随机存取存储器(SDRAM)? 从数据手册、参考手册和可用的应用笔记和原理图中并不能立即看出这一点;这是因为端口驱动程序同时指定了 1V8 和 3V3 (NVCC_EMC1,2)。从 i.MX RT1060 和 RT1050 的类似问答中也可以得出肯定的结论。 我希望避免出现因 EMC 或 同步动态随机存取存储器(SDRAM) 接口的某些隐蔽部分与 1V8 器件不兼容而导致的故障;否则,为什么数据手册中没有明确列出呢!? 此致敬礼, 乔治·扎纳托斯。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B 亲爱的@georgetsanatos , RT1171 支持移动 SDRAM(低功耗 1.8 V SDRAM)。 我们同意,目前的文档没有明确说明这一点。在数据手册和参考手册中,内存协议支持和 I/O 电压模式是分别描述的,而不是合并到一个单独的“移动同步动态随机存取存储器\(SDRAM\) 支持”声明中。 我理解您的担忧。请放心在RT1171上使用移动同步动态随机存取存储器(SDRAM)。关键要求是配置相关的 NVCC_EMC1/2 功率域,使其在 1.8V 电压下运行,以匹配 SDRAM I/O 电压等级。   顺祝商祺! 雪莉
記事全体を表示
GUI Builder 2.0 image generation code bug lqdjdy_0-1785631623960.png lqdjdy_1-1785631779772.png lqdjdy_2-1785631867575.png The generated macro name includes spaces. Re: GUI Builder 2.0生成图片代码bug Hello @lqdjdy , Thanks for your post. Would renaming the image from "face-id" to "face_id" solve the problem? BR Celeste Re: GUI Builder 2.0生成图片代码bug Yes, image names cannot contain hyphens. Re: GUI Builder 2.0生成图片代码bug Thank you for your confirmation. I will suggest to the SW team that an error message be displayed when the image name contains abnormal characters.
記事全体を表示
关于GUI Guider v2.0.0的UI编辑器Bug反馈 我在使用GUI Guider v[你的版本号]时,遇到了几个影响开发效率的Bug,想向开发团队反馈一下: 拖动布局导致布局丢失:当我在UI编辑器中拖动控件进行布局调整时,操作偶尔会失败,并且最新的布局改动会丢失,界面回退到之前的状态。 控件名称重复且无法删除:在操作过程中,有时会出现多个控件名称一致的情况,并且这些控件无法通过右键菜单或Delete键删除。唯一能解决的办法是重新登录软件,这些“幽灵”控件才会消失。 Re: 关于GUI Guider v2.0.0的UI编辑器Bug反馈 您好@CN10086 非常感谢您分享这些反馈意见。 如果您能提供更多详细信息,例如屏幕截图、视频或重现步骤,我们将不胜感激。 BR 哈里
記事全体を表示
无法为 i.MX95 Neutron NPU 编译 YOLOv8/YOLO11 TFLite 模型 您好,NXP支持团队, 我们正在使用Neutron SDK v3.1.3在FRDM i.MX95平台上评估目标检测功能。并且无法生成与 NPU 兼容的模型。Neutron 变流器成功加载了模型,但报告称0 个算子映射到 Neutron NPU 。 环境 目标板:FRDM i.MX95 Neutron SDK:3.1.3 Ultralytics:已使用 YOLO11 和 YOLOv8 进行测试 eIQ 工具包:用于 ONNX 到 TFLite 的转换 型号:定制单类钉子检测器 训练司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 导出命令 $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml 我们还测试了另一种工作流程: 导出 PyTorch → ONNX 使用 NXP eIQ 工具包将 ONNX 转换为 INT8 TFLite 使用 Neutron SDK 编译时,两种工作流程都产生了相同的结果。   中子汇编 〜/下载/eiq-neutron-sdk-linux-3.1.3/bin/neutron-变流器--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   变流器输出 变流器报告: 导入后运算符:341 优化后的运算符数:367 已转换运算符:0 操作员转换率:0 / 367 中子图数量:0 警告: 警告:图中所有运算符均未映射到 Neutron。 警告:转换后的模型与输入模型相同,因为没有将任何算符映射到 Neutron。 警告:图表中包含不支持的 FLOAT 运算符!这会导致转化率低。 更多信息 我们观察到以下情况也存在同样的现象: YOLO11 YOLOv8 直接 Ultralytics TFLite 导出 ONNX → eIQ 工具包 → INT8 TFLite 所有生成的 TFLite 模型都导致 Neutron 编译器映射 0 个算符。 问题 Neutron 编译器是否正式支持 i.MX95 的 YOLOv8 或 YOLO11 目标检测模型? 对于目标平台为 i.MX95 NPU 的 YOLO 模型,是否有推荐的导出流程? 当前 Neutron SDK (v3.1.3) 是否存在任何已知限制?关于YOLO检测头? NXP 是否提供可在 i.MX95 NPU 上成功编译的 YOLOv8/YOLO11 参考模型? 启用运算符映射是否需要额外的编译器选项或预处理步骤? 我们非常希望获得任何与 i.MX95 Neutron NPU 兼容的指导、推荐工作流程或参考模型。 谢谢! Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 谢谢你的回复。​​ 我想咨询一下是否有标准程序可用于在IM X95板上进行模型的训练、导出和部署。​​​​​​​​​​​ 由于我们目前拥有ARA2 ,我们正在寻求充分利用其功能并定制我们的模型。我们将在NXP技术日上进行演示,如果您能在这方面提供帮助,我们将不胜感激。​​​​​​​​​​​ 感谢您的帮助。​​ Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在 imx95 主板上尝试了 eIQ 模型库中的 yolo8m 模型,使用了 LF 2026 Q2 版本镜像。内核版本为 6.18.20,使用 Neutron SDK 3.1.2,运行正常。 xing_lei_0-1783672312304 (1).png     您可以先尝试以下方法: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so 更多信息请参阅 README 文件eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo 此外,您还可以附加转换/编译的模型和详细日志。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 根据变流器日志,首先要解决的问题是生成的 TFLite 模型仍然包含 FLOAT 运算符: 警告:图表中包含不受支持的浮点运算符! 对于 i.MX95 Neutron,中子变流器的输入必须是 TFLite 模型,其算符和量化格式与 Neutron 编译器兼容。具体来说,i.MX95 中子流需要量化的 TFLite 和对称的 int8 权重。如果模型在 Ultralytics 导出或 ONNX 到 TFLite 转换后仍然包含 FLOAT 运算符/张量,则变流器可能无法创建任何 Neutron 兼容的子图,这与报告的结果一致: 已转换运算符:0 中子图数量:0 YOLOv8 已在 i.MX95 上进行过一些流程的评估,但对于任意 Ultralytics 导出,不应假定完全端到端的 YOLOv8/YOLO11 卸载。根据导出的 TFLite 图,模型可能只有一部分会转换为 NeutronGraph,而不支持的操作符将保留在 CPU 上。因此,建议的下一步是检查/分析生成的 TFLite 模型并确认: 该图已完全量化。 没有浮动操作商。 权重是对称的int8, 输入/输出张量类型兼容,或者如果适用,可以使用 Neutron 变流器 uint8 到 int8 选项进行转换。 除非 SDK 确认支持确切的操作符,否则 YOLO 后处理(例如解码/NMS)将保留在 NPU 图之外。 另外,请确保板上的 Neutron 变流器版本和 Neutron 运行时/固件/委托来自同一个兼容的 SDK/电路板支持包 版本。 建议采用 NXP/eIQ 转换路径: PyTorch -> ONNX(静态输入形状) -> NXP/eIQ 量化(使用代表性校准数据) -> 量化后的 TFLite -> 中子变流器 --target imx95 如果模型具有 uint8 输入/输出张量,请同时进行以下测试: --将输入的 uint8 转换为 int8 --convert-outputs-uint8-to-int8 如果移除浮点运算符后,转换结果仍然显示 0 个已映射运算符,请分享: - 完整的 中子变流器 日志,如有详细/分析输出,请提供。 - TFLite 操作员列表, - 张量数据类型和量化参数, - FRDM i.MX95 板上确切的 电路板支持包/运行时 Neutron 代理/固件版本, - YOLO 检测头是否包含 NMS 或 TFLite 图中的其他后处理。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在我的测试中,我没有自己训练或导出模型。我使用了 eIQ 模型库中预先生成的 YOLOv8 模型,并验证了它在 i.MX95 平台上运行。 我实际使用的唯一命令是: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 以该模型为例: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite 对于定制模型,NXP 推荐的流程如下: PyTorch ↓ ONNX(静态输入形状) ↓ eIQ 工具包 ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ 量化 TFLite ↓ 中子变流器 --target imx95 由于您的模型报告: 纯文本 已转换运算符:0 中子图数量:0 警告:图表中包含不支持的 FLOAT 运算符! 我怀疑您生成的 TFLite 图在结构上与 eIQ 模型库参考模型不同。我首先建议做的是比较这两个型号的以下方面: 输入/输出张量类型(INT8 与 UINT8) 浮式经营者的存在 图内的解码/NMS层 Netron/TFLite 分析器报告的运营商列表 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 你好 我运行的是 ubuntu 24.04,但是 eiq_toolkit 仅适用于 20.04.03 版本。 如何使用 eiqToolkit 和使用 eIQ Toolkit 进行量化 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 请问您是如何将 yolov8m_full_integer_quant.tflite 转换为能够在 imx95 NPU 上运行的? 以下步骤和环境设置数据(主机)将对我们非常有帮助。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推荐的端到端工作流程 模型训练(PC) 使用您偏好的框架进行训练: Ultralytics YOLOv8 PyTorch Tensorflow ONNX原生工作流 对于目标检测,NXP 已经在 eIQ 模型库中提供了 YOLO 参考配方,包括 YOLOv8 目标检测模型。[github.com] ,[github.com] 示例: shell yolo 检测训练 \ model=yolov8n.pt \ data=dataset.yaml imgsz=640 \ epochs=100 ` 导出到 ONNX NXP 通常建议在量化和部署之前使用 ONNX 作为交换格式。 yolo 导出 \ model=best.pt \ format=onnx Neutron 启用演示文稿明确描述了基于以下流程的说明: 纯文本 PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ 中子变流器 而不是直接从训练工件中寻找部署目标。 使用 eIQ 工具包进行量化 Neutron 工作流程文档建议使用 eIQ Toolkit 量化工具: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c 输入:: `` 其次是: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite 显示更多行 该流程在 i.MX95 Neutron 实现材料中有明确记录。 为 i.MX95 Neutron NPU 编译 中子变流器 --target imx95 \ --输入 model_int8.tflite \ --输出 model_neutron.tflite Neutron 变流器创建 Neutron 特有的图分区,这些分区可以卸载到 NPU 上。 验证转化率 NPU 部署成功后,应报告类似以下内容: 转换的操作员数量 > 0 中子图数量 > 0 如果你看到: 已转换运算符:0 中子图数量:0 那么该模型就没有被NPU加速。 你目前的问题就属于这一类。 部署在 FRDM-i.MX95 上 使用 TensorFlow Lite 和 Neutron 委托运行: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 或 ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX 机器学习用户指南将Neutron Delegate定义为 i.MX95 TensorFlow Lite 模型的加速机制。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于 eIQ Toolkit 已在 Ubuntu 20.04 上验证过,因此最安全的方法是: Docker 在 Ubuntu 24.04 主机上运行 Ubuntu 20.04 容器: docker run -it --name eiq \ ubuntu:20.04 /bin/bash 然后,在容器内安装所需的依赖项和 eIQ Toolkit。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 使用 eIQ Toolkit (onnx2quant) 转换自定义 YOLOv8 ONNX 模型时,无法保留置信度输出。 概述 NXP团队您好, 我正在尝试使用 eIQ Toolkit 在 FRDM i.MX95 上部署自定义 YOLOv8 单类目标检测模型。 整个转换流程运行成功,但在 onnx2quant 之后,置信度输出全部变为零,而边界框输出仍然有效。 环境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX 运行时 1.21.1 - TensorFlow 2.21 - 中子变流器 3.1.3 - 目标:FRDM i.MX95(tflite_runtime 2.19 + Neutron delegate) 转换管道 1. 火车 yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. 导出 ONNX yolo export model=best.pt format=onnx opset=13 3. 验证 ONNX 输入:(1,3,640,640) 输出:(1,5,8400) ONNX 运行时推理: 置信度通道最大值 = 0.773 4. 生成校准数据集 形状:(1,3,640,640) 数据类型:float32 范围:0.0 - 1.0 5. 量化 onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx 同时测试了: onnx2quant 最佳.onnx -u 两者产生的结果相同。 6. 验证量化的 ONNX 输出:(1,5,8400) 边界框通道仍然有效。 信心: 最小值 = 0 最大值 = 0 平均值 = 0 解码检测结果 = 0 7. 转换为 TFLite 格式 onnx2tflite best_quant.onnx -o best.tflite 8. 为 Neutron 编译 neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite 编译成功。 操作员转化率:278 / 325 (85.5%) 已展开调查 已核实: • PyTorch 模型有效 • ONNX 导出工作 • ONNX 运行时推理功能正常 • 校准数据集正确 • 真实校准和随机校准产生相同的结果 • TFLite 重现量化的 ONNX 输出 • Neutron 可以重现 TFLite 的输出 该问题首次出现于以下情况: ONNX ↓ onnx2quant ↓ 量化 ONNX(置信度变为零) 补充观察 恩智浦参考模型: 输入:(1,640,640,3) INT8 输出:(1,84,8400) INT8 我转换后的模型: 输入:(1,3,640,640) FLOAT32 输出:(1,5,8400) FLOAT32 对于自定义 YOLOv8 模型,是否有推荐的导出或量化工作流程,能够保留置信度输出? 对于输出为 (1,5,8400) 的模型,这可能是 onnx2quant 的一个限制或错误吗? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 与AE团队讨论。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240 的端到端性能是否已经过评估?数据手册中提到了两个矢量核心,可以执行诸如 sigmoid 和 NMS 之类的后处理操作。编译器能否将 NMS 操作映射到向量核心? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 抱歉耽搁了。我正在尝试重现转换工作流程。 现在有一个问题,为什么转换后的模型的数据类型是 FLOAT32?你试过转换成 INT8 类型吗?Neutron NPU 需要 INT8 类型作为输入数据。我在其他模型转换中也遇到过类似的错误,根本原因是数据类型错误。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于对 YOLOv8 的输出张量应用了完全 INT8 量化( inference_output_type=tf.int8 )这一根本限制,置信度输出丢失了。 YOLOv8 将边界框坐标和置信度分数打包成形状为 (1, 5, 8400) 的单个输出张量。bbox 值具有较大的动态范围(~640 像素),而置信度得分在 ~0 到 1 的范围内。当整个输出张量共享一个量化尺度时,该尺度主要由较大的边界框值(~640)构成,只剩下一个整数级别的一小部分来表示整个置信范围(~1)。因此,经过 INT8 量化后,所有置信值实际上都被四舍五入为零。 推荐解决方案 而不是通过  onnx2quant ,直接从您训练好的数据中导出 INT8 TFLite。  .pt  使用 Ultralytics 建模,然后将其输入到  neutron-变流器 : # 直接导出 INT8 TFLite 数据(校准使用您的训练数据集) yolo export model=best.pt \ format=liter \ imgsz=640 \ 量化=8 data=dataset.yaml 分数=0.1 #为Neutron 编译(未更改) neutron-变流器 --target imx95 --input best_int8.tflite --output best_neutron.tflite 请确保输入和输出数据类型为 np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale, inp_zp = inp_d[ "量化" ] out_d = out_ds[0] out_scale, out_zp = out_d[ "量化" ] print(f " 输入数据类型={inp_d['dtype']} 形状={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 输出 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 根据形状确定输入格式 in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] 或 [1,640,640,3] 如果in_shape[1] == 3: # NCHW src=img_nchw 别的: # NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ “索引” ],src_int8) 别的: interp.set_tensor(inp_d[ “索引” ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# 如果 out_d[ "dtype" ] == np.int8,则可能是 int8 或 float32: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale 别的: dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 归一化 # 将边界框重新缩放回像素坐标以便显示 BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 您好,我尝试了您分享的命令…… 但是中子变流器无法转换模型…… 请查收附件日志,供您参考,引用。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 请提供日志。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 您好, 请查看附件中的日志文件。 我成功地训练了模型,并在 i.MX95 NPU 上运行了它。然而,我注意到关于量化参数的一个问题: 数量:(0.003921568859368563,-128) 负的量化零点值引起了我的注意,我想确认这是否是预期行为。 请查看附件中的日志文件。 谢谢!
記事全体を表示
SL3S1206FUD2/HA 请求提供芯片识别文件/晶圆图 尊敬的供应商: 我们想确认您是否提供了任何文件或标记,用于区分晶圆上的“合格芯片”和“不合格芯片”。 具体来说,我们正在寻找: 晶圆图(显示哪些芯片通过/未通过测试), 一份测试结果报告,或 晶圆表面的物理标记(例如墨点、激光标记),可以清晰地识别可用芯片。 我们在显微镜下检查了晶圆,没有发现任何可见的物理标记。这引发了人们的担忧,即我们可能无法可靠地区分合格芯片和有缺陷芯片。 请问您能否帮忙确认一下货物中是否包含这些信息,或者协助我们从制造商那里获取这些信息?我们需要这些数据来进行后续的处理步骤。 感谢您的帮助。我们期待您的回复。
記事全体を表示
MC9S08QG8 编译器,如何获取适用于该芯片的 C 编译器 嗯,我有一款使用 MC9S08QG8 芯片开发的产品。我需要修改一些C代码。我使用的是Windows 11系统。我应该使用什么软件产品来生成芯片的调试器?我正在使用一块 Wiztronics 接口板,将电脑的 USB 端口连接到我产品中的芯片。我尝试过 8 种不同的软件包,但没有一种软件包的最终调试器能够正常工作。您建议使用哪个Software软件包进行调试?我在你的开发中心迷路了。 Re: MC9S08QG8 COMPILER, how do i get the c compiler for this chip Hello CodeWarrior 工具版本 11.1 支持 Windows 11,该工具支持不同的连接方式 [P&E USB Multilink Universal / USB Multilink、P&E Cyclone、开源 BDM、P&E 全芯片仿真]。 您可以从以下链接下载该工具: CodeWarrior ® for MCUs (Eclipse IDE) v11.1 我正在寻找 MC9S08QG8 设备,并且有此版本可供选择。 此致敬礼,路易斯
記事全体を表示