Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Wi Fi CLIのOpen Thread CLIの問題 拝啓、 私たちはFRDM MCXW72を使ってOT-CLIエンドノードとして設定しています。 私たちは文書UG10349に記載されている手順を試しました。 ステップ5以降に進むことができません つまりスクリプトを実行して、すべてのサンプルをビルドしてください。 $ ./script/build_mcxw72 このコマンドの後。 解決に向けてご指導ください。 FRDMトレーニング Re: Issue with Wi Fi CLI Open Thread CLI こんにちは、 あなたの調子が良いといいのですが。MCXW72はWi-Fiをサポートしていないため、このMCUではWi-Fi CLIは動作しません。 どのリポジトリとリリースを使っているのか、教えていただけますか? よろしくお願いいたします。 リカルド Re: Issue with Wi Fi CLI Open Thread CLI こんにちは、 どのリポジトリとリリースを使っているのか、教えていただけますか? ログを見ると、Arm GCCコンパイラが見つからないためビルドが失敗しているようです。CMakeが使用しているコンパイラパスが無効であると思われます。これは、ツールチェーンパスの設定に問題があることを示唆しています。 ARMGCC_DIRの設定を確認し、arm-none-eabi-gccがその場所からインストールされアクセス可能であることを確認していただけますか?コンパイラが正しく検出されたら、ビルドは続行されます。 よろしくお願いいたします。 リカルド Re: Issue with Wi Fi CLI Open Thread CLI OT CLIにFRDM MCXW72を使用しようとしています。 Re: Issue with Wi Fi CLI Open Thread CLI 拝啓、 FRDM RW612でコードFRDMRW612_Wifi_IPv4_IPv6_Echoを試しています 添付ファイルに示すように、正常に動作するTCPサーバーでエコーを受信することができました。 現在、FRDMのポートGPIO 27に接続されたLEDONのコードを変更する作業を進めています Config Pin と socket_task.c ファイルの両方で関連する変更を試みました。 リセット後、ターミナルウィンドウに応答が表示されませんが、FRDMボード上の青色LEDが点灯しています。 問題の解決策をお知らせください。 コードのサイズが.zipファイルで50MBの制限を超えているため、コードを送信できません。 よろしくお願いします。 シーマ・ジョシ Re: Issue with Wi Fi CLI Open Thread CLI 拝啓、 Arm GCCのコンパイラパスはC:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10です。 CMAKEのコンパイラパスを設定する方法を教えてください。 また、以下の点についてもお知らせください。 ARMGCC_DIR設定を確認し、その場所からarm-none-eabi-gccがインストールされアクセス可能であることをどうやって確認すればいいですか? よろしくお願いします。 シーマ・ジョシ
記事全体を表示
需要RW612通过WiFi从移动设备控制照明的示例代码。 尊敬的先生, 我们有 FRDM-RW612,我们计划将 RW612 用作 WiFi 接收器,以接收来自移动 WiFi 的命令并控制照明。 请问您是否可以提供相关的示例代码? 此致 西玛·乔希 FRDM 培训 Re: Need sample code for lighting control from Mobile through WiFi for RW612. 你好, 希望你一切都好。我建议您查看我们不同代码库中提供的示例,例如我们的 SDK、Zephyr 和 Matter 代码库。 所有这些资源都可以与我们的MCUXpresso for Visual Studio Code | NXP 半导体一起使用。 此外,我建议您查看我们应用程序代码中心的其他演示应用程序。 顺祝商祺! 里卡多 Re: Need sample code for lighting control from Mobile through WiFi for RW612. 您好, 我可以给你推荐一个基础项目,你可以从那里开始。 对于带有 Wi-Fi 功能的 FRDM-RW612,一旦 Wi-Fi 接口启动,就可以使用Mongoose Networking Library作为 HTTP/WebSocket Web 服务器。 以下是使用 Mongoose Wizard 为 RW612 生成的 MCUXpresso + FreeRTOS 示例,您可以快速尝试: https://mongoose.ws/wizard/#/output?board=rw612-w&ide=MCUXpresso&rtos=FreeRTOS&file=README.md 这个例子是一个简单的网页仪表盘,但它已经通过 Wi-Fi + Mongoose 集成为你提供了一个坚实的起点。要下载它,请打开链接,转到“设置”选项卡,在“源代码生成器”部分选择本地目录,然后单击右上角的蓝色“生成 C/C++ 代码”按钮。然后使用 MCUXpresso 打开它。转到mongoose/mongoose_glue.h文件,更改 WIZARD_WIFI_NAME 和 WIZARD_WIFI_PASS 的值,以设置您的 Wi-Fi 凭据。然后,构建项目,将其烧录到开发板上,并观察串口日志,它应该会打印出一个 IP 地址。 对于您的照明控制应用程序,您可以添加 HTTP 端点或 WebSocket 处理程序,例如: GET /light/on GET /light/off 帖子/灯光 在这些处理程序中,调用您板级特定的 GPIO/PWM 控制照明代码。然后,移动应用程序可以通过 Wi-Fi 向这些端点发送命令。 Mongoose 的文档在这里。 友情提示:我是 Mongoose 开发团队的一员。希望这能帮到你。
記事全体を表示
TEA2016AAT TEA2016AATチップのデータシートには、RINGOソフトウェアの付録が含まれています。この付録には、Ringoパラメータ設定とICパラメータ設定が表形式で記載されています。データシートの 付録は 、 NXP Semiconductorsから入手できます。 このRingoファイルの付録を提供していただけますか? 71fa0bab2bc390474ac38057d2395563.png   ボードデザイン Re: TEA2016AAT こんにちは、ドンさん。 TEA2016AAT製品データシート(改訂版)の表8を参照してください。1.3 — 2024年1月12日): https://www.nxp.com/docs/en/data-sheet/TEA2016AAT.pdf BRs、トーマス
記事全体を表示
TJA1120A 製品データシートにおける1000BASET1から100BASET1への変換 製品データシートTJA1120A持っています。セクション7.2.1.10 BASE_T1_PMA_CONTROL レジスタには、1000BASET1 と 100BASET1 を選択するための 3:0 MODE があります。これはMMD1レジスタです。 このレジスターを使ってTJA1120Aを100BASET1にする方法を教えてもらえますか(少なくとも一時的には揮発性があります)。 Re: TJA1120A 1000BASET1 to 100BASET1 conversion in Product Datasheet こんにちは、 @vikyhre さん。 データシートに誤字があるようです。「アクセス・フォー・BASE_T1_PMA_CONTROL」です。MODEはR(読み取り専用)となります。TJA1120 1000BASE-T1のみをサポートしています。 よろしくお願いいたします。 パベル
記事全体を表示
Module selection for ADC application I would like to start developing an application around a MXP board, but I'm having trouble selecting a specific compute module I can use. I'm a bit overwhelmed by the variety and unsure about which products can actually do what I need. My understanding is that there are multiple SOCs that offer ADCs. I need something with higher compute power, and at least 4 ADC channels. Which specific development boards can I use, and which modules and boards can I use to build this application? Is there a supplier who can assist me selecting the specific boards I can purchase? Re: Module selection for ADC application I believe an MPU to ensure there's enough processing power, plus we are not so much worried about power consumption or cost. We are also interested in being able to use Profinet. And then it should have at least 4 ADC channels with more than 100ksps (per channel). My understanding is that an i.MX 9 MPU might fit. One alternative on my mind would be getting a Raspberry Pi Pico with a separate ADC module and Ethernet module. But I suspect an NXP system should be able to offer everything I need. But there's such a variety of products even if I settle for a specific chip, and it's often unclear if I'll get a suitable ADC, which is the most important feature of all for me. Re: Module selection for ADC application Hello, What are you looking for? is it an MCU? an MPU? We can help you with that if you can provide more information about the project. Also, we have a product search in the webpage https://www.nxp.com/design/design-center/development-boards-and-designs:EVDEBRDSSYS?collection=devBoardsDesigns&start=0&max=12&language=en&query=typeTax%3E%3Et633_t763 Best regards/Saludos, Aldo. Re: Module selection for ADC application Hello, Yes, any of the i.MX9 familly should be usable, it would depend of the graphics and other peripherals which one should be better on your use case. For this the i.MX91, i.MX93 & i.MX95 all three have FRDM boards and have the same specs on the ADC: • It includes eight channels, four of them connected to pins in the package. • Support the 1MS/s frequency of operation • Multiple modes of starting conversion (Normal, Injected) Normal mode supports One-Shot and Scan (continuous) conversion Injected mode supports One-Shot conversions only • Support TRGMUX to allow 16 trigger channels to be used by any ADC channel i.MX93 https://www.nxp.com/products/i.MX93 i.MX93 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 i.MX91 https://www.nxp.com/products/i.MX91 i.MX91 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91 i.MX95 https://www.nxp.com/products/i.MX95 i.MX95 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX95 Also, you may have a look the the EVKs for each one but as you have mentioned RPI I think the FRDM boards would be of interest for you. Best regards/Saludos, Aldo.
記事全体を表示
マイクロコントローラ の選び方は?位置制御のためにエンコーダー付きのモーターを3つ制御する必要があります。 ステッピングやBLDCモーター(+モータ・ドライバまたはESC)で、xyz軸方向の負荷(例えば約3kg)の位置を制御したいと考えています。フィードバックループ用のエンコーダーやセンサも追加したいと思っています。 そのため、適切なマイクロコントローラを選ぶのに苦労しました。ブランドについては、STM32かESP32のどちらかにしようと考えています。3つのモーターがあるため、3つのPWM出力信号が必要ですが、クロック周波数や外部部品の必要性など、その他の要件が満たされているかどうかをどのように判断すればよいでしょうか? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. こんにちは、 @pekomsさん MCXを選択する場合は、このプロジェクトではMCX A34x / A344~A346から始めてください。180 MHzのCortex-M33、2つのFlexPWM/eFlexPWMブロック、多数のPWM出力、ADC、タイマー、そしてエンコーダフィードバック用のハードウェア直交デコーダブロック2つを備えているため、3軸モーター制御に最も強力なMCX適合です。 カタログを精査した結果、この種のタスクに適したハイエンドMCXの主要候補として、MCX N94xとMCX A34xが浮上した。 BR ハリー
記事全体を表示
DMAモードでのSPI通信が失敗しました(S32k328) Rm_Init(&Rm_Config); 関数を呼び出した後、シリアルポート出力を試みるとハードウェアエラーが発生します。 Rm_Init(&Rm_Config) をコメントアウトして呼び出します。  ステータスは「ビジー」のままです。主要な初期化関数のみをリストアップしました。 if (Lpspi5_ready_flag == 0u) { spi_status = Lpspi_Ip_AsyncTransmit(&LPSPI5_EXTERNAL_DEVICE, &Spi5TxBuffer[0], &Spi5RxBuffer[0], NUMBER_OF_BYTES, Spi5_EndCallback); if (spi_status != LPSPI_IP_STATUS_SUCCESS) { printf("SpiTp: AsyncTransmit FAIL\r\n"); return; } } static void system_init(void) { /* Initialize Clock */ Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); /* Initialize all pins using the Port driver */ Siul2_Port_Ip_PortStatusType Status_Init_Port = SIUL2_PORT_ERROR; Status_Init_Port = Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); /* Initialize interrupt */ IntCtrl_Ip_Init(&IntCtrlConfig_0); /* Initialize Dma */ IntCtrl_Ip_EnableIrq(DMATCD0_IRQn); IntCtrl_Ip_EnableIrq(DMATCD1_IRQn); Dma_Ip_Init(&Dma_Ip_xDmaInitPB); Dma_Mux_Ip_Init(&Dma_Mux_Config); //Rm_Init(&Rm_Config); } /* Initialize each Spi hardware units using*/ Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_0_Instance_4); Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_1_Instance_5); Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_2_Instance_3); /* Update Framesize */ Lpspi_Ip_UpdateFrameSize(&LPSPI4_EXTERNAL_DEVICE, 8U); Lpspi_Ip_UpdateFrameSize(&LPSPI5_EXTERNAL_DEVICE, 8U); Lpspi_Ip_UpdateFrameSize(&LPSPI3_EXTERNAL_DEVICE, 8U); /* Update Transfered Bit order */ Lpspi_Ip_UpdateLsb(&LPSPI4_EXTERNAL_DEVICE, TRUE); Lpspi_Ip_UpdateLsb(&LPSPI5_EXTERNAL_DEVICE, TRUE); Lpspi_Ip_UpdateLsb(&LPSPI3_EXTERNAL_DEVICE, TRUE); /* Update Transfer Mode */ Lpspi_Ip_UpdateTransferMode(LPSPI4_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); Lpspi_Ip_UpdateTransferMode(LPSPI5_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); Lpspi_Ip_UpdateTransferMode(LPSPI3_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); /* SPI5 AsyncTransmit 完成回调 */ static void Spi5_EndCallback(uint8 Instance, Lpspi_Ip_EventType Event) { (void)Instance; if (Event == LPSPI_IP_EVENT_END_TRANSFER) { Spi5TransferOk = TRUE; Spi5TransferFault = FALSE; } else /* LPSPI_IP_EVENT_FAULT */ { Spi5TransferFault = TRUE; Spi5TransferOk = FALSE; } Spi5TransferDone = TRUE; } Re: SPI communication failed in DMA mode(S32k328) こんにちは、 @VaneB ご回答に基づき、 RM構成のDMAMUXソースをチャンネル16とチャンネル17に変更し、DMAも対応するチャンネル16とチャンネル17に設定しました。 1. コメントアウトしました Rm_Init(&Rm_Config); 予約する Dma_Mux_Ip_Init(&Dma_Mux_Config); 割り込みは正常に発生しました。 2. コメントアウトしました Dma_Mux_Ip_Init(&Dma_Mux_Config); 予約する Rm_Init(&Rm_Config); それでもハードウェアエラーが発生します。 今は正常に動作しています。この問題が解決すれば完璧です。本当にありがとうございました! BR、zyzzzz Re: SPI communication failed in DMA mode(S32k328) こんにちは@zyzzzz あなたの設定に関して、一つ気づいた点があります。LPSPI5をDMAを使用するように設定していますが、しかし、RM構成では、チャネル0とチャネル1に割り当てられたDMAのMUXソースはLPSPI_1に対応し、LPSPI_5に対応していません。 また、既に電話をかけている場合は、 Dma_Mux_Ip_Init(&Dma_Mux_Config); また、以下の番号に電話する必要はありません。 Rm_Init(&Rm_Config); あるいはその逆も然り。これは、Rm_Init() が内部的に以下の初期化シーケンスを実行するためです。 Rm_Init() └─ Rm_InitGroup1() └─ Rm_Ipw_Dma_Mux_Init() └─ Dma_Mux_Ip_Init() その結果、DMAマルチプレクサが2回初期化されることになる。初期化関数は1つだけにしておくことをお勧めします。 BR、VaneB Re: SPI communication failed in DMA mode(S32k328) こんにちは@zyzzzz DMAチャネルの設定はDMAMUX0を使っているのに気づきました。ただし、リファレンスマニュアルに付属するS32K3xx_DMAMUX_map.xlsxファイルを参照すれば、LPSPI_5 DMA要求がDMAMUX0ではなくDMAMUX1にマッピングされていることを確認できます。 DMAMUXインスタンス0ではなくインスタンス1を使用するように設定を更新してください。 Re: SPI communication failed in DMA mode(S32k328) こんにちは、 @VaneB ご返信ありがとうございます。おっしゃることは理解できますが、現時点ではDMAMUXインスタンス1を選択することはできません。 DMA_INSTANCE_0を選択してからDMAハードウェアチャネル16を選択すると、DMA MuxソースとしてDMA_MUX_1_LPSPI_5_TX_REQUESTを選択できます。
記事全体を表示
KW47におけるELEMUとLTCの比較:LTCには性能以外に何か利点があるのか? こんにちは。 KW47プラットフォーム上のELEMU(EdgeLockメッセージングユニットドライバー)とLTC(LP信頼暗号)の使用違いについてお聞きしたいです。 私の現在の理解は以下のとおりです。 エレム ・暗号処理は専用のセキュリティコアを要求することで行われ、鍵を隔離された安全な環境に保存できるため強力な改ざん耐性を提供します。 ・セキュリティコアとの通信が必要なため、非常に厳しいレイテンシ要件を持つアプリケーションには適さない場合があります。 ・LTCで利用可能なすべての暗号アルゴリズムをサポートし、さらにECDHなどLTCが扱えないアルゴリズムもサポートしています。 ・セキュリティ関連サービス(セキュアブート統合など)も利用可能です。 したがって、私の理解では、ELEMUは高度なセキュリティを必要とする暗号処理により適していると理解しています。 LTC ・暗号操作はLTCハードウェアアクセラレータレジスタを直接制御することで実行されるため、非常に低コストかつ高性能です。 ・対応アルゴリズムはAES、DES、ハッシュなどのハードウェアアクセラレーション関数に限定されています。 ・鍵は安全で隔離された環境に保管できないため、改ざん抵抗レベルはセキュリティコアが提供するものより低い。 したがって、私の理解ではLTCはレイテンシに敏感なプロセッシングやセッションキーのような一時キーを使ったユースケースにより適していると理解しています。 上記の理解が正しければ、LTCがELEMUに対して最大の利点はパフォーマンスやレイテンシであり、タイミング要件を満たせばLTCで実現できることはすべてELEMUを通じて実現できると言ってもよいでしょうか? あるいは、機能的な制限や対応アルゴリズム、ハードウェアアクセス制限、その他の考慮点で、LTCが特定のシナリオで好まれたり必須の選択肢になるのでしょうか? ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 あなたの調子が良いといいのですが。   ELEメッセージングユニット(ELE_MU)は、アプリケーションコアとEdgeLock Enclave(ELE)セキュリティコア間の通信メカニズムです。このインターフェースを通じて、ホストプロセッサはELEに暗号およびセキュリティ関連サービスを要求できます。暗号操作に加え、ELEは鍵生成、インポート/エクスポート、安全な鍵保存、非揮発性保存のための暗号化鍵ブロブ生成などの安全な鍵マネジメント機能を提供します。 より詳細な情報は KW47セキュリティリファレンスマニュアル 第9章に記載されています。 LTC(LP Trusted Cryptography)ドライバは、KW47ハードウェア暗号加速器への直接アクセスを提供します。この方法は、アプリケーションがELE_MUのようにセキュリティコアを通るのではなく、ハードウェアアクセラレータAPIと直接やり取りするため、ソフトウェアのオーバーヘッドが低減されます。LTCハードウェアはAES、DES、HASH、PKHAなどのアルゴリズムの加速をサポートしています。( KW47 APIリファレンス・マニュアルを参照) つまり、あなたの理解は概ね正しいですが、最終的には実装要件によります。低レイテンシと最小限のソフトウェアオーバーヘッドを主な目標にしているなら、長期介護(LTC)が望ましい選択肢です。しかし、セキュリティ境界やキーライフサイクル管理が重要な考慮事項であれば、一般的にELE_MUがより良い選択肢です。 よろしくお願いします、 ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 お返事ありがとうございます。 私の理解がおおむね正しいと分かって安心しました。 LTCとELE_MUのレイテンシの違いについてもう一つ質問があります。 実際の性能差は、使用されている暗号アルゴリズム、セキュリティコアとのやり取り回数、処理されるデータのサイズなどの要因によって異なると理解しています。具体的なユースケースの詳細な条件を提供できないため、予想されるレイテンシの違いの大まかなガイドラインや一般的な特徴を教えていただけるとありがたいです。 例えば、セキュリティコアとの通信のオーバーヘッドは通常、実際の暗号処理時間よりもはるかに大きく、その結果、LTCの数倍、あるいは数十倍の遅延が発生するのでしょうか? それとも、ほとんどの実用的なCASEでは、暗号処理時間自体が全体の実行時間を支配し、総処理時間の割合で見ると追加のオーバーヘッドは比較的小さくなELE_MUのでしょうか? ELE_MUのパフォーマンスへの影響が顕著になる時期を理解するためには、大まかなガイドラインや定性的な比較だけでも非常に役立つだろう。 ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 不便をおかけして申し訳ありません。現時点では、ELE_MUとLTCのレイテンシ差を比較したり定性的に説明したドキュメントが存在しません。 ELE暗号エンジンは速度よりも安全な実行を優先して最適化されていますが、具体的な性能指標については、特定の目標条件下でKW47ハードウェア上で直接測定することをお勧めします。 KW47におけるELE機能や暗号操作に関しては、最も関連するガイダンスがKW47セキュリティリファレンスマニュアルに記載されています。 よろしくお願いします、 アナ・ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 ご回答ありがとうございます。 ELE_MUとLTCのレイテンシを比較したり、レイテンシー特性を定性的に説明したりするドキュメントは存在しないことは理解しています。 その場合は、実際のKW47ハードウェアでの性能を評価し、レイテンシを直接測定して両実装の違いをよりよく理解します。 ご協力ありがとうございました。 よろしくお願いします、
記事全体を表示
S32G 支持 4 个以太网 MAC MDIO 接口 你好, 根据 tr651601 - S32G2 Ethernet (0.1).pdf • S32G 支持 4 倍以太网 MAC − 3X 与数据包转发引擎 (PFE) 集成 − 1X 作为独立组网 \\(SA\\) 以太网控制器 (GMAC) 我的问题是,4X MAC 的所有 MDIO 接口是否都支持 Clause 45? 谢谢~ 莫里斯 Re: S32G supports 4X Ethernet MACs MDIO interface @Bulat 感谢您的支持! 莫里斯 Re: S32G supports 4X Ethernet MACs MDIO interface 是的,每个 MDIO 接口都支持第 45 条。 此致, 布拉特
記事全体を表示
Gui_GuiderはCコード生成時にフリーズする場合があります。 フォントファイルをインポートした後、生成されるCコードが途中で止まってしまいます。ページを単一サイズに縮小し、アイコンを削除してシンプルなインターフェースを作成しても、「Cコードを生成中」の状態のまま止まってしまいます。 Re: Gui_Guider在生成C code时会出现卡死的情况 Gui_Guiderに新しいフォントを直接インポートすると、Cコードの生成処理がフリーズしてしまうという問題が見つかりました。この問題を解決するにはどうすればよいでしょうか? 回复: Gui_Guider在生成C code时会出现卡死的情况 こんにちは、 @vettleさん インポートされたフォントを教えていただけますか? フォントを変更した場合も、この問題は発生しますか? BR ハリー
記事全体を表示
如何选择微控制器?需要使用编码器控制3个电机进行位置控制。 我希望使用步进电机或无刷直流电机(+驱动器或电调)来控制负载(假设约为 3 公斤)在 xyz 轴上的位置。我还想添加编码器或一些传感器用于反馈回路。 基于此,我很难选择合适的微控制器。我当时考虑的是STM32或者ESP32作为品牌。它需要 3 个 PWM 输出信号(因为有 3 个电机),但我如何知道其他方面是否足够,例如时钟频率、是否需要外部元器件等等? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. 嗨@pekoms 对于 MCX 选择,本项目建议首先选择 MCX A34x / A344–A346。它是最适合三轴电机控制的 MCX,因为它具有 180 MHz Cortex-M33、两个 FlexPWM/eFlexPWM 模块、多个 PWM 输出、ADC、定时器和两个用于编码器反馈的硬件正交解码器模块。 目录浏览还发现 MCX N94x 和 MCX A34x 是此类任务的主要高端 MCX 候选产品。 BR 哈里
記事全体を表示
TEA2016AAT The TEA2016AAT chip datasheet includes a RINGO software appendix: The TEA2016AAT datasheet appendix provides Ringo parameter settings/IC parameter settings in tabular form. The datasheet appendix can be obtained from NXP Semiconductors. Could you provide the appendix for this Ringo file? 71fa0bab2bc390474ac38057d2395563.png   Board Design Re: TEA2016AAT Hi Dong, Please refer to the Table 8 in the TEA2016AAT product data sheet (Rev. 1.3 — 12 January 2024): https://www.nxp.com/docs/en/data-sheet/TEA2016AAT.pdf BRs, Tomas
記事全体を表示
KW47 上的 ELEMU 与 LTC:除了性能之外,LTC 还有其他优势吗? 你好。 我想了解 KW47 平台上 ELEMU(EdgeLock 消息单元驱动程序)和 LTC(LP 可信加密)在使用上的区别。 我目前的理解如下: ELEMU ・通过请求专用网络安全核心来执行加密操作,由于密钥可以存储在隔离的安全环境中,因此具有很强的防篡改能力。 ・由于需要与安全核心进行通信,因此可能不适合对延迟要求非常严格的应用程序。 ・它支持 LTC 提供的所有加密算法,并且还支持 LTC 无法处理的算法,例如 ECDH。 ・还可以利用安全启动集成等安全相关服务。 因此,我的理解是,ELEMU 更适合需要高安全性的加密操作。 长期护理 ・通过直接控制 LTC 硬件加速器寄存器来执行加密操作,从而实现极低的开销和高性能。 ・支持的算法仅限于硬件加速函数,例如 AES、DES、HASH 等。 ・钥匙无法存放在安全的隔离环境中,因此其防篡改能力低于安全核心所提供的防篡改能力。 因此,我的理解是,LTC 更适合对延迟敏感的处理或涉及临时密钥(如会话密钥)的使用场景。 如果上述理解正确,那么是否可以说 LTC 相对于 ELEMU 的主要优势在于性能/延迟,并且如果能够满足时间要求,那么 LTC 可以完成的所有事情也可以通过 ELEMU 完成? 或者,是否存在某些功能限制、支持的算法、硬件访问限制或其他因素,使得 LTC 在某些情况下成为首选或必需的选择? 感谢您事先的指导。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? 你好, 希望你一切都好。   ELE 消息单元 (ELE_MU) 是应用核心与 EdgeLock Enclave (ELE) 安全核心之间的通信机制。通过此接口,主机处理器可以向 ELE 请求加密和安全相关的服务。除了加密操作外,ELE 还提供安全的密钥管理功能,包括密钥生成、导入/导出、安全密钥存储以及为非易失性存储生成加密密钥块。 更多详细信息请参阅KW47 网络安全参考手册第 9 章。 LTC(LP 可信加密)驱动程序提供对 KW47 硬件加密加速器的直接访问。这条路径提供了更低的软件开销,因为应用程序直接与硬件加速器 API 交互,而不是像 ELE_MU 那样通过安全核心进行通信。LTC 硬件支持加速 AES、DES、HASH 和 PKHA 等算法。(参见KW47 API参考手册) 所以你的理解总体上是正确的,最终取决于你的具体实施需求。如果低延迟和最小的软件开销是您的主要目标,那么 LTC 将是首选方案。但如果网络安全边界和密钥生命周期管理是重要的考虑因素,那么 ELE_MU 通常是更好的选择。 此致, 索菲亚。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? 嗨,索菲亚, 感谢你的回复。 很高兴得知我的理解总体上是正确的。 关于 LTC 和 ELE_MU 之间的延迟差异,我还有一个问题。 我理解实际性能差异取决于所使用的加密算法、与安全核心的交互次数以及正在处理的数据大小等因素。由于我无法提供具体用例的详细条件,因此,即使只是一个粗略的指导原则或对预期延迟差异的一般性描述,我也希望得到。 例如,与网络安全核心通信的开销是否通常比实际的加密处理时间大得多,从而导致延迟比 LTC 高出几倍甚至几十倍? 或者,在大多数实际应用场景中,加密处理时间本身是否会占据整个执行时间的大部分,使得 ELE_MU 引入的额外开销相对于总处理时间的百分比而言较小? 即使是高层次的指导原则或定性比较,对于了解 ELE_MU 何时会对性能产生显著影响也十分有帮助。 感谢您事先的指导。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? 你好, 对于由此造成的不便,我深表歉意。目前尚无任何文档提供对 ELE_MU 和 LTC 之间延迟差异的比较或定性指导。 虽然 ELE 加密引擎针对安全执行而非速度进行了优化,但对于具体的性能指标,建议在特定目标条件下对 KW47 硬件进行直接测量。 关于 KW47 上的 ELE 功能或加密操作,最相关的指导可在 KW47 安全参考手册中找到。 此致, 安娜·索菲亚。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? 你好,索菲亚, 感谢您的回复。 我知道目前没有可用的文档来比较 ELE_MU 和 LTC 的延迟,也没有定性地描述它们的延迟特性。 在这种情况下,我将在实际的 KW47 硬件上评估性能,并直接测量延迟,以便更好地了解两种实现方式之间的差异。 再次感谢您的帮助。 此致,
記事全体を表示
S32Gは4XイーサネットMACのMDIOインターフェースをサポートしています こんにちは、 tr651601によると、S32G2イーサネット(0.1).pdf • S32Gは4XイーサネットMACをサポートしています − パケット転送エンジン(PFE)と3x統合 − スタンドアロンイーサネットコントローラ(GMAC)としての1X 質問ですが、4X MACのMDIOインターフェース全体が45条をサポートできるのでしょうか? ありがとう~ モリス Re: S32G supports 4X Ethernet MACs MDIO interface @Bulat サポートありがとうございます!! モリス Re: S32G supports 4X Ethernet MACs MDIO interface はい、各MDIOインターフェースは第45条をサポートしています。 よろしくお願いいたします。 ブラート
記事全体を表示
Wi-Fi CLI 问题(开放主题 CLI) 尊敬的先生, 我们使用 FRDM MCXW72 配置为 OT-CLI 终端节点。 我们按照文件 UG10349 中的方法进行了尝试。 第五步之后,我们无法继续进行下去。 IE运行脚本以版本所有示例。 $ ./script/build_mcxw72 执行此命令后。 请指导解决。 FRDM 培训 Re: Issue with Wi Fi CLI Open Thread CLI 你好, 希望你一切都好。MCXW72 不支持 Wi-Fi,因此任何 Wi-Fi CLI 都无法在该 MCU 上运行。 请问您使用的是哪个代码库和版本? 顺祝商祺! 里卡多 Re: Issue with Wi Fi CLI Open Thread CLI 我们正在尝试使用 FRDM MCXW72 进行 OT CLI。 Re: Issue with Wi Fi CLI Open Thread CLI 尊敬的先生, 我们正在 FRDM RW612 上尝试代码 FRDMRW612 _Wifi_IPv4_IPv6_Echo 这是正常工作的 TCP 服务器,我们能够获取到附件中的回显信息。 现在我们正在修改代码,以控制连接到 FRDM 芯片 GPIO 27 端口的 LED 灯亮起。 我尝试在 Config Pin 以及 socket_task.c 文件中进行相关更改。 我们发现 RESET 后终端窗口没有响应,但 FRDM 板上的蓝色 LED 灯亮着。 请告知问题的解决方案。 由于.zip文件大小超过了50Mb的限制,我们无法发送该代码。 此致 西玛·乔希 Re: Issue with Wi Fi CLI Open Thread CLI 您好, 请问您使用的是哪个代码库和版本? 日志显示构建失败,因为找不到 Arm GCC 编译器。CMake 使用的编译器路径似乎无效,这表明工具链路径配置存在问题。 请您检查一下您的 ARMGCC_DIR 配置,并确认 arm-none-eabi-gcc 是否已安装并可从该位置访问?一旦正确检测到编译器,版本就应该继续进行。 此致, 里卡多 Re: Issue with Wi Fi CLI Open Thread CLI 尊敬的先生, Arm GCC 编译器路径为 C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10 请与我们联系如何为 CMAKE 设置编译器路径。 另外,请与我们联系 如何验证 ARMGCC_DIR 配置并确认 arm-none-eabi-gcc 已安装并可从该位置访问? 此致 西玛·乔希
記事全体を表示
Issue with Wi Fi CLI Open Thread CLI Dear Sir, We are using FRDM MCXW72 , to configure as OT-CLI  End node. We tried the procedure as per document UG10349. We are not able to go ahed after the step 5  i.e. Run the scripts to build all examples. $ ./script/build_mcxw72 after this command. Please guide resolve. FRDM-Training Re: Issue with Wi Fi CLI Open Thread CLI Hello, Hope you are doing well. MCXW72 does not support Wi-Fi, so no Wi-Fi CLI can work on this MCU. Could you please clarify what repository and release are you using? Best Regards, Ricardo Re: Issue with Wi Fi CLI Open Thread CLI Hi, Could you please clarify what repository and release are you using? The log indicates that the build is failing because the Arm GCC compiler cannot be found. The compiler path being used by CMake appears to be invalid, which suggests a toolchain path configuration issue. Could you please verify your ARMGCC_DIR configuration and confirm that arm-none-eabi-gcc is installed and accessible from that location? Once the compiler is correctly detected, the build should proceed further. Regards, Ricardo Re: Issue with Wi Fi CLI Open Thread CLI We are trying to use FRDM MCXW72 for OT CLI. Re: Issue with Wi Fi CLI Open Thread CLI Dear Sir, We are trying  code FRDMRW612 _Wifi_IPv4_IPv6_Echo on FRDM RW612 Its working TCP server we are able to get the echo as per attached. Now we are working to modify code for LED ON connected on port  GPIO 27 on FRDM Tried to do related changes in Config Pin as well as in the file socket_task.c We found the responce  is not coming on the terminal window after reset  but  Blue LED is glowing on FRDM board. Please communicate the resolution on the issue. We are not able to send the code as code size .zip is extending limit of 50Mb. Regards Seema Joshi Re: Issue with Wi Fi CLI Open Thread CLI Dear Sir, Arm GCC compiler   path is  C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10 Please let us know how to set compiler path for CMAKE. Also please let us know about  how to verify ARMGCC_DIR configuration and confirm that arm-none-eabi-gcc is installed and accessible from that location? Regards Seema Joshi
記事全体を表示
ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi. I would like to ask about the differences in usage between ELEMU (EdgeLock Messaging Unit Driver) and LTC (LP Trusted Cryptography) on the KW47 platform. My current understanding is as follows: ELEMU ・Cryptographic operations are performed by requesting the dedicated Security Core, providing strong tamper resistance because keys can be stored in an isolated secure environment. ・Since communication with the Security Core is required, it may not be suitable for applications with very strict latency requirements. ・It supports all cryptographic algorithms available through LTC, and additionally supports algorithms that LTC cannot handle, such as ECDH. ・Security-related services such as secure boot integration can also be utilized. Therefore, my understanding is that ELEMU is better suited for cryptographic operations that require a high level of security. LTC ・Cryptographic operations are executed by directly controlling the LTC hardware accelerator registers, resulting in very low overhead and high performance. ・Supported algorithms are limited to hardware-accelerated functions such as AES, DES, HASH, etc. ・Keys cannot be stored in a secure isolated environment, so the level of tamper resistance is lower than that provided by the Security Core. Therefore, my understanding is that LTC is better suited for latency-sensitive processing or use cases involving temporary keys such as session keys. If the above understanding is correct, is it fair to say that the primary advantage of LTC over ELEMU is performance/latency, and that if timing requirements can be met, everything that can be accomplished with LTC can also be accomplished through ELEMU? Or are there any functional limitations, supported algorithms, hardware access restrictions, or other considerations that would make LTC the preferred or required choice in certain scenarios? Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, Hope you are doing well.   The ELE Messaging Unit (ELE_MU) is a communication mechanism between the application core and the EdgeLock Enclave (ELE) security core. Through this interface, the host processor can request cryptographic and security-related services from ELE. In addition to cryptographic operations, ELE provides secure key management capabilities, including key generation, import/export, secure key storage, and encrypted key blob generation for non-volatile storage. More detailed information can be found in KW47 Security Reference Manual Chapter 9. The LTC (LP Trusted Cryptography) driver provides direct access to the KW47 hardware cryptographic accelerator. This path offers lower software overhead because the application interacts directly with the hardware accelerator APIs rather than communicating through the security core like ELE_MU. The LTC hardware supports acceleration for algorithms such as AES, DES, HASH, and PKHA. (See KW47 API Reference Manual) So your understanding is generally correct, it will ultimately depend on your implementation requirements. If low latency and minimal software overhead are your primary goals, LTC would be the preferred option. But if security boundaries and key lifecycle management are important considerations, ELE_MU is generally the better choice. Best regards, Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your reply. I am glad to know that my understanding is generally correct. I have one additional question regarding the latency difference between LTC and ELE_MU. I understand that the actual performance difference depends on factors such as the cryptographic algorithm being used, the number of interactions with the Security Core, and the size of the data being processed. Since I am not able to provide detailed conditions for a specific use case, I would appreciate even a rough guideline or general characterization of the expected latency difference. For example, is the overhead of communicating with the Security Core typically much larger than the actual cryptographic processing time, resulting in latency that is several times or even tens of times higher than LTC? Or, in most practical use cases, does the cryptographic processing time itself dominate the overall execution time, making the additional overhead introduced by ELE_MU relatively small when viewed as a percentage of the total processing time? Even a high-level guideline or qualitative comparison would be very helpful for understanding when the performance impact of ELE_MU becomes significant. Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, I apologize for the inconveniences, currently there is no available documentation that provides a comparison or qualitative guideline characterizing the latency difference between ELE_MU and LTC. While the ELE cryptographic engines are optimized for secure execution rather than speed, for specific performance metrics, direct measurement on KW47 hardware under the specific target conditions would be recommended. Regarding ELE functionality or cryptographic operations on KW47, the most relevant guidance is provided in the KW47 Security Reference Manual. Best regards, Ana Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your response. I understand that there is no available documentation that compares the latency of ELE_MU and LTC or describes their latency characteristics qualitatively. In that case, I will evaluate the performance on actual KW47 hardware and measure the latency directly to gain a better understanding of the differences between the two implementations. Thank you again for your help. Best regards,
記事全体を表示
How to choose a microcontroller? Need to control 3 motors with encoders for position control. Im looking to control the position of a load (lets say around 3 kg) in xyz axis with either steppers or BLDC motors (+Drivers or ESC). I want to add encoders as well or some sensors for feedback loop. Based on that, I struggled to pick an appropriate microcontroller. I was thinking either STM32 or ESP32 for the brand. It requires 3 PWM output signals (since 3 motors), but how do I know if everything else is enough like the frequency of the clock, do I need external components, etc? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. Hi @pekoms  For an MCX choice, start with MCX A34x / A344–A346 for this project. It is the strongest MCX fit for 3-axis motor control because it has a 180 MHz Cortex‑M33, two FlexPWM/eFlexPWM blocks, many PWM outputs, ADCs, timers, and two hardware quadrature decoder blocks for encoder feedback. A catalog pass also surfaced MCX N94x and MCX A34x as the main higher-end MCX candidates for this class of task. BR Harry
記事全体を表示
SPI communication failed in DMA mode(S32k328) A hardware error will occur when serial port output is attempted after calling the Rm_Init(&Rm_Config); function. Comment out Rm_Init(&Rm_Config) and call  The status remains busy; I have only listed the key initialization functions. if (Lpspi5_ready_flag == 0u) { spi_status = Lpspi_Ip_AsyncTransmit(&LPSPI5_EXTERNAL_DEVICE, &Spi5TxBuffer[0], &Spi5RxBuffer[0], NUMBER_OF_BYTES, Spi5_EndCallback); if (spi_status != LPSPI_IP_STATUS_SUCCESS) { printf("SpiTp: AsyncTransmit FAIL\r\n"); return; } } static void system_init(void) { /* Initialize Clock */ Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); /* Initialize all pins using the Port driver */ Siul2_Port_Ip_PortStatusType Status_Init_Port = SIUL2_PORT_ERROR; Status_Init_Port = Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); /* Initialize interrupt */ IntCtrl_Ip_Init(&IntCtrlConfig_0); /* Initialize Dma */ IntCtrl_Ip_EnableIrq(DMATCD0_IRQn); IntCtrl_Ip_EnableIrq(DMATCD1_IRQn); Dma_Ip_Init(&Dma_Ip_xDmaInitPB); Dma_Mux_Ip_Init(&Dma_Mux_Config); //Rm_Init(&Rm_Config); } /* Initialize each Spi hardware units using*/ Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_0_Instance_4); Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_1_Instance_5); Lpspi_Ip_Init(&Lpspi_Ip_PhyUnitConfig_SpiPhyUnit_2_Instance_3); /* Update Framesize */ Lpspi_Ip_UpdateFrameSize(&LPSPI4_EXTERNAL_DEVICE, 8U); Lpspi_Ip_UpdateFrameSize(&LPSPI5_EXTERNAL_DEVICE, 8U); Lpspi_Ip_UpdateFrameSize(&LPSPI3_EXTERNAL_DEVICE, 8U); /* Update Transfered Bit order */ Lpspi_Ip_UpdateLsb(&LPSPI4_EXTERNAL_DEVICE, TRUE); Lpspi_Ip_UpdateLsb(&LPSPI5_EXTERNAL_DEVICE, TRUE); Lpspi_Ip_UpdateLsb(&LPSPI3_EXTERNAL_DEVICE, TRUE); /* Update Transfer Mode */ Lpspi_Ip_UpdateTransferMode(LPSPI4_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); Lpspi_Ip_UpdateTransferMode(LPSPI5_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); Lpspi_Ip_UpdateTransferMode(LPSPI3_EXTERNAL_DEVICE.Instance, LPSPI_IP_INTERRUPT); /* SPI5 AsyncTransmit 完成回调 */ static void Spi5_EndCallback(uint8 Instance, Lpspi_Ip_EventType Event) { (void)Instance; if (Event == LPSPI_IP_EVENT_END_TRANSFER) { Spi5TransferOk = TRUE; Spi5TransferFault = FALSE; } else /* LPSPI_IP_EVENT_FAULT */ { Spi5TransferFault = TRUE; Spi5TransferOk = FALSE; } Spi5TransferDone = TRUE; } Re: SPI communication failed in DMA mode(S32k328) Hi, @VaneB Based on your reply, I changed the RM configuration DMAMUX source to channel 16 and channel 17, and the DMA is also set to the corresponding channel 16 and channel 17. 1. I commented out Rm_Init(&Rm_Config); reserve Dma_Mux_Ip_Init(&Dma_Mux_Config); The interrupt was triggered normally. 2. I commented out Dma_Mux_Ip_Init(&Dma_Mux_Config); reserve Rm_Init(&Rm_Config); It will still trigger a hardware error. It's working properly now. It would be perfect if this problem could be solved. Thank you so much! BR, zyzzzz Re: SPI communication failed in DMA mode(S32k328) Hi @zyzzzz  I have an observation regarding your configuration. You have configured LPSPI5 to use DMA; however, in the RM configuration, the DMA MUX sources assigned to Channel 0 and Channel 1 correspond to LPSPI_1, not LPSPI_5.  Also, if you are already calling: Dma_Mux_Ip_Init(&Dma_Mux_Config); there is no need to also call: Rm_Init(&Rm_Config); Or vice versa. This is because Rm_Init() internally performs the following initialization sequence: Rm_Init() └─ Rm_InitGroup1() └─ Rm_Ipw_Dma_Mux_Init() └─ Dma_Mux_Ip_Init() As a result, the DMA MUX is being initialized twice. I would recommend keeping only one initialization function.  BR, VaneB Re: SPI communication failed in DMA mode(S32k328) Hi @zyzzzz  I noticed that you are configuring the DMA channels using DMAMUX0. However, if you refer to the S32K3xx_DMAMUX_map.xlsx file included with the Reference Manual, you can verify that the LPSPI_5 DMA request is mapped to DMAMUX1, not DMAMUX0. Please update the configuration to use DMAMUX instance 1 instead of instance 0. Re: SPI communication failed in DMA mode(S32k328) Hi, @VaneB I'm glad to receive your reply. I understand what you mean, but DMAMUX instance 1 cannot be selected at this time. If you select DMA_INSTANCE_0 and then select DMA Hardware Channel 16, you can select DMA Mux Source as DMA_MUX_1_LPSPI_5_TX_REQUEST.
記事全体を表示
TEA2016AAT TEA2016AAT芯片手册,上面的RINGO软件附录介绍:TEA2016AAT 数据手册附录以表格形式给出了 Ringo 参数设置 /IC 参数设置。数据手册附录可向恩智浦半导体公司索取 能提供一下这个ringo的附录吗??? 71fa0bab2bc390474ac38057d2395563.png   Board Design Re: TEA2016AAT 嗨,董, 请参阅 TEA2016AAT 产品数据手册(修订版)中的表 8。1.3 — 2024 年 1 月 12 日): https://www.nxp.com/docs/en/data-sheet/TEA2016AAT.pdf BRs,托马斯
記事全体を表示