MC33 PT2000 ICを使用してSOI -EOIを調整する方法 トピックとして、PT2000を用いてフルー注入SOI-EOI測定を適用する全工程を確立する助けが必要です Hブリッジドライバー 小型機関運転士 ソレノイドコントローラー Re: How use adjust SOI -EOI with use MC33 PT2000 IC 感謝します！ Re: How use adjust SOI -EOI with use MC33 PT2000 IC 親愛なるKaijinbin様、 PT2000のインジェクション終了検出アプリケーションノートは、有効なNDAとともに PT2000製品ページからダウンロード可能です。 JozefKozon_0-1786079976443.png まだNDAを持っていない方で署名を希望される場合は 、こちらから 新しいチケットを作成してください。NDA関連の担当者が手続きをサポートします。 さらに、FRDMPKPT2000EVM製品ページからPT2000SWUGとPT2000-IDEUGをダウンロードしてください。同じページからPT2000 Developer Studio IDEやPeak and HoldおよびDCDCソフトウェアのソフトウェアファイルをダウンロードできます。その後、FRDMPKPT2000EVM評価ボードでソフトウェアの例をテストできます。 JozefKozon_1-1786080423866.png 敬具、 ヨゼフ

请求提供 NXP V2X 评估板和设计文件 尊敬的恩智浦团队： 我们正在评估用于汽车应用的 V2X 通信解决方案，该方案支持 V2V、V2I 和 V2P 功能安全消息。 我们对 NXP 基于 RoadLINK/SAF5400 的 V2X 解决方案和 OrangeBox 平台很感兴趣。请提供以下信息： 推荐的 NXP V2X 评估板或参考平台 评估板订购部件号 SAF5400 的可用性和生命周期状态 参考原理图和硬件设计文件 物料清单和PCB布局指南 射频匹配和天线参考设计 硬件用户手册和软件开发工具包 电路板支持包、驱动程序和示例应用程序 功能安全文档，包括 ASIL-B 支持详情 V2X消息签名和验证的**网络安全**设备建议 获取受控技术文件的保密协议程序 我们计划将其应用于工作在 5.9 GHz 频段的汽车 V2X 通信单元。请确认 NXP 目前是否提供支持 DSRC/IEEE 802.11p、C-V2X PC5 或两者兼备的解决方案。 请提供相关的产品文件、商务联系方式和采购流程。 顺祝商祺！ 伦吉斯·托马斯 高级设计工程师 - 硬件 获取我的解决方案 +91 8015237416 Re: Request for NXP V2X Evaluation Board and Design Files 你好， 希望你一切都好。 这是我们面向汽车 V2X 应用的 DSRC 功能安全调制解调器产品目录： DSRC 功能安全调制解调器。您也可以在这里找到我们推荐的V2X通信产品。 RoadLINK SAF5400是一款适用于汽车应用的单芯片 DSRC 调制解调器，适用于 V2X 应用，符合 IEEE 802.11p 标准。IEEE 1609.4，ETSI EN 302663、ETSI EN 302571 和 ARIB T-109M。 对于由此可能造成的不便，我深表歉意，但遗憾的是，有关 SAF5400 和其他 V2X 汽车产品的信息受保密协议保护。 如需了解这些产品的信息，请联系您当地的代理商，以便他们不仅可以帮助您完成 NDA 流程，还可以为您提供您可能需要的有关这些产品的信息？ 此致， 安娜·索菲亚。

相机模块与 OX05B1S 传感器和内置 ISP 与 i.MX95 FRDM 的兼容性 大家好， 想知道带有 ox05b1s 传感器和内置 ISP 的摄像头模块（类似于NVIDIA Jetson AGX Orin 的 5MP RGB-IR 全局快门 GMSL2 摄像头）是否与 i.MX95 FRDM 板兼容。 我明白 i.MX95 只有 MIPI_CSI2 端口，因此我需要找到 GMSL2 到 MIPI_CSI2 的转换器，但我的问题具体与 NXP Linux 电路板支持包中现有驱动程序的兼容性有关。NXP Linux 版本的摄像头驱动程序是否可以直接与此摄像头模块配合使用？ 我需要修改dtb文件吗？还有其他需要修改的地方吗？或者我需要计划一些额外的工作吗？

MCALコンポーネントSbc_fs26とOSコンポーネントfreeRTOSを使用したK344およびFS26のサンプルコード こんにちは、 Sbc_fs26とfreeRTOSのコンポーネントを統合したS32K344とFS26チップのソースコード例(S32DSプロジェクト)を教えてもらえますか? 個別のRTDの例があることは承知しています。 1) Sbc_fs26_example_HLD_S32K344 (FreeRTOSなし) 2) FreeRTOS_Toggle_Led_Example_S32K344 (Sbc_fs26なし) そして、例を挙げると次のようになります。 3) MR_CANHUBK3_IEEE1722（ウォッチドッグが無効で、Sbc_fs26コンポーネントが使用されていない） 要するに、FreeRTOS環境でFS26チップを適切に設定および更新するための基本的なソースコード例を探しています。 よろしくお願いします。 Re: Example code for K344 & FS26 with MCAL component Sbc_fs26 and OS component freeRTOS こんにちは、スラヴコさん。 現時点では、これらの要素を組み合わせたプロジェクト例は把握していません。   あなたが挙げた例は、関連する参考資料です。 - Sbc_fs26_example_HLD_S32K344 これはFS26/SBCの統合を示すものですが、FreeRTOSは使用していません。 - FreeRTOS_Toggle_Led_Example_S32K344 これはS32K344上での基本的なFreeRTOSのセットアップ例を示していますが、FS26 SBCコンポーネントは含まれていません。 - MR_CANHUBK3_IEEE1722 これにはより広範なシステムレベルの実装が含まれますが、FS26ウォッチドッグは無効になっており、Sbc_fs26コンポーネントは使用されていません。 あなたのユースケースでは、実用的な方法はSbc_fs26_example_HLD_S32K344プロジェクトから始めて、FreeRTOSの例からFreeRTOS構成を統合することです。FS26の初期化はシステムの起動シーケンスの一部として残し、ウォッチドッグの更新はFreeRTOSタスクや他のデターミニスティックなタイミング機構から定期的に処理されるべきです。   BRs、トーマス

Himiway：ミッドドライブ方式とハブモーター方式：メリットとデメリット 電動自転車を購入する際、最も重要な決断の一つは、ミッドドライブモーターとハブモーターのどちらを選ぶかということです。 どちらのデザインも自動的に優れているわけではありません。ミッドドライブモーターは、自転車のギアを駆使して急な坂道やテクニカルな地形を走行するのに特に優れている一方、ハブモーターは構造がシンプルで、通常は価格も手頃であり、駆動系のメンテナンスも少なくて済む。 多くの日常的なライダーにとって、優れたハブモーターは十分すぎるほどの性能を提供する。急な坂道や山道、あるいは荷物を積んで走行するようなライダーは、ミッドドライブシステムの方がよりメリットを得られるかもしれません。 具体的な比較をしてみましょう。 ミッドドライブとハブモーターの比較を一目で見た 特徴:ミッドドライブモーターハブモーター エンジンの位置 クランク/ペダル周辺 フロントホイールハブかリアホイールハブ 丘陵、トレイル、テクニカルライディング、通勤、レジャー、混合の日常走行に最適です 坂道性能:トルクに応じて良好から優秀 重量配分は非常にバランスが取れている。片方の車輪に重さが増す。 駆動系の摩耗は高く、低くなっています メンテナンスはより手間がかかる。一般的には簡単です。 パンクタイヤ修理 通常、モーターホイールの取り外しは簡単なものの、より難しいことがあります ペダルの感触はしばしば非常に自然で、センサーのチューニングに大きく依存します 価格が通常は高く、通常はより手頃です。 ミッドドライブモーターとは何ですか? ミッドドライブモーターは、ペダルとクランクセットがフレームに接するボトムブラケット付近に配置されています。 モーターは車輪を直接回転させるのではなく、自転車の駆動系を通して動力を伝達する。つまり、モーターはライダーと同じようにバイクのギアを活用できるのです。 例えば急な登りでは低速ギアに切り替えると、モーターはより有利な速度で動作し、強力な登坂補助を得られます。 これが、高性能な電動マウンテンバイクや、険しい地形向けに設計されたその他の自転車でミッドドライブシステムが人気を集めている最大の理由です。 ミッドドライブモーターの利点 1. 優れた登坂性能 これはおそらく、ミッドドライブエンジンを支持する最も強力な論拠だろう。 モーターのパワーは自転車のギアを通るため、登る際には低いギアを選ぶことができます。これにより、モーターが非常に低い回転数で自転車を坂道で引っ張ろうとするのではなく、効率的に動作させることができます。 非常に起伏のある地域に住むライダーにとっては、これは目に見える違いを生み出します。 しかし、ミッドドライブモーター搭載の自転車がすべてハブモーター搭載の自転車よりも自動的に登坂性能に優れているとは限らないので、その点は注意が必要です。モータートルク、コントローラーのチューニング、ライダーの重量、ギア比、タイヤサイズ、そしてバイク全体の重量がすべて重要です。 高トルクの750Wギア付きハブモーターは、通常の道路や中程度のトレイルでも優れたヒルクライマーです。 2. 重量配分の改善 ミッドドライブモーターは、その重量を自転車の低い位置、かつ中心付近に配置する。 一般的に、前輪や後輪の中に大きなモーターが集中していないため、バイクの操縦性はよりニュートラルになります。 その利点は、テクニカルなマウンテンバイク走行時、素早い方向転換時、そして起伏の多い地形を走行する際に特に顕著になる。 3. モーター動力の効率的な利用 モーターは自転車のギアを使えるため、ミッドドライブシステムはより効率的な回転数範囲でモーターを動作させることができます。 これにより、頻繁に高低差が起こるルートの効率が向上します。 しかし、だからといってミッドドライブの方が必ずしも飛距離が長いとは限らない。バッテリー容量、速度、タイヤ空気圧、ライダーの重量、気温、標高、風速、アシストレベルなどが実際の航続距離に大きな影響を与えることがあります。 4. 自然なペダリング体験 多くの上位ミッドドライブシステムはトルクセンサーと組み合わされています。 トルクセンサーはペダルをどれだけ強く踏んでいるかを測定し、それに応じてモーターの補助を調整します。 もっと強く押せば、もっと多くの支援が得られる。ペダルを軽く踏むと、モーターの反応も穏やかになります。 その結果、普通の自転車に乗るのと驚くほど似た感覚になることがありますが、突然脚がずっと強くなるだけです。 ミッドドライブモーターのデメリット 1.ドライブトレインの摩耗が増加 ミッドドライブエンジンの登坂性能における利点となる同じ特徴が、同時に最大の欠点の1つにもなっている。 ライダーとモーターの両方が、以下のようなコンポーネントを通して動力を伝達します。 チェーン チェーンリング カセット ディレイラーシステム 高いモータートルクと悪いシフト習慣が組み合わさると、駆動系の摩耗が加速します。 モーターが最大出力を発揮している状態で頻繁にギアチェンジを行うと、チェーンやカセットスプロケットの歯が著しく早く摩耗する可能性があります。 2. より高価 ミッドドライブシステムは一般的に高価です。 モーターはクランク周辺に組み込む必要があり、フレームは多くの場合、その駆動ユニットに合わせて特別に設計する必要がある。 主に舗装路や比較的緩やかな地形を走行するライダーにとって、割増料金を支払うことは、十分な実質的なメリットをもたらさないかもしれない。 3. シフト技術の重要性 ミッドドライブのライダーはギアについてもっと慎重に考える必要があります。 急な坂道を非常に高いギアで発進し、その後、エンジンに大きな負荷がかかった状態でギアチェンジするのは理想的ではありません。優れたライディングテクニックとは、駆動系に大きな負荷がかかる前に適切なギアを選択することである。 経験豊富なサイクリストにとっては、これはすぐに自然な動作となる。初心者には学習曲線があります。 4. チェーンが切れると、より大きな問題になることがあります ミッドドライブはチェーンを通じてモーターの動力を伝達するため、ドライブトレインの故障で後輪を駆動できなくなる可能性があります。 スロットル装備のハブドライブバイクは、モーターが自転車チェーンから独立して動作するため、ここで有利に働きます。 ハブモーターとは何ですか？ ハブモーターは、前輪または後輪の中央に直接組み込まれています。 リアハブモーターは、現代の電動自転車で特に一般的です。 チェーンとカセットを介して動力を伝えるのではなく、モーターが直接ホイールを回転させる。これにより、システムは機械的に簡素化され、モーターの動力を従来の自転車の駆動系から分離することができる。 いくつかのヒミウェイモデルは強力なハブドライブ構成を採用しています。Himiway D5 2.0シリーズのようなバイクは、ハブモーターが実用的なファットタイヤの電動バイクで人気を保ち続けている理由を示しています。大きなトルクと比較的シンプルな操作を組み合わせることができるからです。 ハブモーターの長所 1. シンプルで手間のかかりにくい設計 最大の利点の一つはシンプルさです。 モーターは通常、自転車のチェーンやカセットを通して動力を伝達しません。したがって、駆動系はペダリング力のみを処理すればよく、ペダリング力とモーター出力の両方を処理する必要はありません。 通勤、週末のサイクリング、買い物、レクリエーションなど、電動自転車を様々な用途で利用したいライダーにとって、このシンプルさは非常に価値がある。 2. 毎日力強いパフォーマンスを発揮 ハブモーターは平坦な道路にしか適していないという考え方は時代遅れだ。 現代のギアードハブモーターはかなりのトルクを発生させることができます。 例えば、Himiway D5 2.0は、トルク90Nmの750Wギアードハブモーターを使用しています。それは、完全に平坦な自転車道をただゆったりと走るためではなく、力強い加速と効果的な登坂補助を提供するように設計された仕様です。 D5 2.0 20インチは、同じ一般的な**アイデア**を20インチファットタイヤとフルサスペンションで組み合わせ、快適さと操作性を重視したコンパクトな**プラットフォーム**をライダーに提供しています。 普通の丘や近隣の通り、砂利道、レクリエーション用のトレイルなどでは、よく設計されたハブモーターが十分に対応可能です。 3. 購入コストの削減 ハブモーターは一般的に、メーカーにとって電動自転車への組み込みが比較的簡単で、コストも抑えられる。 これにより、バイクの予算をより多く、例えば以下のような他の機能に充てることができます。 大型バッテリー 油圧ブレーキ より良いサスペンション 統合照明 ファットタイヤ ペイロード容量の増加 これがハブドライブバイクがコストパフォーマンスに見合った非常に魅力的な仕様を提供できる理由の一つです。 4. チェーンとカセットへの負担軽減 モーターの動力は直接車輪に伝わるため、チェーンはモーターの全トルクを伝達する必要がない。 これは、両バイクが適切にメンテナンスされていれば、パワフルなミッドドライブバイクに比べてドライブトレインの部品寿命が長くなることを意味します。 5. スロットル操作が有用であること スロットル付きの対応ハブドライブ電動自転車では、モーターの動作は必ずしも自転車の駆動系に依存しません。 これは、停止からのスタートや交差点を一時的に通過する際、または荷物を運ぶときにバイクを動かす際に便利です。 また、重要な機械的利点も備えている。チェーンが切れても、必ずしもモーターが自転車を動かすのを妨げるわけではないのだ。 ハブモーターズの短所 1. 極限の登りでは効率が劣る 従来のハブモーターでは、ミッドドライブのように自転車のカセットを活用できません。 長く急な登り坂では、モーターは高負荷状態で低速運転を余儀なくされる可能性がある。 これにより熱発生量やエネルギー消費が増加します。 時折の坂道ではあまり気にしない場合もあります。毎日急な山道を登るライダーにとっては、それはさらに重要な意味を持つようになる。 2. 後輪または前輪が重い モーターは、それが搭載されている車輪にかなりの質量を加える。 ほとんどのパワフルな電動自転車はリアハブモーターを使用しているため、持ち上げたり整備したりする際に後部が重く感じられることがあります。 実際に自転車に乗っている時よりも、自転車を階段で運ぶ時に、このことに気づきやすいかもしれません。 3. パンクタイヤの修理はより複雑になることがあります ハブモーターのホイールは、普通の自転車ホイールほど簡単には取り外せません。 モーターケーブルを外して、かなり重い車輪を扱う必要があるかもしれません。 そのため、正しいタイヤ空気圧を維持し、パンクしにくいタイヤを使用することは、ハブドライブの電動自転車では特に有効です。 Himiwayの電動自転車はどうでしょうか？ Himiwayの電動自転車は良い例と言えるでしょう。なぜなら、同社の自転車の多くは、単に高級感があるという理由だけでミッドドライブ方式を採用するのではなく、パワフルなハブ駆動システムを重視しているからです。 Himiway D5、D5 Pro、D5 2.0、D5 2.0 ST、D5 2.0 Camo、D5 2.0 20インチ、C3、A7、A7 Pro、D7、D7 Proなどのモデルは異なるライディングタイプを対象としているため、重要なのはエンジンの位置だけで判断するのではなく、全体のバイクを見ることです。 例えば、D5 2.0の購入を検討しているライダーは、可能な限り軽量なドライブトレインを実現することよりも、強力なトルク、太いタイヤでのトラクション、サスペンションの快適性、航続距離、そして日常的な信頼性を重視するかもしれません。 D5 2.0 20インチは、操作性と快適性を重視するライダーにとって特に魅力的なモデルです。20インチの小型ホイール、4インチ幅のタイヤ、フルサスペンション、そして低重心設計により、従来の大型ホイールのマウンテンバイクとは全く異なる乗り心地を実現しています。 一方、A7とA7 Proは都市交通や日常の使いやすさを重視するライダーにより関連性が高いです。 そしてC1キッズは全く別のカテゴリーに属する。若いライダーにとっては、制御性、適切なサイズ、速度マネジメント、ブレーキング、大人の監督が、最大限のモータートルクを追い求めるよりもはるかに重要です。 これは重要な教訓を浮き彫りにしている。 電動自転車を選ぶ際は、モーターの性能だけで判断しないでください。 ライダーが実際に気づくこと 仕様は役立つが、実際の日常的な運転では、その違いははるかに分かりやすくなる。 適切に調整されたハブモーター搭載の自転車は、通常の通勤において、しばしば楽に感じられる。ペダルを漕ぐとアシストが到着し、ギアのことを常に気にすることなく前進し続けることができます。 優れたミッドドライブシステムは、ギアを積極的に使うライダーに報いる傾向がある。坂道に近づく際は、ギアを一段下げることで、エンジンとライダーが効率的に連携して走行することができる。テクニカルな地形では、重心を中心に置くことで自転車のバランス感も向上します。 平坦な自転車道を中程度の速度で走行している場合、その差ははるかに小さくなる。 そのため、ミッドドライブに大幅に高い費用をかけることが、すべてのライダーにとって必ずしも価値があるとは限らないのです。 坂道走行に適したモーターはどちらですか？ 本格的な登坂には、ミッドドライブが最適だ。 普段の走行ルートに長くて急な山登りが含まれる場合、ミッドドライブモーターが自転車のギアを活用できる点は大きな利点となります。 しかし、「丘」と「極端な丘」の間には重要な違いがある。 ほとんどの人は毎朝山道を登っているわけではない。 高トルクギアードのハブモーターは、典型的な近隣の丘陵地帯、起伏のある田園地帯、砂利道、そして中程度のトレイルクライムにも非常によく対応できます。だからこそ、Himiway D5 2.0のようなバイクは、より高価なミッドドライブプラットフォームに移行せずに登攀能力を求めるライダーにとって理にかなっています。 通勤にはどちらが良いですか？ 一般的な通勤であれば、ハブモーターの方が有利だと思います。 シンプルで比較的安価であり、自転車の駆動系にかかるモーター関連の負荷も少なく、通常の都市部での走行には十分なアシストを提供します。 しかし、通勤経路に非常に急な地形が含まれる場合は、中間地点での運転がより魅力的になる。 マウンテンバイクにはどちらが良いですか？ 本格的なテクニカルマウンテンバイクなら、ミッドドライブを選ぶでしょう。 エンジンを中心に置くことで重量配分が改善され、急な登りやテクニカルな登りでもギア比へのアクセスが役立ちます。 砂利道、森林道、未舗装道路、キャンプ、比較的中程度のレクリエーショントレイルでは、パワフルなファットタイヤのハブドライブバイクは依然として優れた選択肢となり得ます。 初心者にはどちらが良いですか？ 多くの初心者にとって、ハブモーター式の電動自転車の方が理にかなっている。 モーターを適切なギアに入れておく必要性が少なく、駆動系のメンテナンスも簡単で、価格も手頃な場合が多い。 しかし、使いやすさに影響を与える要因はモーターの種類だけではありません。 フレームジオメトリ、ホイールサイズ、バイクの重量、スタンドオーバー高さ、スロットル挙動、トルクやケイデンスのセンス、ブレーキ、サスペンションなどもライダーの自信にさらに大きな影響を与えます。 ミッドドライブ方式 vs ハブモーター方式：最終結論 万人に勝者はいない。 次のような場合は、ミッドドライブモーターを選択してください。 定期的に非常に急な坂道を登る テクニカルな山道を走る 重量バランスの取れた配分を望む 自然でパフォーマンス重視のライディングフィールを好む 追加のドライブトレインメンテナンスは気にしない より多くのお金を支払うことに抵抗がない ハブモーターを選ぶべきなのは、次のような場合です。 通勤やレクリエーションでの乗車 主に平坦から中程度の丘陵地帯に遭遇します メンテナンスを抑えたい 予算に見合ったより良い価値を望む 機械的にシンプルなシステムを好む 自転車の駆動系に依存しないモーターの動作が欲しい 多くの日常的なライダーにとって、高品質なギアードハブモーターはパワー、シンプルさ、信頼性、価格のバランスが良いです。適切に設計された750Wの高トルクハブドライブ電動自転車は、平坦な市街地だけでなく、はるかに多くの道を走行できます。 地形が本当に険しくなった時、ミッドドライブは特に重宝する。 ですから、「どちらのモーターが良いか?」と聞く代わりに、次の質問をしてください。 「この自転車は実際どこで乗るんだろう？」 もし答えが険しい山道や厳しい登り坂であれば、ミッドドライブコースをよく検討してみてください。通勤、週末のライド、砂利道、用事、中程度の坂道など、Himiwayのラインナップにあるいくつかのモデルのような良いハブドライブ電動自転車は、使わない複雑さにお金をかけずに必要なものをすべて提供できるかもしれません。

#S32K388 S32K388 LPI2Cはデバッグモードに入ると停止します lpi2cを使用している際に、プログラムがデバッグモードで停止してしまうという状況に遭遇しました。しかし、PE接続を切断してプログラムを再起動したところ、正常に動作しました。プログラムが実行中にデバッグモードで停止した。 する ヤージュ /* マスターがデータを送信する */ Lpi2c_Ip_MasterSend(Instance); ElapsedTicks += OsIf_GetElapsed(&CurrentTicks, I2C_TIMEOUT_TYPE); }while ((Lpi2c_Ip_MasterGetTransferStatus(Instance, NULL_PTR) == LPI2C_IP_BUSY_STATUS) && (ElapsedTicks < TimeoutTicks)); この問題を解決する方法はありますか？ Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered こんにちは@zhangyu5454 I2Cデバッグ有効化オプションが選択されているか確認してもらえますか? MCR[DBGEN] = 1のとき、LPI2CモジュールはMCUのデバッグ中も動作を続けます。 MCR[DBGEN] = 0の場合、アプリケーションをプログラムし、デバッガを接続せずに通常通りボードを動作させた後、LPI2Cは期待通りに動作します。 BR、VaneB Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered ご返信ありがとうございます。私は.mexを使ってi2cの設定をしていますが、どうやってMCR[DBGEN] =1をコントロールするように設定すればいいですか? Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered こんにちは@zhangyu5454 参考までに、以下の画像を掲載しました。 VaneB_0-1786396779346.png Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered こんにちは@zhangyu5454 このオプションは最新のRTDリリースに追加され、ペリフェラルツールから直接設定できるようになりました。 以前のRTDバージョンを使用しているため、アプリケーションコード内でMCR[DBGEN]を設定するのが推奨されます。 Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered zhangyu5454_0-1786418199524.png ページの表示が異なっていることに気づきました。このオプションが見つかりませんでした。私のバージョンはRTD5.0です。

IMX95ブートカウント管理 こんにちは、 最近、imx95 19x19 EVKボードの開発に取り組んでいて、ディストリビューションのアップデート/リカバリーにブートカウント マネジメントの仕組みを実装したいと考えています。 TRMを調べてみたところ、GPR（汎用レジスタ）はBBNSM内にあり、SCMIプロトコル（M33上で動作するSMへのリクエスト）を介してアクセスできることがわかりました。u-bootでは、arch/arm/mach-imx/imx9/scmi/soc.cで親切にAPIを用意しており、scmi_set_bbnsm_gpr scmi_get_bbnsm_gpr bootcount_store()/_load()を問題なく実装できました。 しかし、カーネルにはそのようなAPIは存在しません！(成功した起動後にLinuxユーザー空間からブートカウントをリセットしたいと思っています。) さらに、あなたのドキュメントでCyber Resilient Recovery Module(CRRM)を見かけたのですが、ディストリビューションアップデートのために自己管理のブートカウントが本当に必要かどうか疑問に思っています。 そこで、あなたに以下の質問があります。 なぜカーネル内でGPRアクセス用のSCMI APIをサポートしていないのですか?CRRMがGPRの一つを使っているからですか? CRRMを使用する場合、ディストリビューションのアップデート管理にブートカウントを設けるのは理にかなっていますか？はいの場合、GPR以外でブートカウントを保存する場所として推奨される場所はありますか？(またはGPRにアクセスする他の方法など) どんな回答でも大変ありがたく思います。 SoC: i.MX 95 (19x19 LPDDR5 EVK) BSP: LF6.18.20_2.0.0 ありがとうございました。 アブデル Re: IMX95 bootcount managment こんにちは、 @Chaviraさん 貴重なご説明をありがとうございました。 GPRの使用は問題ありませんが、NXPのカーネル側でGPRアクセスを追加する公式ドライバはありますか? カーネルソースのドライバ/ファームウェア/arm_scmi/ベンダーズ/IMXの項目でimx-sm-bbm.cが確認できますGPRコマンドを定義しますが、実装はしません!! enum scmi_imx_bbm_protocol_cmd { IMX_BBM_GPR_SET = 0x3、 IMX_BBM_GPR_GET = 0x4、 IMX_BBM_RTC_ATTRIBUTES = 0x5、 IMX_BBM_RTC_TIME_SET = 0x6、 IMX_BBM_RTC_TIME_GET = 0x7、 IMX_BBM_RTC_ALARM_SET = 0x8、 IMX_BBM_BUTTON_GET = 0x9、 IMX_BBM_RTC_NOTIFY = 0xA、 IMX_BBM_BUTTON_NOTIFY = 0xB、 };   リストされているコマンドはすべて実装するが、GPRコマンドだけは実装しないという決定には、何か理由があるのでしょうか？私は、独自の実装に頼る前に、NXPが意図するアプローチに沿うことを好みます。   よろしくお願いいたします。 アブデル Re: IMX95 bootcount managment こんにちは、 @Abder さん。 詳細な調査をありがとうございました。 簡単に言うと、CRRMとROMリカバリはブートカウント機構を置き換えるものではありません。破損や無効なブートイメージからの復旧は助けますが、Linuxやアプリケーションが正常に起動したかどうかは判別できません。OTAアップデートソリューションの場合、アップデートの失敗を検出し、自動的にロールバックを実行するために、ブートカウント機能が引き続き推奨されます。 BBNSM GPRに関しては、U-BootはNXP固有のSCMI関数を通じてアクセスを提供しますが、Linuxは現在同等のインターフェースを公開していません。これらのレジスタにLinuxでアクセスが必要な場合は、カスタムカーネルドライバーやSCMIベンダー拡張が必要になるでしょう。 あなたのユースケースでは、すでにU-Bootで動作しているBBNSM GPRをブートカウントストレージとして使い続けることをお勧めします。CRRMのリカバリーとブートカウント管理は異なる目的を果たしており、代替案ではなく補完的なメカニズムとみなすべきです。 よろしくお願いします、 チャビラ Re: IMX95 bootcount managment こんにちは、 @Abder さん。 ご指摘ありがとうございます。あなたの指摘は正しいです。 IMX_BBM_GPR_SETおよびIMX_BBM_GPR_GETコマンドはBBMプロトコル仕様で定義されており、ファームウェアは汎用レジスタ(GPR)へのアクセスをサポートしています。しかし、現在のLinuxのimx-sm-bbmドライバーではこれらのコマンドのサポートは実装されていません。現時点では、このドライバはRTCおよびボタン関連の機能のみを公開しており、これらは既存のLinuxサブシステム(RTCおよび入力フレームワーク)と直接統合されています。 GPRアクセスはまだ上流ドライバから利用可能ではありませんが、ドライバは初期化時に利用可能なGPRの数の情報を取得・保存しています。これは基盤となるインフラストラクチャが部分的に整っており、ドライバ設計時にGPRサポートが考慮されたことを示しています。しかし、これらのレジスタをユーザー空間に公開する公式のカーネルインターフェースやリリースされたドライバ実装は現在存在しません。 よろしくお願いします、 チャビラ

iMX8 Nanoのカーネルを5.15から6.18にアップデート こんにちは A53コア用にカーネルを5.15から6.18に移植する際、rpmSGの問題に直面しています。 # dmesg -T |grep -Ei 'rpmsg|rproc' [2024年10月8日火曜日 15:42:28] IMX RPMSGドライバーが登録されました。 [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: error -ENOENT: クロックを有効にしられませんでした [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: ドライバ付きプローブ imx-rproc エラー -2 で失敗 [火曜日 2024年10月8日 15:42:29] remoteproc remoteproc0: releaseingimx-rproc このエラーが出ます。このエラーをオンラインで検索したところ、DTSにダミークロックを追加するように求められました。 IMX8Mn-CM7 { 互換性 = "FSL,IMX8mn-CM7"; RSC-DA = <0xb8000000>; クロック = <&CLK IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mbox = <μ 0 1 &ミュー 1 1 μ 3 1>; memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "OK"; } これが唯一の変更なのでしょうか?この変更の理由は何ですか。 よろしくお願いいたします ヤドゥナス・R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 いいえ、私は clocks = <&clk IMX8MN_CLK_DUMMY>; を唯一の必要な変更として扱うつもりはありません。これで即時の-ENOENT: Failed to Enable Clock probe failureを乗り越えられるかもしれませんが、i.MX8M Nanoの場合、重要な要件はLinuxがM7ファームウェアを読み込み/起動する際にCortex-M7のルートクロックが有効のままであるということです。 理由： imx-rproc ノードにはクロックエントリがあることが想定されています。AN5317 では、compatible = "fsl,imx8mn-cm7" と clocks = <...> プロパティ、さらに mailbox および memory-region エントリを持つ i.MX8M remoteproc DTS ノードが示されています。 あなたのエラーは、カーネル6.18のimx-rprocドライバーがそのノードからクロックを取得して有効化しようとした際、-ENOENTでクロック検索が失敗したため、リモートプローク0がレジスタジアムのままになる前にプローブが中止されたことを意味します。 NXPのAMPガイダンスには「i.MX 8Mプラットフォームでは、M7/M4のルートクロックを常にLinuxで有効にしてファームウェアコードを読み込み、Cortex M7/M4を起動させる必要があります」とあります。 また、NXP Linux BSPはU-BootからMコアを起動した際にこのルートクロックを有効にしているとも書かれています。それ以外の場合、MコアをLinuxブートから起動した場合、ドライバ/clk/imx/clk-composite-8m.cを更新してMコアクロックのゲート登録をスキップする必要があります。 したがって、この変化には二つの意味が考えられます。 ダミークロックを互換性回避策として使う カーネル6.18 imx-rprocがクロックの性質を必要としているが、実のM7クロックが共通クロックフレームワークで意図的に制御されていない場合、IMX8MN_CLK_DUMMYを追加することでドライバーのクロック処理要件を満たし、-ENOENTを回避できます。 実クロック制御の修正 もしLinuxが実際にM7の読み込みや起動を担当している場合、ダミークロックだけではプローブエラーを隠すかもしれませんが、M7クロックが有効になる保証はありません。その場合、NXP BSPクロックドライバーの処理かclk-composite-8m.cのいずれかでM7/M4のルートクロックがオンになっていることを確認してください変更内容はAN5317に記載されています。 クロックラインだけでなく、remoteproc/rpmsg DTSの残りの部分も確認してください。 imx8mn-cm7 { 互換性 = "fsl,imx8mn-cm7";      rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* または、お使いのBSPで使用される正しいM7クロック */      mbox-names = "tx", "rx", "rxdb";      mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;      memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "オーケー"; }; メモリ領域リストは重要で、AN5317ではこのプロパティがファームウェアELFで使用されるメモリセクションを含まなければならず、remoteprocがsysfsから再ロードできるとされています。 推奨されるチェックパス： M7をU-Bootから起動する場合は、NXPのprepare_mcore/bootauxなどのフローを使い、その後Linuxを起動します。AN5317によると、BSPはこの経路でMコアのルートクロックを有効にしています。 Linux remoteprocからM7を起動する場合、6.18クロックドライバーにNXP対応が含まれているか確認し、Mコアのルートクロックを常に有効にしてください。そうでなければ、ダミークロックはプローブのみを修正し、実行時の開始・ロードは修正されません。 作成したDTSファイルをNXP imx8mn-*-rpmsg.dtsと比較してください。同じ BSP リリースの場合、特にクロック、mboxes、rsc-da、および予約済みメモリレイアウト。 ダミークロックは即時の-ENOENTプローブ故障を説明しますが、実際の設計要件はi.MX8MN M7のルートクロックを有効にしておくことです。DTSだけで十分かどうかは、6.18 BSPクロックドライバーがすでにそのクロックを保持しているかどうかに依存します。

ECC RAMのスクラビング MCU:S32K148 ドライバー:RTD 3.0.0 OS: ベアメタル 上記のMCUで、ECC SRAMを「スクラブ」する方法はありますか?「スクラビング」とは、修正可能なエラーが検出された場合、ユーザーが適切なレジスタを設定した場合にSRAMセルが正しい値で更新されることを意味します。TI Herculesのような競合製品にはこの機能があります。 Re: Scrubbing ECC RAM フィードバックをいただき、誠にありがとうございます。 Re: Scrubbing ECC RAM S32K1デバイスは、修正可能なECCイベント後に修正されたデータを自動的にメモリに書き戻すハードウェアSRAMスクラブ機構をサポートしていません。ソフトウェアベースの実装も実現不可能で、単一ビットSRAM ECCの訂正イベントはERMによって報告されないため、アプリケーションは影響を受けたメモリ位置を特定できません。 S32K3ファミリーも自動SRAMスクラブを提供しませんが、シングルビットのECCイベントを報告し、アプリケーションがこれらのエラーを可視化し、より高度なフォールト処理戦略の実装を可能にします。

FRDM-IMX95: SDカードから起動するとシリアル出力がない (プリインストールされたeMMCブートは正常に動作します) こんにちは、NXPコミュニティの皆さん、 私は機械工学と電気工学のバックグラウンドを持っていますが、複雑なシステムオンチップ（SoC）や組み込みオペレーティングシステムに深く取り組むのは今回が初めてです。 私のプロジェクトではFRDM-IMX95の開発ボードを使用しています。私の最終目標は、IPC（プロセス間通信）フレームワークを使用して、2つのオペレーティングシステムを並行して実行することです。 ボードは内部eMMCにプリインストールされたLinuxイメージを同梱していました。これは箱から出してすぐに完璧に動作し、ターミナルモニタープログラムでシリアル出力ログを完全に取得できます。 現在、公式の Starting Guide に従って、Windowsホストマシン上でUUU(Universal Update Utility)を使って標準のLinux BSPイメージをmicroSDカードにフラッシュしようとしています。 Windowsのコマンドプロンプトによると、UUUのフラッシュ処理は「SUCCESS」ステータスで完了します。私は以下の標準コマンドレイアウトを使用しました: ".\uuu.exe -b sd_all imx-boot-imx95-15x15-lpddr4x-frdm-sd.bin-flash_all imx-image-full-imx95evk.wic" 問題点:フラッシュに成功した後、ボードを電源を切り、物理的なブートスイッチをSDブートモードに設定し、SW1 [1:2]を11(オン/オン)に設定します。ボードの電源を入れ直しても、シリアルモニターは完全に空白のままです。テキスト出力やハードウェアの初期化は一切表示されません。 1. ブートチェーンの仕組みについて、私は根本的な誤解をしているのでしょうか？i.MX Linux ユーザーガイドによると、.wicはこのイメージには、ブートローダーイメージ（U-Boot）を含む、4つの必須要素すべてが含まれています。基本的なハードウェア構成ブロックはカードから読み込まれるはずなので、少なくとも最初のU-Boot SPLシーケンスがシリアルモニターに表示されるべきではないでしょうか？ この特定のFRDMバリアントで初心者がよく注意する落とし穴、あるいは隠れたスイッチの要件について、何かアドバイスがあればぜひ教えてください! よろしくお願いいたします。 FRDMトレーニング Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly こんにちは、 現在、こちらでテストを行い、正確な手順をお伝えします。近日中に更新いたします。 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 調査していただき、またそちらでテストしていただき、ありがとうございます！ご協力ありがとうございます。今後のご報告をお待ちしております。 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 問題は、uuuツールでSDカードにフラッシュしようとしているからです。emmCはemmcをフラッシュするために作られています。SDカードをフラッシュしたい場合は、Linuxホストマシンで以下のコマンドを実行する必要があります。 $ sudo dd if= .wicof=/dev/sdx bs=1M && sync SD/MMCカードに割り当てられたデバイスノードを確認するには次のコマンドを実行します。 $ cat /proc/partitions メジャーマイナー #ブロック名 8 0 78125000 sda 8 1 75095811 sda1 8 2 1 sda2 8 5 3028221 sda5 8 32 488386584 sdc 8 33 488386552 sdc1 8 16 3921920 sdb 8 18 3905535 sdb1

PCA9615 dI2C通信の両端の回路、つまりツイストワイヤ束を介して接続された2枚のPCB間の回路（DSDAPとDSDAM、DSCLPとDSCLM、2本のGND、および2本の5Vライン）について助けを求めてご連絡しました。この前にGeminiをテストすることに決め、残念ながらdI2C通信に関連する2つのPCBの部品を生成するためにAIに頼ってしまいました。dI2Cに関連する回路図の一部を添付します。当然のことながら、各ボード間には通信手段がありませんでしたが、私の怠惰と、正直に言うと愚かさ（教訓になりました）のせいで、多くの時間を無駄にしてしまいました。最終的にデモボードのデータシートとユーザーマニュアルを参照したところ、明らかな違いは正の線(DSCLPとDSDAP)とVDD(B)の間に600オームの抵抗があり、負極線(DSCLMとDSDAM)とVSSの抵抗が同じで、正負の線間は120オームで、正負の線間は100オームになると知っています(1/600 + 1/120 = 1/600 + 5/600 =100ですが、電気的には見えません。多分機械工学者だからでしょうか?この誤差(おそらく複数のエラーの一つ)は、それぞれのウィリーの間に600オームプルアップ抵抗、600オームプルダウン抵抗、120オーム抵抗が存在しないことによるものです(28 AWGツイストワイヤペアの特性インピーダンスは、内部データリンクやUSB/イーサネット構成で約100オームのケーブル、標準的な間隔構成では78 Ωから95 Ωの配線です。PVCまたはFEP絶縁線)を使い、代わりにPCA9615のdI2C側の接続線の両端に100オームのリサイザーを単純に設置するという、単純化され、おそらく誤ったバージョンだったのでしょうか? これは、AIが私に示してくれた結果と、データシートの図1、7、8、9に示されている結果との間の重要な相違点の1つです。もう一つの違いは、AIが2枚のプリント基板に対して異なるコンデンサ配置を提案したのに対し、デモボードには1種類の配置しかない点です（これはdI2C接続ラインの両側で使用されるものと思われます）。さらに、VDDAピンとVDDBピンそれぞれに2つのコンデンサがあるようです。どちらもセラミックコンデンサです（ただし、最初に思ったのは、2つの黄色のコンデンサはタンタルタイプだろうということでした）。デモのユーザーマニュアルに記載されているコンデンサ配置を使い、添付のAIが提供・示したものは無視してもいいのでしょうか? もう一つの問題は、マスター側(私が3.3Vマイクロコントローラを使っている)では、当初AIがイネーブルピンを5Vラインにコネクテッドするよう指示していたことですが、基板を作った後、両基板間で機能がなかったため、AIはマスター側のイネーブピンをマスターボードの3.3Vライン(VDD(A)にコネクテッドすべきだと判断しました。3.3Vのラインにコネクテッドされています。その後、テストとして、マスター基板上のイネーブルピンへの電源供給を完全に遮断するよう要求した。どの電源、もし全てをENピンに流すべきなら、アドバイスしてもらえますか?テスト中または最終動作中は、電気部品のホットスワップは一切行いません。 上記変更の実施を検討していますが、高価な基板を導入する前に、ぜひとも皆様のご意見を伺いたいと思っています。 Re: PCA9615 コンデンサに関してもう一つ補足すると、マスター基板上のVDDAピンとVDDBピンの両方には、デカップリングコンデンサのみが推奨されています。スレーブ基板にもデカップリングコンデンサが提案されたが、スレーブ基板のVDDBピンにもさらに2つのコンデンサが提案された。 Re: PCA9615 こんにちは！ 詳しい説明をありがとうございました。 なお、NXPはPCA9615ファミリの評価ボードを提供しており、実装の**リファレンス・デザイン**として利用できます。デザインには推奨される差動I²C終端ネットワーク、バイアス抵抗、デカップリングコンデンサ、ENピン接続が含まれており、NXPによって検証されているため、回路図をPCA9615評価基板および対応ユーザーマニュアルと比較することを強くお勧めします。 評価ボード回路図を基準に、カスタムPCA9615ベースのシステムを設計する際には、設定やレイアウトの問題のリスクを最小限に抑え、データシートやアプリケーションドキュメントの推奨事項に従うため、最良のアプローチとなることが多いです。 次のPCB改訂に取り組む前に、評価ボードの回路図を確認し、設計を適切に更新することをお勧めします。 https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL お役に立てば幸いです！

件名:MC33774A AFE(RD33774CNC3EVB)用のスタンドアロン評価ソフトウェア/GUI 私は、RD33774CNC3EVB(MC33774A拠点のCMU)とRD-K358BMU評価ボードと協力しています。 MC33774A AFEを、BMSシステム全体を統合することなく、単独で評価および検証したいと考えています。私の目標は、以下のような機能を検証することです。 - セル電圧測定 - 温度測定 - 診断および障害報告 - 受動的な細胞バランス調整 - レジスタ設定 - BMUとAFE間の通信 私には以下の質問があります。 1. NXPはMC33774A向けに独立した評価用GUIやPCソフトウェアを提供していますか? 2. BMUを通じて、FreeMASTERプロジェクトやデモンストレーション用GUI、またはその他のグラフィカルツールでMC33774Aを監視・設定できるものはありますか? 3. 最小限のソフトウェア開発でMC33774Aを評価できるリファレンスアプリケーションや例ファームウェアはありますか? 4. BMUおよびCMU評価ボードのみを使ってMC33774A評価する推奨セットアップを説明したアプリケーションはありますか? 私の目的は、AFEを完全なBMSシステムに統合する前に、その機能検証を行うことです。 サポートありがとうございます。 RD33774CNC3EVB 、 MC33774 、 MC33665A Re: Subject: Standalone Evaluation Software / GUI for MC33774A AFE (RD33774CNC3EVB) サンケット様、 1. NXPはMC33774A向けに独立した評価用GUIやPCソフトウェアを提供していますか? [A] はい、MC33774A 用の EvalGUI 7 があります。特にRD33774ADSTEVBと併用してください。GUIは、MCUとSPI間の通信をTPLトランシーバに、さらにTPL経由でMC33774Aに通信するためのSPIインターフェースと連携することを想定しています。UM11816を参照してください。 JozefKozon_0-1785399710998.png もしRD33774CNC3EVB専用のGUIがあるかどうかを尋ねているなら、CTNインターフェース経由でMCUと通信するためのMC33665A TPLからCANトランシーバーへの接続が入っている場合、残念ながら存在しません。 2. BMUを通じて、FreeMASTERプロジェクトやデモンストレーション用GUI、またはその他のグラフィカルツールでMC33774Aを監視・設定できるものはありますか? [A] BMUとCMUのボードについては、ソフトウェアバンドルを丸ごと用意しています。ただし、 S32DSのIDEが必要です。 JozefKozon_6-1785400949053.png こちらのリンクをご参照ください。FreeMASTER用のデモプロジェクトが含まれています。 JozefKozon_1-1785400007530.png 右側のリリースノートをご参照ください。 JozefKozon_2-1785400038979.png 3. 最小限のソフトウェア開発でMC33774Aを評価できるリファレンスアプリケーションや例ファームウェアはありますか? [A] 上記のEVB用のソフトウェアをご覧ください。しかし、2枚のボードでは不十分です。MC33774A 1個につき最低4個のセルを備えた独自のバッテリーパックが必要です。または、 BATT-18EMULATOR をご利用ください。これは、RD33774CNC3EVB に搭載された各 MC33774A に対して18個のセルをエミュレートします。 UM11943を参照してください。 JozefKozon_3-1785400370798.png JozefKozon_4-1785400486233.png 4. BMUおよびCMU評価ボードのみを使ってMC33774A評価する推奨セットアップを説明したアプリケーションはありますか? [A] はい、あります。ただし、前述のとおり、バッテリーパックまたはバッテリーエミュレーターのいずれかが必要です。UM11943およびこちらのリンクを参照してください。 JozefKozon_5-1785400737734.png 敬具、 ヨゼフ Re: Subject: Standalone Evaluation Software / GUI for MC33774A AFE (RD33774CNC3EVB) 当社では部品番号が利用できませんが、必要なセットアップRD3374CNT3EVB IDは提供されていますので、TPLベースのRD33774CNT3EVBを単独テストに使えますか RD33774CNT3EVB 

S32DS ARM 2018 R1 许可证过期 你好， 3e3ddc69f7c74134887b48237e8792a5.png       我的S32DS许可证：1F6C-C156-4EFC-CE54       申请延期/重新发放 谢谢 Re: S32DS ARM 2018 R1 许可证过期 您的 S32DS 许可证已延期。 Re: S32DS ARM 2018 R1 许可证过期 你好： 我的S32DS许可证： 3961-E8A1-3B9E-B769 延期/重新签发申请 非常感谢！ 414179465_0-1786263896843.png

如何使用 Zephyr 在 IMXRT1170 上使用 FLEXPWM？ 大家好， ，我计划将 Zephyr 与 IMXRT1176 配合使用，并使用 FLEXPWM 生成 PWM 信号输出。 我阅读了之前一些关于 FLEXPWM 和 XBAR 的帖子。需要启动 XBARA，以便将 FLEXPWM 路由到裸机代码的输出。 现在我想知道，这在 Zephyr 中是如何工作的？我需要在设备树中定义什么？我还能简单地定义 FLEXPWM 组然后编译系统处理 XBARA 配置吗？ 据我了解，zephyr 使用通用 API 来设置 PWM 的输出，但是 IMXRT117X MCU 中有这样的硬件依赖关系，这是如何工作的？手动设置？ 有没有任何例子或说明可以帮助澄清这方面的问题？ Re: how to use FLEXPWM on IMXRT1170 using Zephyr? 你好@TomC818、 感谢您对 NXP MIMXRT 系列的关注！ 在 Zephyr 中，如果所选引脚是正常的 FLEXPWM 交替功能，则只需在 devicetree 中启用相应的 FLEXPWM 子模块，并提供正确的 pinctrl 即可。Zephyr 的 MCUX PWM 驱动程序将应用 pinctrl，并通过通用 PWM API 配置 FLEXPWM。MIMXRT1170 EVK 已经提供了这样一个示例，将 flexpwm1_pwm2 和 GPIO_AD_04 用作 FLEXPWM1_PWM2_A。 但是，如果您的设计需要通过 XBARA 将 FLEXPWM 信号路由到 XBAR 输出引脚，则当前的 Zephyr PWM 驱动程序不会自动将 XBARA 配置为 PWM。您需要使用 MCUX SDK API 在主板/应用程序初始化时手动配置 XBARA，或者添加一个小型自定义驱动程序/初始化函数来使用 xbar-maps 属性。Zephyr 有一个 nxp,mcux-xbar 绑定，一些驱动程序（如 QDEC）会使用它，但 PWM 驱动程序本身目前并不使用 xbar 映射。 请参考以下两个关键驱动因素： 1.https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pwm/pwm_mcux.c 2.https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/sensor/nxp/qdec_mcux/qdec_mcux.c 致以最诚挚的问候， Gavin Re: how to use FLEXPWM on IMXRT1170 using Zephyr? 您能否进一步解释一下这个答案？`xbar-maps` 在源代码树中的唯一使用似乎是在 `/zephyr/samples/sensor/qdec/boards/mimxrt1050_evk_mimxrt1052_hyperflash.overlay` 中。 这是否类似于使用数值？ kXBARA1_InputFlexpwm1Pwm0OutTrig0 ->  kXBARA1_OutputFlexpwm1Pwm0Exta ?

ADT7420温度センサーは基板frdm_mcxw72動作しません こんにちは、 frdm_mcxwボードでADT7420のサンプルデモを実行しようとしましたが、印刷メッセージは「センサ:デバイスが準備できません」と表示されます。ターゲットにイメージをフラッシュした後。 ハードウェア構成は、参考として以下の画像を参照してください。 anliu114036_0-1786010612902.png ハードウェアの配線は、以下の説明に従って行ったので問題ないと思います。 anliu114036_1-1786010728607.png そして、下記のようにボードフォルダに追加したオーバーレイファイルも見つかります anliu114036_2-1786010818065.png また、ビルドログファイルも添付しました。そこからさらに情報を得るのに役立つと思います。確認して問題解決に協力してもらえますか? Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board こんにちは、お元気でお過ごしでしょうか。   共有してくれた画像からすると、KW47-LOCボードを使っているようですが、これが正しいデバイスか確認していただけますか? どのZephyrリポジトリとバージョンを使っていますか?ご存知かもしれませんが、KW47-LOCボードはZephyrで直接サポートされておらず、frdm-mcxw72のみがサポートされています。とはいえ、チップは互換性があるので、frdm-mcxw72の例を使い、オーバーレイファイルをKW47-LOCボードのピンに合わせて修正できます。 オーバーレイ設定を確認すると、KW47-LOCボードはLPI2C1モジュールのみをサポートしているため、オーバーレイ内のlpi2c1ノードを有効にする必要があります。SCLピンとSDAピンについては、frdm_mcxw72-pinctrl.dtsiでI2C1のPTB4とPTB5として定義されています。これらはKW47-LOCのピンと一致しているため、そのままにしておくことをお勧めします。J2ピン6をターゲットのMCUピンPTB4に接続するために、J24の2-3をショートさせてください。   MikroBUS I2Cピン配置についてはUM12114を参照してください。 ピン2：WUU0_P12/PTC7のINT（ハードウェア割り込み） ピン5：I2C1_SCLのSCL（I2Cクロック） ピン 6: I2C1_SDA の SDA (I2C データ)   また、prj.conf ファイルで以下の設定が有効になっていることを確認してください。 CONFIG_I2C=y CONFIG_SENSOR=y CONFIG_ADT7420=y   よろしくお願いします、 アナ・ソフィア。 Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board こんにちは、アナ ご支援ありがとうございます。はい、KW47-LOCボードを使ったことがあり、このボードでfrdm-mcxw72の例を動かそうとしました。Zephyrリポジトリ版はv4.4.1です。 I2C0からI2C1へのオーバーレイファイルを切り替えた後、ADT7420デバイスの初期化は問題なさそうですが、このセンサーはまだ正しい温度を読み取れません。下記はシリアルモニターからの印刷メッセージです。 anliu114036_0-1786427779708.png 最新のオーバーレイファイルとprj.confファイルの内容は以下のとおりです。 anliu114036_1-1786427965565.png anliu114036_3-1786428011874.png よろしくお願いいたします。 リウ・ウェイ

iMX8 Nano 内核从 5.15 更新至 6.18 你好 在将 A53 内核从 5.15 移植到 6.18 时，遇到了 rpmsg 的问题。 # dmesg -T | grep -Ei 'rpmsg|rproc' [2024年10月8日星期二 15:42:28] imx rpmsg 驱动程序已注册。 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：错误 -ENOENT：启用时钟失败 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：使用驱动程序 imx-rproc 进行探测失败，错误代码为 -2 [2024年10月8日星期二 15:42:29] remoteproc remoteproc0：正在释放 imx-rproc 我遇到了这个错误。我在网上搜索这个错误时，有人建议我在 DTS 文件中添加一个虚拟时钟，如下所示。 imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7"; rsc-da = <0xb8000000>; clocks = <&clk IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; 内存区域 = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; 状态 = "正常"; } 请问是否只需要做这一项更改？更改的原因是什么？ 问候 亚杜纳特·R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 不——我不会将 clocks = <&clk IMX8MN_CLK_DUMMY>; 视为唯一需要的更改。或许可以解决眼前的 -ENOENT：启用时钟探测失败的问题，但对于 i.MX8M Nano 来说，重要的要求是，当 Linux 加载/启动 M7 固件时，Cortex-M7 根时钟必须保持启用状态。 原因： imx-rproc 节点应该有一个时钟条目；AN5317 显示了 i.MX8M remoteproc DTS 节点，其 compatible = "fsl,imx8mn-cm7" 和 clocks = <...> 属性，以及邮箱和内存区域条目。 您的错误意味着内核 6.18 imx-rproc 驱动程序尝试从该节点获取/启用时钟，但时钟查找失败并出现 -ENOENT 错误，因此在 remoteproc0 保持注册状态之前探测中止。 NXP 的 AMP 指南指出： “对于 i.MX 8M 平台，Linux 必须始终启用 M7/M4 的根时钟，才能加载固件代码并启动 Cortex M7/M4。”它还指出，NXP Linux 电路板支持包 在 M 内核从 U-Boot 启动时保持此根时钟启用；否则，如果 M 内核首先从 Linux 启动，则必须更新 drivers/clk/imx/clk-composite-8m.c 以跳过 M 内核时钟的门注册。 所以这一变化有两种可能的含义： 使用虚拟时钟作为兼容性替代方案 如果内核 6.18 imx-rproc 需要一个 clocks 属性，但实际的 M7 时钟并非有意通过通用时钟框架控制，则添加 IMX8MN_CLK_DUMMY 可以满足驱动程序的时钟句柄要求，并避免 -ENOENT。 真正的时钟控制修复 如果 Linux 实际上负责加载/启动 M7，那么仅使用虚拟时钟可能会掩盖探测错误，但不能保证 M7 时钟已启用。在这种情况下，您必须确保 M7/M4 根时钟保持开启状态，这可以通过 NXP 电路板支持包时钟驱动程序处理或 clk-composite-8m.c 文件来实现。AN5317 中描述的变更。 此外，还要检查 remoteproc/rpmsg DTS 的其余部分，而不仅仅是时钟线： imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7";         rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* 或您的 电路板支持包 使用的正确 M7 时钟 */ mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>; memory-region = , , , ;         status = "okay"; }; 内存区域列表很重要，因为 AN5317 指出此属性必须包含固件 ELF 使用的内存部分，以便 remoteproc 可以从 sysfs 重新加载它。 推荐检查路径： 如果从U-Boot启动 M7，请使用 NXP 流程，例如 prepare_mcore / bootaux，然后启动 Linux；AN5317 指出，这是 BSP 保持 M 内核根时钟启用的路径。 如果您从Linux remoteproc启动 M7，请确认您的 6.18 时钟驱动程序包含 NXP 处理，以保持 M 内核根时钟始终启用；否则，虚拟时钟可能只能修复探测，而不能修复运行时启动/加载。 将您的 DTS 与 NXP imx8mn-*-rpmsg.dts 进行比较对于同一个 BSP 版本，特别是时钟、mboxes、rsc-da 和保留内存布局。 虚拟时钟解释了立即出现的 -ENOENT 探测失败，但真正的设计要求是保持 i.MX8MN M7 根时钟启用；仅靠 DTS 是否足够取决于你的 6.18 BSP 时钟驱动程序是否已经保留了该时钟。

K344 和 FS26 的示例代码，包含 MCAL 元器件 Sbc_fs26 和 OS 元器件 freeRTOS。 你好， 能否提供一个集成了 Sbc_fs26 和 freeRTOS 组件的 S32K344 和 FS26 芯片源代码示例（S32DS 项目）？ 我知道有一些个别RTD的例子： 1) Sbc_fs26_example_HLD_S32K344（无 freeRTOS） 2) FreeRTOS_Toggle_Led_Example_S32K344（无 Sbc_fs26） 举个例子： 3) MR_CANHUBK3_IEEE1722，其中看门狗功能被禁用，并且未使用 Sbc_fs26 元器件。 我主要想找一个基本的源代码示例，用于在 freeRTOS 环境中正确设置和刷新 FS26 芯片。 谢谢！ Re: Example code for K344 & FS26 with MCAL component Sbc_fs26 and OS component freeRTOS 你好，斯拉夫科， 目前，我还没有看到将这些元器件结合起来的实例项目。   您提到的例子都是相关的参考点： - Sbc_fs26_example_HLD_S32K344 这演示了 FS26/SBC 的集成，但它没有使用 FreeRTOS。 - FreeRTOS_Toggle_Led_Example_S32K344 这演示了 S32K344 上的基本 FreeRTOS 设置，但不包括 FS26 SBC 元器件。 - MR_CANHUBK3_IEEE1722 这包括更广泛的系统级实现，但 FS26 看门狗被禁用，并且未使用 Sbc_fs26 元器件。 就您的使用情况而言，比较实际的方法是先从 Sbc_fs26_example_HLD_S32K344 项目入手，然后集成 FreeRTOS 示例中的 FreeRTOS 配置。FS26 初始化应保留为系统启动序列的一部分，而看门狗刷新应由 FreeRTOS 任务或其他确定性计时机制定期处理。   BRs，托马斯

FRDM-IMX95：从 SD 卡启动时无串口输出（预装 eMMC 启动完全正常） NXP社区的各位朋友，大家好！ 我拥有机械和电气工程背景，这是我第一次深入研究复杂的片上系统 (SoC) 和嵌入式操作系统。 我的项目使用的是 FRDM-IMX95 开发板。我的最终目标是使用 IPC（进程间通信）框架并行运行两个操作系统。 主板到货时，其内部 eMMC 上预装了 Linux 镜像。它开箱即用，完美运行，我的终端监测程序中可以获取完整的串行输出日志。 现在，我正在尝试按照官方入门指南，使用 Windows 主机上的 UUU（通用更新实用程序）将标准 Linux 电路板支持包映像刷写到 microSD 卡上。 根据 Windows 命令提示符显示，UUU 刷新过程以“成功”状态完成。我使用了以下标准命令布局： “.\uuu.exe -b sd_all imx-boot-imx95-15x15-lpddr4x-frdm-sd.bin-flash_all imx-image-full-imx95evk.wic” 问题：成功刷写固件后，我关闭电路板，并将物理启动开关配置为 SD 启动模式，方法是将 SW1 [1:2] 设置为 11（ON / ON）。当我重新启动电路板时，串口监视器完全空白。完全没有任何文本输出或硬件初始化信息可见。 1. 我是否对这里的启动链的工作原理存在根本性的误解？根据i.MX Linux 用户指南，.wic镜像包含所有四个基本部分，包括引导加载程序镜像（U-Boot）。既然基本的硬件配置块应该从卡上读取，那么我的串口监视器上至少应该能看到初始的 U-Boot SPL 序列吧？ 任何关于此特定 FRDM 变体的见解、初学者常犯的错误或隐藏的开关要求都将不胜感激！ 顺祝商祺！ FRDM 培训 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 你好， 我这边正在进行测试，稍后会把具体步骤分享给你，稍后会更新。 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 感谢您调查并进行了测试！感谢您的帮助，期待您的最新消息。 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 你遇到这个问题是因为你试图使用 uuu 工具将固件刷入 SD 卡，而 uuu 工具是用来刷写 eMMC 的。如果你想将固件刷写到 SD 卡上，你需要在 Linux 主机上执行以下命令。 $ sudo dd if= .wicof=/dev/sdx bs=1M && 同步 要确定分配给SD/MMC卡的设备节点，执行以下命令： $ cat /proc/partitions 主次 #块名称 8 0 78125000 sda 8 1 75095811 sda1 8 2 1 sda2 8 5 3028221 sda5 8 32 488386584 sdc 8 33 488386552 sdc1 8 16 3921920 sdb 8 18 3905535 sdb1

#S32K388 S32K388 LPI2C 进入调试模式后将停止运行 在使用 lpi2c 时，我遇到了程序卡在调试模式的情况。但是，当我断开 PE 连接并重新启动程序后，它就能正常工作了。程序在运行时卡在了调试模式。 做 { /* 主发送数据 */ Lpi2c_Ip_MasterSend(实例); ElapsedTicks += OsIf_GetElapsed(&CurrentTicks, I2C_TIMEOUT_TYPE); while ((Lpi2c_Ip_MasterGetTransferStatus(Instance, NULL_PTR) == LPI2C_IP_BUSY_STATUS) && (ElapsedTicks < TimeoutTicks)); 有什么办法解决这个问题吗？ Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered 嗨@zhangyu5454 请问是否已选中“I2C调试启用”选项？ 当 MCR[DBGEN] = 1 时，在调试 MCU 时，LPI2C 模块将继续工作。 当 MCR[DBGEN] = 0 时，在对应用程序进行编程并正常运行电路板（不连接调试器）后，LPI2C 应该能够按预期工作。 BR，VaneB Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered 嗨@zhangyu5454 下图供您参考： VaneB_0-1786396779346.png Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered 感谢您的回复。我使用 .mex 文件配置 i2c，如何设置才能控制 MCR[DBGEN] =1？ Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered 嗨@zhangyu5454 此选项已添加到最新RTD版本中，现在可以直接通过外设工具进行配置。 由于您使用的是较早的 RTD 版本，建议在应用程序代码中配置 MCR[DBGEN]。 Re: #S32K388 S32K388 LPI2C will stop when debug mode is entered zhangyu5454_0-1786418199524.png 我注意到我们的页面显示方式不同，我找不到这个选项，请注意我的版本是 RTD5.0。

Himiway：中置电机 vs 轮毂电机：优缺点 如果你正在选购电动自行车，那么最重要的决定之一就是在中置电机和轮毂电机之间做出选择。 两种设计方案没有绝对的优劣之分。中置电机特别擅长利用自行车的变速器来应对陡坡和技术地形，而轮毂电机则更简单、通常更实惠，并且需要的传动系统维护也更少。 对于许多日常骑行者来说，一款性能优良的轮毂电机就能提供绰绰有余的性能。对于经常需要应对陡峭山坡、山路或需要承载大量货物的骑行者来说，中置电机系统可能更有利。 以下是一个实际的比较。 中置电机与轮毂电机对比概览 特色中置电机轮毂电机 电机位置：曲柄/踏板附近，前轮或后轮轮毂 最适合山地、小径、技术性骑行、通勤、休闲、日常混合骑行 爬坡性能：优秀，具体取决于扭矩。 重量分布非常均衡，一个车轮的重量较大。 传动系统磨损较高 较低 维护方面更复杂，但通常更简单 补胎通常比较容易，但拆卸车轮可能比较困难。 踏板感觉通常非常自然，很大程度上取决于传感器的调校。 价格通常较高，但通常更实惠 什么是中置电机？ 中置电机位于五通附近，也就是脚踏板和曲柄组与车架连接的地方。 电机不是直接驱动车轮，而是通过自行车的传动系统传递动力。这意味着电机可以像骑手一样利用自行车的齿轮。 例如，在陡坡上换到较低的档位，电机就可以以更合适的速度运行，同时产生强大的爬坡辅助。 这正是中置电机系统在高性能电动山地自行车和其他专为崎岖地形设计的自行车上广受欢迎的最大原因。 中置电机的优点 1. 出色的爬坡性能 这或许是支持中置驱动器的最有力论据。 因为电机动力通过自行车的齿轮传递，所以爬坡时可以选择较低的档位。这样可以提高电机的运行效率，而不是强迫电机以非常低的转速拉动自行车上坡。 对于居住在丘陵地带的骑行者来说，这可能会产生明显的差异。 但是，不要以为所有中置电机都比所有轮毂电机爬坡性能更好。电机扭矩、控制器调校、骑手体重、齿轮比、轮胎尺寸和整车重量都很重要。 一款动力强劲的 750W 齿轮轮毂电机，扭矩大，在普通道路和中等难度的山路上仍然是一款优秀的爬坡电机。 2. 更佳的重量分布 中置电机将重量放置在自行车较低的位置，靠近中心。 这通常使自行车的操控性更加中性，因为前轮或后轮内没有集中的大型发动机。 在技术性山地自行车骑行、快速改变方向以及在不平坦的地形上骑行时，这种优势会变得尤为明显。 3. 电机功率的高效利用 由于电机可以利用自行车的齿轮，中置驱动系统可以使电机在更高效的转速范围内运行。 这可以提高频繁出现海拔变化的路线的效率。 但这并不意味着中置电机就一定拥有更长的续航里程。电池容量、速度、轮胎压力、骑行者体重、温度、海拔、风力和辅助级别都可能对实际续航里程产生更大的影响。 4. 自然踏板体验 许多高端中置电机系统都配备了扭矩传感器。 扭矩传感器测量你踩踏板的力度，并据此调整电机辅助力度。 付出更多努力，就能获得更多帮助。轻踩踏板，电机反应也会更柔和。 这种感觉与骑普通自行车非常相似——只是你的腿部力量突然增强了很多。 中置电机的缺点 1.传动系统磨损加剧 中置电机爬坡的优势也正是源于这一特性，而这一特性同时也造成了它最大的劣势之一。 骑手和电机都通过以下元器件传递动力： 链 链轮 磁带 变速器系统 电机扭矩过大，加上不良的换挡习惯，会加速传动系统的磨损。 如果在电机输出最大功率时频繁换挡，链条和飞轮齿的磨损速度可能会明显加快。 2. 更贵 中置驱动系统通常价格更高。 电机必须集成在曲柄区域周围，车架通常需要专门围绕该驱动装置进行设计。 对于主要在铺装路面或相对平缓的地形上行驶的骑行者来说，支付额外费用可能不会带来足够的实际好处。 3. 换挡技巧很重要 中置电机骑行者需要更仔细地考虑档位选择。 以非常高的档位起步爬陡坡，然后在发动机负荷较大的情况下换挡，这不是理想的做法。良好的骑行技巧包括在传动系统负荷过重之前选择合适的档位。 对于经验丰富的骑行者来说，这很快就会变得很自然。对于初学者来说，可能需要一段时间的学习。 4. 链条断裂可能会演变成更大的问题 由于中置电机通过链条传递电机动力，传动系统故障可能会导致电机无法驱动后轮。 配备油门的轮毂驱动自行车在这方面具有优势，因为它的电机独立于自行车链条运行。 什么是轮毂电机？ 轮毂电机直接安装在前轮或后轮的中心。 后轮毂电机在现代电动自行车上尤为常见。 电机不是通过链条和飞轮传递动力，而是直接驱动车轮旋转。这使得该系统在机械结构上变得简单，并将电机动力与传统的自行车传动系统分离。 Himiway的多款车型采用强大的轮毂驱动配置。Himiway D5 2.0 系列等自行车证明了轮毂电机在实用型胖胎电动自行车上仍然很受欢迎：它们可以将巨大的扭矩与相对简单的操作结合起来。 轮毂电机的优点 1. 简洁且维护成本低的设计 最大的优势之一就是简单易用。 电机通常不会通过自行车链条或飞轮传递动力。因此，你的传动系统只需要承受你的踩踏力，而不是你的踩踏力加上电机输出功率。 对于想要购买电动自行车用于通勤、周末骑行、办事或休闲娱乐的骑行者来说，这种简便性很有价值。 2. 日常表现优异 认为轮毂电机只适用于平坦道路的想法已经过时了。 现代齿轮轮毂电机可以产生相当大的扭矩。 例如，Himiway D5 2.0 使用 750W 齿轮轮毂电机，额定扭矩为 90 牛米。这种规格旨在提供强劲的加速性能和有效的爬坡辅助，而不是仅仅在平坦的自行车道上巡航。 D5 2.0 20" 结合了相同的总体理念，配备 20 英寸宽轮胎和全悬架，为骑手提供了一个以舒适性和操控性为核心的紧凑平台。 对于普通的山坡、居民区街道、碎石路和休闲小径，设计良好的轮毂电机完全能够胜任。 3. 更低的购买成本 对于制造商而言，轮毂电机通常结构更简单，成本也更低，更容易集成到电动自行车中。 这样一来，自行车预算中的更多资金就可以用于其他功能，例如： 更大的电池 液压制动器 更好的悬挂系统 集成照明 宽胎 更高的有效载荷能力 这也是轮毂电机自行车能够以非常优惠的价格提供极具吸引力的配置的原因之一。 4. 减轻链条和飞轮的压力 由于电机动力直接传递到车轮，链条无需传递电机的全部扭矩。 与动力强劲的中置电机自行车相比，这意味着传动系统元器件的使用寿命更长，前提是两辆自行车都得到妥善维护。 5. 油门操作可能很有用 在配备油门的兼容轮毂驱动电动自行车上，电机运行不一定取决于自行车传动系统。 从静止状态起步、短暂通过十字路口或载重时启动自行车，这会很方便。 它还提供了一个重要的机械优势：链条断裂不一定会阻止电机带动自行车运转。 轮毂电机的缺点 1. 在极端爬坡路段效率较低 传统的轮毂电机无法像中置电机那样充分利用自行车的飞轮。 在漫长而陡峭的爬坡过程中，电机可能被迫在重负荷下低速运转。 这会增加热量产生和能源消耗。 如果只是偶尔遇到小山坡，这可能影响不大。对于每天都要攀登陡峭山路的骑行者来说，这一点就显得更加重要了。 2. 后轮或前轮较重 电机给装有它的车轮增加了相当大的质量。 大多数动力强劲的电动自行车都使用后轮毂电机，因此在抬起或维修自行车时，自行车的后部可能会感觉更重。 你可能在扛着自行车上楼时比骑车时更容易注意到这一点。 3. 补胎可能更复杂 轮毂电机的车轮不像普通自行车车轮那样容易拆卸。 您可能需要断开电机电缆，并处理一个重量明显更重的车轮。 因此，对于轮毂驱动电动自行车来说，保持正确的胎压和使用防刺轮胎尤其重要。 Himiway电动自行车怎么样？ Himiway 电动自行车就是一个很好的例子，因为它的许多自行车都强调强大的轮毂驱动系统，而不是仅仅因为中置驱动听起来更高端就自动使用中置驱动。 Himiway D5、D5 Pro、D5 2.0、D5 2.0 ST、D5 2.0 Camo、D5 2.0 20"、C3、A7、A7 Pro、D7 和 D7 Pro 等车型针对不同类型的骑行，因此重点是要看整辆自行车，而不是仅仅根据发动机的位置来判断。 例如，考虑购买 D5 2.0 的骑手可能更关心强劲的扭矩、宽胎的牵引力、悬架的舒适性、续航里程和日常可靠性，而不是追求最轻的传动系统。 D5 2.0 20" 对于那些重视操控性和舒适性的骑手来说，它尤其具有吸引力。它较小的 20 英寸车轮、4 英寸轮胎、全悬架和低重心，与传统的大轮山地电动自行车相比，带来了截然不同的骑行体验。 与此同时，A7 和 A7 Pro 更适合那些优先考虑城市交通和日常实用性的骑行者。 而 C1 Kids 则属于完全不同的类别。对于年轻的骑手来说，操控性、合适的尺寸、速度控制、刹车和成人监督远比追求最大电机扭矩重要得多。 这凸显了一个重要的教训： 不要仅仅根据电机来选择电动自行车。 骑手们真正注意到的是什么 规格参数固然有用，但日常骑行往往会让这些差异变得简单得多。 一辆调校良好的轮毂电机自行车在日常通勤中通常会感觉毫不费力。你踩着踏板，救援人员赶到，你就可以继续前进，而无需时刻考虑档位。 一款好的中置电机往往会给那些积极使用变速档位的骑手带来回报。接近坡顶时，降档可以让发动机和骑手高效地协同工作。在复杂地形上，重心集中也能使自行车感觉更加平衡。 当你在平坦的自行车道上以中等速度骑行时，这种差异就不那么明显了。 因此，对于每个骑手来说，花更多的钱购买中置电机并不一定值得。 哪款发动机更适合爬坡？ 中置电机在爬坡时表现出色。 如果你的日常骑行包括漫长、陡峭的山路爬坡，那么中置电机利用自行车变速系统的能力就是一个很大的优势。 但“丘陵”和“极端丘陵”之间存在着重要的区别。 大多数人并非每天早上都要攀登山隘。 高扭矩齿轮轮毂电机能够很好地应对典型的社区山坡、起伏的乡村、碎石路和中等难度的山路爬坡。这就是为什么像 Himiway D5 2.0 这样的自行车对于那些想要爬坡能力但又不想升级到更昂贵的中置电机平台的骑手来说是一个不错的选择。 哪个更适合通勤？ 对于一般的通勤，我会认为轮毂电机更有优势。 它结构简单，价格相对便宜，对自行车传动系统造成的电机相关压力较小，并且为正常的城市骑行提供了足够的助力。 但是，如果你的通勤路线包含非常陡峭的地形，那么中途驾车就更具吸引力了。 哪款更适合山地自行车？ 对于高难度的技术型山地自行车骑行，我会选择中置电机。 电机居中位置改善了重量分布，同时方便调整自行车的变速装置，有助于在陡峭和技术性爬坡时获得更好的操控。 对于碎石路、林间小路、土路、露营旅行和难度相对较低的休闲步道来说，动力强劲的胖胎轮毂驱动自行车仍然是一个不错的选择。 哪个更适合初学者？ 对于许多初学者来说，轮毂电机驱动的电动自行车更合适。 无需过多考虑如何保持发动机处于正确的档位，传动系统的维护也很简单，而且价格通常也更亲民。 然而，电机类型并不是影响易用性的唯一因素。 车架几何形状、车轮尺寸、自行车重量、跨高、油门响应、扭矩或踏频感应、刹车和悬架等因素，对骑行者的信心会产生更大的影响。 中置电机 vs 轮毂电机：最终评测 没有绝对的赢家。 如果您符合以下条件，请选择中置电机： 经常攀登非常陡峭的山坡 骑行技术性强的山地车道 想要均衡的重量分布 偏爱自然、注重性能的骑行感受 不介意额外的传动系统维护 愿意支付更多费用 如果您符合以下条件，请选择轮毂电机： 通勤或休闲骑行 主要遇到平坦或略有起伏的地形 想要降低维护成本 想在预算范围内获得更高的性价比 倾向于选择机械结构更简单的系统 希望电机独立于自行车传动系统运行。 对于许多日常骑行者来说，优质的齿轮轮毂电机在动力、简易性、可靠性和价格方面提供了更好的平衡。设计合理的 750W 高扭矩轮毂驱动电动自行车，其性能远不止于平坦的城市街道。 当地形变得真正复杂时，中置电机就显得尤为重要。 所以，与其问“哪个电机更好？”，不如问： “我到底要去哪里骑这辆自行车呢？” 如果答案是陡峭的山路和艰险的攀登，那么请仔细研究一下中途驱动。如果是通勤、周末骑行、碎石路骑行、办事以及中等坡度的山路骑行，一辆好的轮毂电机电动自行车——例如 Himiway 产品线中的几款车型——可以满足您的所有需求，而无需为用不到的复杂功能买单。