Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ 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 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.     You can try it firstly by: 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 more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Sorry for the delay. I am trying to reproduce the conversion workflow.  One question for now, why the converted model's data type is FLOAT32? Have you tried to convert to INT8? The Neutron NPU requires the INT8 type as input data. I met the similar error on other models conversion and the root cause is the data type. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU The confidence output is lost due to a fundamental limitation of full INT8 quantization ( inference_output_type=tf.int8 ) applied to YOLOv8's output tensor. YOLOv8 packs bounding box coordinates and confidence scores into a single output tensor of shape  (1, 5, 8400) . The bbox values have a large dynamic range (~640 pixels), while the confidence scores are in the range of ~0 to 1. When the entire output tensor shares a single quantization scale, that scale is dominated by the large bbox values (~640), leaving only a fraction of one integer level to represent the entire confidence range (~1). As a result, all confidence values are effectively rounded to zero after INT8 quantization. Recommended Solution Instead of going through  onnx2quant , export INT8 TFLite directly from your trained  .pt  model using Ultralytics, then feed it into  neutron-converter : # Export INT8 TFLite directly (calibration uses your training dataset) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # Compile for Neutron (unchanged) neutron-converter --target imx95 --input best_int8.tflite --output best_neutron.tflite For the input and output data type, please ensure they are 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"  Input  dtype={inp_d['dtype']}  shape={inp_d['shape'].tolist()}"       f"  quant=(scale={inp_scale:.6f}, zp={inp_zp})") print(f"  Output dtype={out_d['dtype']}  shape={out_d['shape'].tolist()}"       f"  quant=(scale={out_scale:.6f}, zp={out_zp})")# Determine input format from shape in_shape = inp_d["shape"].tolist()   # [1,3,640,640] or [1,640,640,3] if in_shape[1] == 3:     # NCHW     src=img_nchw else:     # 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["index"], src_int8) else:     interp.set_tensor(inp_d["index"], src.astype(np.float32))interp.invoke() raw_out = interp.get_tensor(out_d["index"])  # may be int8 or float32if out_d["dtype"] == np.int8:     dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale else:     dq_out = raw_out.astype(np.float32)dq_out = dq_out[0]   # (5, 8400) normalized# Rescale bbox back to pixel coords for display BBOX_SCALE = 640.0 tfl_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 Hi Tried the commands you shared... But neutron-converter is failing to convert the model... please find the log attached for your reference
記事全体を表示
An error occurred while building the target device using GuiGuiDer2.0.0. I have now created a guiguider project based on frdm_mcx947, using version 2.0.0, and selected ARM. The GCC version is 14.4.1. I have already configured the arm gcc tool. The following error message occurred during compilation: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. I was successful in finding the compiler tools using cmd: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
記事全体を表示
GuiGuiDer2.0.0是否只支持LVGL9.4了? GuiGuiDer2.0.0是否只支持LVGL9.4了? 没有V8.3.11或者V8.4的支持了吗 回复: GuiGuiDer2.0.0是否只支持LVGL9.4了? 你好@wqy1103 是的,GUI Guider2.0.0 是为与 LVGL 9.4.0 一起使用而设计的。 BR 哈里
記事全体を表示
TPL+33664+33774 最近、BMSプロジェクトに取り組んでいて、以下の問題に遭遇しました。   NXPの公式ウェブサイトからダウンロードされた公開MC33664データシートには、MC33664トランシーバのレジスタ説明は含まれていません。さらに、私がダウンロードした公式デモコードパッケージには、内部レジスタへのアクセスや操作MC33664ルーチンが一切含まれていません。 TPL3の通信にはMC33664のレジスタへの読み書きアクセスが必要ですか?   レジスタ操作が必須なら、完全なMC33664データシートと、レジスタ読み書きロジックを実装したサンプルデモプロジェクトMC33664誰か共有できますか?どうもありがとうございました! Re: TPL+33664+33774 こんにちは、 ダウンロードされたデータシートは、既に完全な文書です。MC33664には内部レジスタが含まれていないため、TPL通信においてレジスタの読み書き操作は必要ありません。 このデバイスは透過的なTPL物理層トランシーバとして機能します。MCU SPIの送信ストリームをTPLパルス符号化信号に変換し、受信したTPLトラフィックを再びSPI信号に変換します。その結果、TPLネットワーク上のデバイスとの通信は、TPIインターフェースを通じてTPLフレームの送受信によって行われます。 あなたが言及しているのは、内部レジスタ、メッセージキュー、ルーティング機能、レジスタアクセスプロトコルを含む新しいMC33665Aゲートウェイデバイスのことかもしれません。そのため、MC33665Aの完全なデータシート(NDAに基づきセキュアファイルとして入手可能)には、詳細なレジスタの説明が含まれています。 Gen1 SDKの一部として、MC33664とMC33665の両方にSWデバイスドライバーを提供しています。MC33664については、MCUのCDD層が、ウェイクアップシーケンスを実行するピンタイミング、MCU上の2つの独立したSPIブロックを同時に設定・管理、割り込みルーティングなどのタスクを処理します。 BRs、トーマス
記事全体を表示
Does GuiGuiDer 2.0.0 only support LVGL 9.4? Does GuiGuiDer 2.0.0 only support LVGL 9.4? Is there no support for V8.3.11 or V8.4? 回复: GuiGuiDer2.0.0是否只支持LVGL9.4了? Hi @wqy1103  Yes, GUI Guider2.0.0 is designed for use with LVGL 9.4.0. BR Harry
記事全体を表示
GuiGuiDer 2.0.0はLVGL 9.4のみをサポートしているのですか? GuiGuiDer 2.0.0はLVGL 9.4のみをサポートしているのですか?V8.3.11またはV8.4はサポートされていないのですか? 回复: GuiGuiDer2.0.0是否只支持LVGL9.4了? こんにちは、@wqy1103さん はい、GUI Guider2.0.0はLVGL 9.4.0で使用するように設計されています。 BR ハリー
記事全体を表示
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です。うまくいく。     まずは以下から試してみることもできます: 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変換器はモデルの変換に失敗している... 参照用に添付のログをご覧ください
記事全体を表示
Anybody using Kinetis MCUs? I'm currently evaluating some USB-equipped MCUs and the Kinetis line caught my eye for its feature set. I've got a few samples (main one I'd like to focus on being the K22FN1M0VLH12), put them onto breakouts with headers and have worked out a way to bootstrap code onto them using EzPort/SPI, but I'm now getting to the point where I need to actually start proper firmware development. I've done my share of software development, but not much in the way of embedded platforms. I like the look of the new eclipse-based toolchain and Processor Expert that Freescale has released in the last few months, because it handles a lot of the peripheral initialization. However, I'm seeing a real dearth of information regarding either that or using Kinetis with a GCC-based toolchain. The only information (what little there is) going around seems to be restricted to their FRDM boards, which while cheap are restricted to a fairly small subset of their available range. Has anybody out there done any work with Kinetis recently? If so, what toolchain did you use? What are people's general impression of the Kinetis devices/documentation/tools compared to similar ARM chips from other vendors? If I get a K20 FRDM board, do people think the knowledge gained will be relatively portable to the K22F chip I'd like to use in my actual application? There is a K22F FRDM board but it is double the price, the difference being just shy of enough money to grab a STM32 dev board to evaluate alongside this. Also, in general how easy is it to port code from a dev board to a custom board? What's your approach for moving from a development board to a custom circuit? Apologies if this is a lot of questions - I'm just hoping I might be able to pick a few brains. Re: Anybody using Kinetis MCUs? Hello @lukutu , Thanks for your post.  In fact, regarding the Eclipse-based toolchain you mentioned, I assume you are referring to Kinetis Design Studio (KDS) and Processor Expert. Both of these tools are now legacy products and are no longer actively supported.  As the successor to Kinetis Design Studio, NXP introduced MCUXpresso IDE. Like KDS, MCUXpresso IDE is also Eclipse-based and integrates the GNU toolchain, SDK example import, pin/clock/peripheral configuration tools, flash programming capabilities, and seamless SDK integration, providing a more modern and fully supported development environment. MCUXPresso SDK can be download here: MCUXpresso SDK Builder You can refer to MCUXpresso Config Tool for MCUXpresso IDE for config tools usage.   As for hardware selection, I would recommend considering the FRDM-K22F board. Because it differs significantly from the K20 FRDM platform, and there is an additional benefit:  After purchase, reply to your order confirmation email to request a free FRDM-MCXE31B, FRDM-MCXN236, FRDM-MCXA153, or FRDM-MCXA156 coupon to evaluate MCX microcontrollers. The MCX family is NXP's latest MCU portfolio and offers a longer product lifecycle for new designs. You may want to consider the FRDM-MCXA156, which includes USB and could be a good option for future development and evaluation. About porting code from a dev board to a custom board, it's easy to realize with MCUXPresso , please refer to below posts: Hands-On Workshop: Creating a Custom Board SDK for Your Device How to Create Custom Board MCUXpresso SDK Please let me know if you have any further questions. I'd be happy to help. BR Celeste
記事全体を表示
需要协助解决NBP8FD4ST1压力传感器SPI通信问题 您好, 我正在使用NBP8FD4ST1压力传感器和S32K146微控制器。传感器的CS_B/WAKE-UP引脚连接到微控制器的 GPIO 引脚。 逻辑分析仪的信号映射关系如下: D0 → SCLK D1 → CS_B D3 → 就绪 D5 → 中同轴 D7 → MOSI 在通信序列中,当我将CS_B引脚拉低以请求 SPI 通信时, READY引脚如预期般置位。READY 变为高电平后,我发送SPIOPS 寄存器 READ命令 (0x00E1) 。但是,该传感器在 MISO 上始终返回0x0000 。因此,固件验证失败,随后 CS_B 引脚被拉高以终止事务。 请问您能否帮我确认一下我的 SPI 通信序列是否正确,或者我是否遗漏了任何必要的步骤,例如数据手册中描述的唤醒序列、虚拟传输或 SPIOPS 处理? 我还附上了逻辑分析仪的截图供您参考。 感谢您提前给予的支持。 此致, 普拉蒂尤莎。 压力传感器 Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor 你好, Pratyusha, 请注意,NXP 的 MEMS 传感器业务(包括 NBP8FD4ST1 等压力传感器)已转让给意法半导体。自 2026 年 2 月 2 日起,这些传感器的技术支持、产品文档和开发活动将由 STM 负责。因此,很遗憾,我们无法再为 NBP8FD4ST1 提供技术支持。 我建议您直接通过STM的支持渠道或社区论坛联系他们,那里的传感器专家可以帮助您解决实施和通信方面的问题。 BRs,托马斯
記事全体を表示
TPL+33664+33774 我最近在做一个楼宇管理系统(BMS)项目,遇到了以下问题。   从 NXP 官方网站下载的公开 MC33664 数据手册中没有 MC33664 收发器的任何寄存器描述。此外,我下载的官方演示代码包也缺少访问和操作 MC33664 内部寄存器的任何例程。 TPL3 通信是否需要对 MC33664 的寄存器进行读/写访问?   如果寄存器操作是必需的,请问有人可以分享一份完整的 MC33664 数据手册,其中包含完整的寄存器规格,以及一个实现 MC33664 寄存器读/写逻辑的示例演示项目吗?非常感谢! Re: TPL+33664+33774 您好, 您下载的数据表已经是完整的文档了。MC33664 不包含任何内部寄存器,因此 TPL 通信不需要寄存器读/写操作。 该设备可用作透明的TPL物理层收发器。它将 MCU SPI 发送流转换为 TPL 脉冲编码信号,并将接收到的 TPL 流量转换回 SPI 信号。因此,与 TPL 网络上的设备通信是通过 SPI 接口发送和接收 TPL 帧来实现的。 您指的是较新的 MC33665A 网关设备,它确实包含内部寄存器、消息队列、路由功能和寄存器访问协议。因此,MC33665A 的完整数据手册(根据保密协议以安全文件形式提供)包含详尽的寄存器描述。 作为Gen1 SDK的一部分,我们提供了适用于 MC33664 和 MC33665 的软件设备驱动程序。至于 MC33664,MCU 上的 CDD 层负责处理诸如引脚定时以执行唤醒序列、同时配置和管理 MCU 上的两个独立的 SPI 模块、中断路由等任务。 BRs,托马斯
記事全体を表示
PTE4ABTE-32GX eMMC このPHISON製のeMMC PTE4ABTE-32GX をIMX8Mプロセッサと組み合わせて使用する予定です。起動に対応しているか確認してください。参考資料としてデータシートを添付します。 Re: PTE4ABTE-32GX eMMC はい、データシートによると、PHISON PTE4ABTE-32GXはi.MX8Mファミリー(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP)での起動をサポートしているはずです。ただし、i.MX8Mハードウェア設計ガイドに基づくUSDHCインターフェースに接続されている場合に限ります。 Re: PTE4ABTE-32GX eMMC @yipingwangご回答ありがとうございます。 私たちは MIMX8ML5CVNKZAB を使っています。これは i.MX8ML デバイス です。あなたの回答では 、 i.MX8Mファミリ(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP) のみ が言及されています。 ハードウェア設計ガイドラインに従い、 PHISON PTE4ABTE-32GX が i.MX8ML デバイスに接続 された場合、USDHCインターフェースに接続した場合 の起動にも対応されている か確認していただけます か? Re: PTE4ABTE-32GX eMMC はい、i.MX8ML(MIMX8ML5CVNKZAB)はUSDHCインターフェース経由で接続されたeMMCデバイスからの起動をサポートしています。PHISON PTE4ABTE-32GXはeMMC 5.1デバイスであり、i.MX8Mハードウェア設計ガイドに従って接続・設定した場合、i.MX8MLブートフローに対応しることが期待されています。
記事全体を表示
RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Hello, My name is Hye-Woon Jang, and I am currently using the RD33772C14VEVM board. After purchasing the board, I connected it to a DC power supply as shown in the attached photo. Since I do not currently have a suitable 12 V battery available, I am supplying 12 V using the power supply instead. The connections are as follows: 12 V + : VBAT+, K30_12V_L 12 V - : VBAT-, GND_KL31_DOWN I am contacting you because, even when only the power supply is connected, the red RESET LED turns on and continues blinking at intervals of approximately 0.5 to 1 second, as shown in the attached photo. Should I understand this behavior as the board being repeatedly reset? I am asking because the LED brightness appears to be different from when I manually press the RESET button. I would like to run a model using TRACE32. However, when the board is connected to TRACE32, the RESET indication in TRACE32 blinks at the same time as the RESET LED on the board, and it seems that TRACE32 is therefore unable to establish a connection with the target. I would appreciate it if you could confirm whether this RESET LED behavior is normal and advise me on how to resolve the issue.  Thank you for your assistance. Best regards, Hye-Woon Jang #rd33772c14vevm #s32k344 #JTAG #MBDT #reset #T32 #TRACE32 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure And please let me know how I can stop the repeated reset behavior. Thank you. Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure When I purchased the RD33772C14VEVM board, the supplied J5 cable assembly included a board labeled “PWA, X-14VBMS-EMU (700-50656)” at the end of the cable. My understanding is that this board functions as an emulator for battery cell voltages and temperatures when 12 V is supplied as follows: *12v + to K30_12V_L *12v - to GND_K31_DOWN Could this emulator board be used in place of connecting at least three actual battery cells to the MC33772C? Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Hello Jang, please refer to the section 13.2.2 in the MC33772C datasheet. Minimally 3 Cells must be populated with the MC33772C.  For the RD33772C14VEVM 4 Cells are recommended. Then the Cells must supply the MC33772C. Power supplying the MC33772C from external source without populating the Cells will not work.  Please also refer to the AN12536 attached. With Best Regards, Jozef Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Would it be correct to understand it this way? 12 V SUPPLY (−) → B− → SHUNT → VBAT− → X-14VBMS-EMU GND_KL31_DOWN Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Hello Jang, thank you for pointing me to the X-14VBMS-EMU, I see it now. I see a possible issue in the connection. Please connect the negative side of the X-14VBMS-EMU to the other pin of the shunt resistor, so the current will flow through the Shunt resistor and sensed by ISENSE pins. Please refer to the RD33772C14VEVM schematic attached.  Please check if you have the J1 connector populated, for setting the FS26 to DEBUG mode. Please follow the powering order. First please connect the 12V to B+ and B-.  Then connect the connector to J6.  Connect the battery simulation cable to J5 and connect the power source (+12V to the BAT+ (K30) and negative point from the Shunt resistor to BAT- (K31)).  With Best Regards, Jozef Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Hello JozefKozon, Thank you for your response. Based on what you explained and the RD33772C14VEVM board schematic, I connected it as follows: 12 V supply -> shunt -> EMU. However, the reset behavior is still the same. Could you please answer the following questions? I am supplying power after setting the DC power supply to 12 V and 1.5 A. However, I confirmed that the actual current going into the board is 12 V and 0.04 A. Could this be a problem? If the issue in question 1 is a problem, what should I do to make 1.5 A flow into the board? As you explained, I configured the setup so that the wire from the power supply goes through the shunt resistor and then to the EMU. Could you please confirm once whether the setup shown in the attached photo is correct? When TRACE32 is connected, it appears that a reset occurs once every 0.5 seconds, and because of this behavior, I cannot connect TRACE32 to the board. Is there a way to confirm whether the board is actually performing a reset? When I measured the voltage between JTAG pin 10 and GND, it was 4.9 V. However, since I do not have an oscilloscope, there is a limitation in confirming the reset behavior through the JTAG pin. If there is a way to stop the reset behavior, could you please explain it in detail, even though it may be inconvenient? Since we have not yet been able to obtain a 12 V battery, we are conducting the test with the VBAT terminals left unconnected. When 12 V is supplied to B+ and B−, we confirmed that 12 V is present at the VBAT terminals. Could leaving VBAT unconnected be causing the issue? I look forward to your response. Thank you. Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure Hello Jang, Would it be correct to understand it this way? 12 V SUPPLY (−) → B− → SHUNT → VBAT− → X-14VBMS-EMU GND_KL31_DOWN [A] Yes, this is how it is depicted in the RD33772C14VEVM board schematic. With Best Regards, Jozef
記事全体を表示
Concern about Guiguider License Compliance Dear NXP Semiconductors, I am writing to report a potential violation of the license agreement for your Guider software. As we understand, the license for your Guider software explicitly prohibits its commercial use in the development of products based on non-NXP series chips. However, a major multinational corporation is currently using this software in the development of commercial products based on Rockchip series main control chips, which appears to be a clear breach of your license terms. I would like to ask: Does NXP plan to take any enforcement actions to protect its intellectual property rights in this matter? Additionally, if I were to file a formal complaint regarding this violation, what specific evidence would you require to initiate an investigation? I look forward to your response. 回复: Concern about Guiguider License Compliance Guiguider is being used in violation of its license. Your company's Guider software license explicitly prohibits its use in commercial development of non-NXP series chips. A large multinational corporation has violated this license by applying the software to commercial products using Rockchip's main control chips. Will your company take legal action? If I wish to file a complaint, what evidence should I provide?
記事全体を表示
i.MX RT1050 Download Algorithm My current development environment is MCUXPRESSO IDE, using the i.MX RT1050. I understand that because the i.MX RT1050 doesn't have internal flash, an algorithm needs to be downloaded when using external flash. However, this downloaded algorithm is dependent on the chosen flash memory. Does the official documentation explain how to obtain the desired downloaded algorithm for quick and easy use? Re: i.MX RT1050 下载算法 Hi SDFDSFSF, We suggest you do it in the following order: 1. Select an external Flash download algorithm in the project properties. NXP provides some mainstream Flash download algorithms. You can right-click the project -> Properties -> MCU settings -> Memory details and select the NXP-supported flash driver: The flash driver for MCUXpresso is usually located under nxp\LinkServer_xx.x.xx\binaries\Flash, with the .cfx extension. 2. If the selected Flash memory supports SFDP, try the SFDP driver first. In MCUXpresso, you can choose a driver like MIMXRT1050_SFDP_QSPI.cfx. The significance of this type of SFDP driver is that it reduces the dependence on specific part number-specific algorithms through flash self-describing parameters. 3. Create your own using a template. Please refer to the application manual : https://www.nxp.com/docs/en/application-note/AN13386.pdfGenerate a custom CFX file. When modifying it, key parameters should be derived from test results of the external flash datasheet and the flexspi_nor_polling demo in the SDK. In addition to the download algorithm, XIP/Boot Header configuration is also required. Please refer to Solved: Flash interface initialization - NXP Community. The above are the basic methods. You can provide more specific details, such as what model of Flash you are using, what specific difficulties you are encountering at this stage, and this will help you better. Best Regards, Shelly Zhang i.MX RT1050 下载算法 I'm using J-Link, and in MCUXpresso I selected MIMXRT1050_SFDP_QSPI.cfx. Download failed. Re: i.MX RT1050 下载算法 How can I create my own J-Link algorithm for the IMXRT1052 in the MCUXpresso IDE? My Flash file is WINBOD 25Q256JVEQ. My current MCUXpresso IDE version is MCUXpresso IDE v25.6. SDK_EVBK is version 26.06.00. I don't know which example program can be modified to generate the download algorithm I want. Re: i.MX RT1050 下载算法 Dear @SDFDSFSF , The reference example is located in the nxp/LinkServer directory, with the project name iMXRT1050_QSPI: If your pinouts differ from the evaluation board, you will need to modify the pinout configuration. The Flash configuration also needs to be modified according to the datasheet. Please confirm the following: 1. Check if the Flash hardware pins are configured correctly. The FlexSPI pins must be configured according to the RT1050 hardware development manual : Only group A or group B can be selected, and FlexSPI_DQS needs to be left floating. 2. Import the evkbimxrt1050_flexspi_nor_polling_transfer example into the SDK, and modify the flash configuration according to the flash datasheet. (This step can be omitted; it's only to verify that the flash configuration is correct.) 3. Modify the correct flash configuration in the iMXRT1050_QSPI project. Please refer to the following for this step. https://www.nxp.com/docs/en/application-note/AN13386.pdf Best Regards, Shelly Zhang Re: i.MX RT1050 下载算法 It's possible that your hardware pin configuration differs from the evaluation board. We suggest you modify the iMXRT1050_QSPI project to generate the cfx file yourself. Re: i.MX RT1050 下载算法 Is it okay if I use J-Link in the MCUXpresso IDE? I've seen some people say that the MCUXpresso IDE algorithm can only be used in CMSIS-DAP type emulators?
記事全体を表示
i.MX RT1050 下载算法 我现在开发环境是MCUXPRESSO IDE ,用的是i.MX RT1050 。我了解到因为i.MX RT1050 没有内部flash,所以在使用外部flash时需要下载算法。但是这个下载算法又和自己选用的flash有关。官方有没有说明怎么样得到自己想要的下载算法可以快速用起来? Re: i.MX RT1050 下载算法 Hi SDFDSFSF , 建议您按照以下顺序做: 1. 在工程属性里选择外部Flash下载算法,NXP提供了一些主流Flash下载算法。 您可以右键工程->Properties->MCU settings->Memory details选择NXP支持的flash驱动: MCUXpresso的flash驱动通常放在nxp\LinkServer_xx.x.xx\binaries\Flash下面,以.cfx为扩展名。 2. 如果选择的Flash支持SFDP,优先尝试SFDP driver 在MCUXpresso中可以选择类似MIMXRT1050_SFDP_QSPI.cfx这样的Driver。这类 SFDP driver 的意义是通过 flash 自描述参数减少对具体料号专用算法的依赖。 3. 使用模板自己做 请参考应用手册 https://www.nxp.com/docs/en/application-note/AN13386.pdf 生成客户自定义cfx文件。修改时关键参数要来自外部flash datasheet和SDK里的flexspi_nor_polling demo的测试结果。 除了下载算法,还需要XIP/Boot Header配置,请参考Solved: Flash interface initialization - NXP Community  以上是基本的方法。您可以告诉更具体的情况,比如您使用的是什么型号的Flash,您现在进行到哪一步遇到什么具体的困难,这样能更好的帮助到您。 Best Regards, Shelly Zhang i.MX RT1050 下载算法 我用的是JLINK,在MCUXpresso中选择的是MIMXRT1050_SFDP_QSPI.cfx。下载失败 Re: i.MX RT1050 下载算法 怎么样自己做一个JLINK在MCUXpresso ide里面用的 imxrt1052的现在算法? 我的flash是WINBOD 25Q256JVEQ. 我现在的MCUXpresso ide版本是MCUXpresso IDE v25.6。SDK_EVBK是26.06.00。我不知道用哪个例程可以修改生成自己想要的下载算法。 Re: i.MX RT1050 下载算法 Dear @SDFDSFSF , 参考示例在nxp/LinkServer目录下,工程名为iMXRT1050_QSPI: 如果你的引脚跟评估板不一样,需要修改引脚配置。Flash的配置也需要根据datasheet修改。 请确认以下事项: 1. Flash硬件引脚是否配置正确。必须根据RT1050硬件开发手册配置FlexSPI引脚: 只能选择A组或B组,FlexSPI_DQS需要悬空。 2. 在SDK中导入evkbimxrt1050_flexspi_nor_polling_transfer的example,根据flash的datasheet修改flash的配置。(这步可以省略,这步只是为了验证flash的配置是否正确) 3. 将正确的flash配置修改到工程iMXRT1050_QSPI。这步请参考 https://www.nxp.com/docs/en/application-note/AN13386.pdf Best Regards, Shelly Zhang Re: i.MX RT1050 下载算法 可能是您的硬件引脚配置跟评估板有差异,建议您修改iMXRT1050_QSPI工程自己生成cfx文件。 Re: i.MX RT1050 下载算法 我再MCUXpresso IDE下面用JLINK 有关系吗?我看到有的说在是MCXPpresso IDE算法仅能在CMSIS-DAP类型仿真器下使用?
記事全体を表示
Guiguiderライセンスのコンプライアンスに関する懸念 親愛なるNXPセミコンダクターズへ、 私は、あなたのGuiderソフトウェアのライセンス契約違反の可能性を報告するために書いています。 理解している限り、あなたのGuiderソフトウェアのライセンスは、NXPシリーズ以外のチップをベースにした製品開発における商業利用を明確に禁止しています。しかし、現在、大手多国籍企業がこのソフトウェアをRockchipシリーズのメインコントロールチップをベースにした商用製品の開発に使用しており、これはあなたのライセンス条項に明らかな違反と思われます。 お聞きしたいのですが、NXPはこの件に関して知的財産権を保護するために何らかの執行措置を講じる予定はありますか?また、この違反に関して正式な苦情を申し立てる場合、調査を開始するために具体的にどのような証拠が必要となりますか? ご回答をお待ちしております。 回复: Concern about Guiguider License Compliance Guiguiderはライセンスに違反して使用されています。 貴社のGuiderソフトウェアのライセンスでは、NXPシリーズ以外のチップの商用開発における使用を明確に禁止しています。ある大手多国籍企業が、Rockchip社のメイン制御チップを使用した商用製品にこのソフトウェアを適用することで、このライセンスに違反しました。貴社は法的措置を取る予定ですか?苦情を申し立てる場合、どのような証拠を提出すればよいでしょうか?
記事全体を表示
RD33772C14VEVM RESET LEDの繰り返し点滅とTRACE32接続エラー こんにちは、 私の名前はチャン・ヘウンです。現在、RD33772C14VEVMボードを使用しています。 ボードを購入した後、添付の写真のようにDC電源に接続しました。現在、適切な12Vバッテリーが手元にないため、代わりに電源装置を使って12Vを供給しています。 接続は以下のとおりです。 12V+:VBAT+、K30_12V_L 12 V - : VBAT-、GND_KL31_DOWN 電源ユニットのみに接続されていても、赤いRESETLEDが点灯し、添付写真に示されているように約0.5秒から1秒間隔で点滅し続けるため、あなたに連絡しています。 これは、基板が繰り返しリセットされていると理解すべきでしょうか? 手動でリセットボタンを押したときと、LEDの明るさが異なっているように見えるので、質問させていただきました。 TRACE32を使ってモデルを実行したいと思っています。しかし、ボードをTRACE32に接続すると、TRACE32のRESET表示と同時に基板上のRESETLEDが点滅し、TRACE32ターゲットとの接続ができないようです。 このリセットLEDの挙動が正常かどうか確認し、問題の解決方法についてアドバイスをいただけると助かります。ご協力ありがとうございました。 よろしくお願いします、 チャン・ヘウン #rd33772c14vevm #s32k344 #JTAG #MBDT #リセット #T32 #TRACE32 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure リセットの繰り返しを止める方法も教えてください。ありがとう。 Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure RD33772C14VEVMボードを購入した際、付属のJ5ケーブルアセンブリにはケーブルの端に「PWA, X-14VBMS-EMU (700-50656)」とラベル付けされた基板が付属していました。 私の理解では、このボードは12Vが供給された場合、バッテリーセルの電圧と温度のエミュレーターとして機能します。 *12v + からK30_12V_L *12V - GND_K31_DOWN このエミュレーターボードは、少なくとも3つの実際のバッテリーセルをMC33772Cに接続する代わりに使えるでしょうか? Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure このように理解して良いでしょうか? 12V電源(−) → B− → シャント → VBAT− → X-14VBMS-EMU GND_KL31_DOWN Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure こんにちは、チャンさん。 MC33772Cのデータシートのセクション13.2.2を参照してください。最低でも3つのセルにMC33772Cを実装する必要があります。 RD33772C14VEVMには4セルが推奨されます。次に、セルはMC33772Cを供給する必要があります。セルに部品を実装せずに外部電源からMC33772Cに電源を供給しても動作しません。 添付のAN12536もご参照ください。 敬具、 ヨゼフ Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure こんにちは、チャンさん。 X-14VBMS-EMUについて教えていただきありがとうございます。おかげさまで分かりました。接続に問題がある可能性があるようです。X-14VBMS-EMUの負側をシャント抵抗のもう一方のピンに接続してください。そうすれば電流がシャント抵抗を通過し、ISENSEピンで感知されます。添付のRD33772C14VEVMの回路図をご参照ください。 FS26をデバッグモードに設定するには、J1コネクタが正しく接続されているか確認してください。 電源投入の順番を守ってください。まず、12VをB+とB-に接続してください。 次に、コネクタをJ6に接続します。 バッテリーシミュレーションケーブルをJ5に接続し、電源(+12V)をBAT+(K30)に接続し、シャント抵抗器のマイナス点をBAT-(K31)に接続します。 敬具、 ヨゼフ Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure こんにちは、チャンさん。 このように理解して良いでしょうか? 12V電源(−) → B− → シャント → VBAT− → X-14VBMS-EMU GND_KL31_DOWN [A] はい、RD33772C14VEVMボードの回路図ではそのように描かれています。 敬具、 ヨゼフ Re: RD33772C14VEVM Repeated RESET LED Blinking and TRACE32 Connection Failure こんにちは、JozefKozonさん。 ご返信ありがとうございます。 説明されたこととRD33772C14VEVM基板の回路図に基づいて、接続は次の通りです:12V電源 -> シャント -> EMU。しかし、リセット時の動作は以前と同じです。 以下の質問にお答えいただけますか? DC電源を12Vと1.5Aに設定した後に電源を供給しています。しかし、実際に基板に流れ込む電流は12V、0.04Aであることを確認しました。これが問題になる可能性はありますか? 質問1の問題が深刻な場合、基板に1.5Aの電流を流すにはどうすればよいでしょうか? ご説明の通り、電源からの配線がシャント抵抗を通ってEMUに接続するように設定しました。添付の写真に示されているセットアップが正しいかどうか、一度だけ確認していただけますか? TRACE32接続すると、0.5秒ごとにリセットが起こるようで、この動作のせいでTRACE32ボードに接続できません。基板が実際にリセットを実行しているかどうかを確認する方法はありますか?JTAGピン10とGND間の電圧を測定したところ、4.9Vでした。しかし、オシロスコープを持っていないため、JTAGピンを介したリセット動作の確認には限界があります。 リセット動作を止める方法があれば、不便かもしれませんが詳しく説明してもらえますか? 12Vバッテリーを入手できていないため、VBAT端子を接続せずにテストを実施しています。B+とB−に12Vを供給したところ、VBAT端子に12Vが存在することを確認しました。VBATを接続していないことが問題の原因かもしれませんか? ご回答をお待ちしております。 よろしくお願いします。
記事全体を表示
Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi, I am using the NBP8FD4ST1 pressure sensor with the S32K146 microcontroller. The CS_B/WAKE-UP pin of the sensor is connected to a GPIO pin on the microcontroller. The logic analyzer signal mapping is as follows: D0 → SCLK D1 → CS_B D3 → READY D5 → MISO D7 → MOSI During the communication sequence, when I pull the CS_B pin low to request SPI communication, the READY pin is asserted as expected. After READY goes high, I send the SPIOPS register read command (0x00E1). However, the sensor always returns 0x0000 on MISO. As a result, the firmware validation fails, and the CS_B pin is subsequently driven high to terminate the transaction. Could you please help me understand whether my SPI communication sequence is correct or if I am missing any required step, such as the wake-up sequence, dummy transfer, or SPIOPS handling described in the datasheet? I have also attached the logic analyzer screenshots for reference. Thank you in advance for your support. Best regards, Pratyusha. Pressure Sensors Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi Pratyusha, Please note that NXP's MEMS Sensors business, including pressure sensors such as the NBP8FD4ST1, has been transferred to STMicroelectronics. Effective February 2, 2026, technical support, product documentation and development activities for these sensors are now handled by STM. As a result, we are unfortunately no longer able to provide technical support for the NBP8FD4ST1. I recommend that you contact STM directly through their support channels or community forum, where the sensor experts can assist you with your implementation and communication troubleshooting. BRs, Tomas
記事全体を表示
PTE4ABTE-32GX eMMC We are planning to use this eMMC PTE4ABTE-32GX from PHISON with the IMX8M Processor. Please confirm whether this will support booting. Attaching the datasheet for reference. Re: PTE4ABTE-32GX eMMC Yes, based on the datasheet, the PHISON PTE4ABTE-32GX should support booting on the i.MX8M family (i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP), provided it is connected to a USDHC interface according to the i.MX8M Hardware Design Guide. Re: PTE4ABTE-32GX eMMC Yes, the i.MX8ML (MIMX8ML5CVNKZAB) supports booting from an eMMC device connected through the USDHC interface. The PHISON PTE4ABTE-32GX is an eMMC 5.1 device and is expected to be compatible with the i.MX8ML boot flow when connected and configured according to the i.MX8M Hardware Design Guide. Re: PTE4ABTE-32GX eMMC @yipingwang Thanks for your response. We are using MIMX8ML5CVNKZAB, which is an i.MX8ML device. In your response, only the i.MX8M family (i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP) has been mentioned. Could you please confirm whether the PHISON PTE4ABTE-32GX is also supported for booting with the i.MX8ML device when connected to the USDHC interface as per the hardware design guidelines?
記事全体を表示
有人在使用Kinetis的MCU吗? 我目前正在评估一些配备 USB 接口的微控制器,Kinetis 系列的功能集引起了我的注意。我有一些样品(我主要想重点研究的是 K22FN1M0VLH12),把它们放在带接头的扩展板上,并且已经找到了一种使用 EzPort/SPI 将引导代码加载到它们上面的方法,但我现在到了需要真正开始进行正式固件开发的阶段。我做过不少软件开发工作,但在嵌入式平台方面经验不多。我喜欢飞思卡尔最近几个月发布的基于 Eclipse 的新工具链和 Processor Expert,因为它处理了很多外围设备初始化工作。然而,我发现关于这方面的信息非常匮乏,也缺乏关于在基于 GCC 的工具链中使用 Kinetis 的信息。目前流传的信息(虽然很少)似乎仅限于他们的 FRDM 板,虽然价格便宜,但仅限于他们可用产品系列的一小部分。 最近有人用过Kinetis吗?如果是的话,你使用了哪条工具链? 与其它厂商的类似ARM芯片相比,人们对Kinetis的设备/文档/工具的总体印象如何? 如果我拿到一块 K20 FRDM 板,大家认为我所获得的知识能否相对地迁移到我想在实际应用中使用的 K22F 芯片上?虽然有 K22F FRDM 开发板,但价格是它的两倍,差价还不够买一块 STM32 开发板来和这块板一起评估。 另外,一般来说,将代码从开发板移植到定制板有多容易?从开发板到定制电路,您采取了什么方法? 如果问题太多,请见谅——我只是希望能请教一些专家意见。 Re: Anybody using Kinetis MCUs? 你好@lukutu , 感谢你的帖子。 事实上,关于你提到的基于 Eclipse 的工具链,我假设你指的是 Kinetis Design Studio (KDS) 和 Processor Expert。这两个工具现在都是过时产品,不再提供支持。 作为 Kinetis Design Studio 的继任者,NXP 推出了MCUXpresso IDE 。与 KDS 一样,MCUXpresso IDE 也是基于 Eclipse 的,并集成了 GNU 工具链、SDK 示例导入、引脚/时钟/外设配置工具、闪存编程功能以及无缝的 SDK 集成,从而提供了一个更现代化且完全支持的开发环境。 MCUXPresso SDK 可在此处下载: MCUXpresso SDK Builder 您可以参考MCUXpresso IDE 的 MCUXpresso 配置工具来了解配置工具的使用方法。   至于硬件选择,我建议考虑FRDM-K22F主板。因为它与 K20 FRDM 平台有很大不同,而且还有一个额外的好处:购买后,回复您的订单确认电子邮件,即可申请免费的 FRDM-MCXE31B、FRDM-MCXN236、FRDM-MCXA153 或 FRDM-MCXA156 优惠券,用于评估 MCX 微控制器。 MCX 系列是恩智浦最新的 MCU 产品组合,可为新设计提供更长的产品生命周期。您可以考虑FRDM-MCXA156 ,它包含 USB 接口,对于未来的开发和评估来说可能是一个不错的选择。 关于将代码从开发板移植到定制板,使用 MCUXPresso 可以轻松实现,请参考以下帖子: 实践工作坊:为您的设备创建自定义板级 SDK 如何创建自定义板 MCUXpresso SDK 如果您还有其他问题,请告诉我。我很乐意帮忙。 BR 塞莱斯特
記事全体を表示