Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
GuiGuiDer2.0.0是否只支持LVGL9.4了? GuiGuiDer2.0.0是否只支持LVGL9.4了? 没有V8.3.11或者V8.4的支持了吗
查看全文
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?
查看全文
GuiGuiDer 2.0.0はLVGL 9.4のみをサポートしているのですか? GuiGuiDer 2.0.0はLVGL 9.4のみをサポートしているのですか?V8.3.11またはV8.4はサポートされていないのですか?
查看全文
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やその他の後処理が含まれているかどうか。
查看全文
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.
查看全文
需要协助解决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インターフェースに接続されている場合に限ります。
查看全文
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
查看全文
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 下载算法 我现在开发环境是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
查看全文
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
查看全文
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.
查看全文
有人在使用Kinetis的MCU吗? 我目前正在评估一些配备 USB 接口的微控制器,Kinetis 系列的功能集引起了我的注意。我有一些样品(我主要想重点研究的是 K22FN1M0VLH12),把它们放在带接头的扩展板上,并且已经找到了一种使用 EzPort/SPI 将引导代码加载到它们上面的方法,但我现在到了需要真正开始进行正式固件开发的阶段。我做过不少软件开发工作,但在嵌入式平台方面经验不多。我喜欢飞思卡尔最近几个月发布的基于 Eclipse 的新工具链和 Processor Expert,因为它处理了很多外围设备初始化工作。然而,我发现关于这方面的信息非常匮乏,也缺乏关于在基于 GCC 的工具链中使用 Kinetis 的信息。目前流传的信息(虽然很少)似乎仅限于他们的 FRDM 板,虽然价格便宜,但仅限于他们可用产品系列的一小部分。 最近有人用过Kinetis吗?如果是的话,你使用了哪条工具链? 与其它厂商的类似ARM芯片相比,人们对Kinetis的设备/文档/工具的总体印象如何? 如果我拿到一块 K20 FRDM 板,大家认为我所获得的知识能否相对地迁移到我想在实际应用中使用的 K22F 芯片上?虽然有 K22F FRDM 开发板,但价格是它的两倍,差价还不够买一块 STM32 开发板来和这块板一起评估。 另外,一般来说,将代码从开发板移植到定制板有多容易?从开发板到定制电路,您采取了什么方法? 如果问题太多,请见谅——我只是希望能请教一些专家意见。
查看全文
圧力センサのSPI通信に関する支援NBP8FD4ST1必要 こんにちは、 S32K146マイクロコントローラでNBP8FD4ST1圧力センサーを使っています。センサーの CS_B/WAKE-UP ピンはマイクロコントローラのGPIOピンに接続されています。 ロジックアナライザの信号マッピングは以下のとおりです。 D0 → SCLK D1 → CS_B D3 → 準備完了 D5 → MISO D7 → MOSI 通信シーケンス中に、 CS_BピンをローレベルにプルダウンしてSPI通信を要求すると、 READYピンは期待どおりにアサートされます。READYがハイになった後、 SPIOPSレジスタ読み取りコマンド(0x00E1)を送信します。しかし、MISOではセンサーは常に 0x0000 戻ってしまいます。その結果、ファームウェアの検証が失敗し、CS_Bピンがハイレベルに駆動されてトランザクションが終了します。 私のSPI通信シーケンスが正しいのか、それともデータシートに記載されているウェイクアップシーケンス、ダミー転送、SPIOPS処理など、必要なステップを見落としているのか教えていただけますか? 参考までに、ロジックアナライザのスクリーンショットも添付しました。 サポートにあらかじめ感謝いたします。 よろしくお願いします、 プラチューシャ。 圧力センサ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor こんにちは、プラティウシャさん。 なお、NXPのMEMSセンサ事業、NBP8FD4ST1などの圧力センサはSTMicroelectronicsに移管されました。2026年2月2日付で、これらのセンサの技術サポート、製品ドキュメント、開発活動はSTMが担当しています。その結果、残念ながらNBP8FD4ST1の技術サポートは提供できません。 サポートチャネルやコミュニティフォーラムを通じて直接STMに連絡することをお勧めします。センサの専門家が実装やコミュニケーションのトラブルシューティングをサポートいたします。 BRs、トーマス
查看全文
What Is Model-Based Design? A Practical Introduction for Modern Embedded Systems   Table of Contents Why embedded development needs a better workflow What Model-Based Design is A simple mental model: from idea to executable model to hardware Why engineers use it: the core advantages Verification along the way: MIL, SIL, PIL, HIL How NXP enables this with Model-Based Design Toolbox (MBDT) What comes next in this article series 1 Why embedded development needs a better workflow Modern embedded systems are no longer isolated functions running on a single controller. In today's vehicles and intelligent machines, applications span sensing, communication, control, safety logic, diagnostics, and multiple processing nodes that must work together as one system. As this complexity grows, traditional workflows based mainly on handwritten code and late-stage hardware testing become difficult to scale, hard to validate early in the development cycle, and slow to iterate. Issues are often discovered late, when integration becomes more costly and harder to manage. Model-Based Design offers an alternative approach designed to address these challenges. It enables earlier validation and a more structured development flow, where verification is not an afterthought, but part of every stage of development. 2 What Model-Based Design is   Model-Based Design is a visual way of programming, where you build your functionality by drawing an engineering diagram, and that diagram can be executed—either as a simulation on your computer or as code running on real hardware. In this approach, models become the central engineering artifact used to design, simulate, verify, and deploy embedded systems. Instead of starting from low-level implementation details, engineers create an executable model of the application behavior, simulate, verify, refine it, and then generate code for the target system. This model-centric workflow makes designs easier to understand, easier to reuse, and less prone to errors. It also enables model-based testing, where test cases can be derived directly from system models and used to verify behavior early in development. 3 A simple mental model: from idea to executable model to hardware A simple way to think about Model-Based Design is this: you describe what the system should do in an executable model, validate that behavior in simulation, and then carry the same design through to the final implementation. In this approach, the model is not just documentation—it becomes an active engineering asset used for design, simulation, verification, and code generation. This creates a direct path from idea to application, where requirements, design, prototyping, testing, and deployment are connected in one continuous workflow. 4 Why engineers use it: the core advantages One of the biggest advantages of Model-Based Design is that it changes where engineering effort is spent. Instead of focusing primarily on how to implement functionality at a low level, engineers can focus on what the system should do—its behavior, control strategy, and response to real-world scenarios. This approach also enables early validation. System behavior can be simulated on a PC before the final hardware is available, allowing issues to be detected earlier and reducing costly rework late in the development cycle. In addition, Model-Based Design enables hardware-independent simulation, where algorithms can be developed and validated before being tied to a specific target platform. This allows teams to explore designs faster and reuse validated functionality across different hardware solutions. As a result, teams benefit from: faster iteration during development improved traceability between design and implementation reduced integration risk more consistent validation across development stages Ultimately, this contributes directly to faster time-to-market, as development cycles are shortened and fewer late-stage issues need to be addressed. Some concrete examples can be found in the following articles: From Virtual Vehicle to All-Electric Off-Road UTV in Less Than a Year Dyson Accelerates New Product Development with System-Level Simulation 5 Verification along the way: MIL, SIL, PIL, HIL A key strength of Model-Based Design is that validation happens continuously throughout development. This is typically organized into several stages: Model-in-the-Loop (MIL): the model is tested against a simulated environment Software-in-the-Loop (SIL): generated code is executed on the host PC and compared to model behavior Processor-in-the-Loop (PIL): code runs on the target MCU to verify functional correctness and performance Hardware-in-the-Loop (HIL): the controller is tested against a real-time or emulated system before final deployment These stages provide a structured validation path, ensuring that issues are detected early and confidence is built progressively before running on final hardware. Model-Based Design also supports reuse and scalability. A validated model can be adapted, parameterized, or reused across multiple systems, reducing development effort and improving consistency. 6 How NXP enables this with Model-Based Design Toolbox (MBDT) To make this workflow practical on real embedded hardware, NXP provides the Model-Based Design Toolbox (or MBDT). This acts as a bridge between the MathWorks' and NXP's software ecosystems, and allows the entire workflow to be done from one environment, as depicted in the diagram above. Concretely, this allows engineers to use MATLAB and Simulink to design, simulate, verify, and automatically generate code that can run directly on NXP microcontrollers and processors. MBDT provides: block libraries for hardware access integration with configuration tools for pins, clocks, and peripherals support for PIL workflows code generation and deployment capabilities profiling and runtime monitoring through tools like FreeMASTER This creates a complete end-to-end flow—from model to validated application running on target hardware. Engineers can explore functionality at a high level, validate behavior through simulation, and deploy with confidence onto real systems. 7 What comes next in this article series In the articles that follow, we will move from this general introduction to concrete, real application examples. We will show how Model-Based Design and NXP tools can be applied across a modern system architecture, covering applications such as battery management, motor control, radar, steering, lighting, and parking sensors. Each example will illustrate how functions can be designed, validated in simulation, and deployed onto the appropriate hardware nodes. The key idea is simple: Model-Based Design helps engineers focus on system behavior while reducing the gap between concept, implementation, and validation. With NXP's Model-Based Design Toolbox, this approach can be carried from the modeling environment all the way to a running application on hardware. MBDT  https://www.nxp.com/mbdt https://mathworks.com/nxp 
查看全文