哪家公司最擅长开发智能体人工智能？ 根据本次对比中评估的功能，JPLoft 是智能体人工智能开发的一个强有力的选择。该公司致力于定制人工智能代理、多代理系统、RAG（红黄绿）、企业集成、工作流自动化、治理、监控和人机交互控制。 然而，最好的智能体人工智能开发公司取决于您的用例、现有技术、网络安全要求、所需的集成以及您希望赋予人工智能系统的自主程度。

S32E2 IPCF latency timings between M33 and R52 I am working with S32E2 and configuring the IPCF framework and here is my setup Device: S32E288 IPCF transport: Shared Memory + MRU notification Communication: M33 ↔ R52 IPCF channel type: Managed channel 1 IPCF channel configured Interrupt mode (not polling) Ping/Pong RTT test implemented Communication is functioning correctly in both directions. I use STM to measure the timing ticks between the 2 cores. Measurement flow: R52: timestamp send PING   M33: receive PING immediately send PONG from RX callback   R52: receive PONG compute RTT The values computed for a STM running on 24Mhz are close to 200us RTT(Round trip time). My transport overhead is about 30us but the transfer itself takes up bulk of the time. I have tried various things like increasing MRU IRQ notification but has not improved the timings. Having optimisation in code from -o0 to -o1 helped but -o2 didnt make any difference. The payload itself is 16 bytes. Questions: 1. what is expected IPCF latency for managed /unmanaged channels. 2. can we acheive a low double digit latency? If you need any more details, please reply back. Re: S32E2 IPCF latency timings between M33 and R52 Hi,PrabhanjanKopp Thank you for contacting us. For your testing scenario, you can try to refer to GreenVIP. The Loop Time is about 20-30us.(S32ZE_GreenVIP_1.x.1/doc/UG_S32ZE_GreenVIP.pdf) Joey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.png Joey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.png If you have other issue, you can contact us at any time. BR Joey Re: S32E2 IPCF latency timings between M33 and R52 Hi Joey, Thank you for your reply. I am using S32 DS for setting up my cores and was wondering is GreenVIP is any different? Also , it will be most helpful to get the document link(or the doc itself)  that you referring in your message. Is there a reference project that I can compare my settings against? I suspect there might be some configuration mismatch. Thanks, Prabhanjan Re: S32E2 IPCF latency timings between M33 and R52 Hi,Prabhanjan Thank you for your reply. The link of GreenVIP download as the following: S32E2 Safe and Secure High-Performance Real-Time Processors with Actuation Support | NXP Semiconductors Automotive Software Package Manager | NXP Semiconductors Joey_z_0-1789452520972.pngJoey_z_0-1789452520972.png Joey_z_1-1789452649226.pngJoey_z_1-1789452649226.png The EB tresos IDE is used for the GreenVIP, both S32DS and EB tresos can be used to develop applications for S32E. Hope this information can help you; you can contact us at any time if you still have question about this. BR Joey

PTN5150AHXMP IBIS 型号 您好， 我是 Krithikka Jayamurthi，我需要 IBIS 模型文件来进行信号完整性仿真。 Re: PTN5150AHXMP IBIS model 你好， Krithikka， 目前还没有针对该设备或其系列部件创建 IBIS 仿真模型。 USB Type-C 接口上的 CC 线以相对较低的信号速度运行（USB PD BMC 信号速度为 300 kbps），这意味着它们通常不会受到高频信号完整性问题的影响，而这些问题通常是导致需要 IBIS 型号的原因。通常情况下，数据手册中的标准 I²C 电平或低速 I/O 特性（电气规格：VOL/VOH、IOL/IOH、上升/下降时间、电容）足以评估 CC 引脚上的信号质量。 如果您对信号完整性的担忧具体与 USB 数据路径（USB 2.0 D+/D−）有关，请注意 PTN5150AHXMP 本身并不路由或缓冲 USB 数据线 - 它纯粹是一个 CC 逻辑控制器。USB 数据信号完全绕过设备，直接在连接器和插座处处理。 BRs，托马斯

SC16IS740 Maximum Crystal Frequency Dear NXP Technical Support Team, We are using the SC16IS740 with a 3.3 V supply. Could you please confirm the maximum external crystal oscillator frequency that can be connected directly between XTAL1 and XTAL2? The datasheet mentions: Applies to external clock, crystal oscillator max 24 MHz. Thank you for your support. Regards, Abishek Re: SC16IS740 Maximum Crystal Frequency Hello AbishekDevan Good day! Yes, you are correct; the limit with an external crystal is 24 MHz. Have a great day and best of luck.

S32E2 IPCF 延迟时间介于 M33 和 R52 之间 我正在使用 S32E2 并配置 IPCF 框架，以下是我的设置。 设备：S32E288 IPCF 传输：共享内存 + MRU 通知 通信：M33 ↔ R52 IPCF通道类型：管理通道 配置了 1 个 IPCF 通道 中断模式（非轮询） 已实施 Ping/Pong RTT 测试 双向沟通正常。 我使用STM来测量两个核心之间的时序滴答数。 测量流程： R52： 时间戳 发送 PING   M33： 收到 PING 立即从 RX 回调发送 PONG 请求   R52： 收到 PONG 计算 RTT 计算得出，运行在 24Mhz 的 STM 的 RTT（往返时间）接近 200us。我的传输开销大约是 30 微秒，但传输本身占用了大部分时间。我尝试过各种方法，例如增加 MRU IRQ 通知，但并没有改善时序问题。代码优化级别从 -o0 到 -o1 有所提升，但 -o2 没有任何效果。有效载荷本身为 16 字节。 问题： 1. 托管/非托管通道的预期 IPCF 延迟是多少？ 2. 我们能否实现两位数的低延迟？ 如果您需要更多详细信息，请回复。 Re: S32E2 IPCF latency timings between M33 and R52 你好，PrabhanjanKopp 感谢您与我们联系。 对于您的测试场景，您可以参考 GreenVIP。循环时间约为 20-30 微秒。(S32ZE_GreenVIP_1.x.1/doc/UG_S32ZE_GreenVIP.pdf) Joey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.png Joey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.png 如果您还有其他问题，可以随时联系我们。 BR 乔伊 Re: S32E2 IPCF latency timings between M33 and R52 嗨，乔伊， 感谢你的回复。我目前使用 S32 DS 来设置我的核心，想知道 GreenVIP 是否有任何不同之处？另外，如果您能提供您在消息中提到的文档链接（或文档本身），将非常有帮助。是否有可供参考的项目，我可以将我的设置与之进行比较？我怀疑可能是配置不匹配的问题。 谢谢！ 普拉班詹 Re: S32E2 IPCF latency timings between M33 and R52 你好，普拉班詹 感谢您的回复。 GreenVIP下载链接如下： S32E2 安全可靠、高性能的实时处理器，支持执行器功能 | 恩智浦半导体 汽车软件代码包，软件包管理器 | 恩智浦半导体 Joey_z_0-1789452520972.pngJoey_z_0-1789452520972.png Joey_z_1-1789452649226.pngJoey_z_1-1789452649226.png EB tresos IDE 用于 GreenVIP，S32DS 和 EB tresos 都可用于开发 S32E 应用程序。希望这些信息对您有所帮助；如果您还有任何疑问，可以随时联系我们。 BR 乔伊

LPC1347 USB 控制传输 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们的客户 SIGMATEK 希望在 LPC1347 上实现 USB 控制传输。 只要数据长度小于 64 字节或大于 64 字节，这种方法就很好用。 如果数据长度正好是 64 字节（或 64 字节的倍数），则此方法不再有效。 他们需要做些什么才能让这个功能正常运行？ 此致， Peter Re: LPC1347 USB Control Transfer 你好， 当 USB 数据有效载荷恰好等于端点最大数据包大小（全速为 64 字节）的倍数时，接收器会挂起，因为没有短数据包来表示传输结束；为了在 LPC1347 上解决此问题，SIGMATEK 必须检查有效载荷长度是否为 64 的非零倍数，如果是，则在主数据块之后立即手动发送长度为零的零长度数据包 (ZLP)，以刷新缓冲区、表示完成并成功终止传输。 此致

PTN5150AHXMP IBISモデル こんにちは、 私はKrithikka Jayamurthiです。信号整合性シミュレーションを行うためにIBISモデルファイルが必要です。 Re: PTN5150AHXMP IBIS model こんにちは、クリティッカさん。 この装置やそのファミリ部品については、IBISシミュレーションモデルは作成されていません。 USB Type-Cインターフェース上のCCラインは比較的低い信号速度(USB PD BMC信号は300 kbps)で動作するため、IBISモデルに通常求められる高周波信号の整合性問題には一般的に影響されません。データシートの標準I²Cレベルまたは低速I/O特性評価(電気仕様:VOL/VOH、IOL/IOH、昇降時間、静電容量)で、通常はCCピンの信号品質を評価するのに十分です。 もし信号の整合性に関する懸念がUSBデータパス(USB 2.0 D+/D−)に特化している場合、PTN5150AHXMP自体はUSBデータラインをルーティングやバッファリングするものではなく、純粋にCCロジックコントローラであることにご注意ください。USBデータ信号はデバイスを完全にバイパスし、コネクタとレセプタクルで直接処理されます。 BRs、トーマス

关于使用S32K388主从模式的咨询 6953956c0a213afc6de89697c3d0e88f.png6953956c0a213afc6de89697c3d0e88f.png 我们这里有一个要求，即两个 S32k388 使用 SPI 通信相互通信。两者之间可以既是主人又是奴隶吗？例如，当我使用芯片 A 作为主机时，IOMUX 表中的 I 项描述了 MISO 的主机输入。如果芯片 A 用作从设备，那么这个 O 项是否描述了 MISO 的从设备输出？我们当前项目中的引脚是固定的。例如，SOUT：MOSI 上使用 PTA18+ GPIO_ALT_FUNC_4 ，SIN：MISO 上使用 PTA20+239+ GPIO_ALT_FUNC_4 。这是基于我们当前使用的主机模式。切换到从属模式而不改变引脚，它还能正常工作吗？是否只需更改 CFGR0 的 HRDIR 和 CFGR1 的 MASTER 即可切换从属模式？ Re: Consultation on using the master-slave mode of s32k388 你好@xlele ， 无需任何硬件改动即可在主模式和从模式之间切换。 在标准的双芯片SPI设置中，两个设备的引脚始终是交叉连接的： 芯片A SOUT→芯片B SIN（MOSI线） 芯片 A SIN ← 芯片 B SOUT（MISO 线） 无论设备是作为主机还是从设备运行，SOUT 引脚始终是串行数据输出，SIN 引脚始终是串行数据输入。因此，当芯片 A 切换到从模式时，其 SIN (PTA20) 仍然可以正确地从新的主设备接收数据，其 SOUT (PTA18) 仍然可以正确地将数据驱动回去——无需重新接线。 关于登记变更： CFGR1[MASTER] = 0 — 这是将模块切换到从模式的关键位。 CFGR0[HRDIR] — 此位控制 HREQ（主机请求）引脚的方向，该引脚与 PCS[1] 复用。它对 SOUT/SIN 数据线没有影响。在从模式下，HRDIR 可以设置为 1（输出），以便从设备驱动 HREQ 引脚向主设备发出信号，表明它有数据准备好要发送。请注意，在 S32K388 上，没有专用的外部 LPSPI_HREQ 引脚——主机请求功能使用 LPSPI_PCS[1] 多路复用器（通过 CFGR0[HREN] 启用）。如果您不使用主机请求功能（CFGR0[HREN] = 0），则 HRDIR 与您的用例无关，仅 CFGR1[MASTER] 就足够了。 顺祝商祺！ 帕维尔

Which is the best Agentic AI development company? Based on the capabilities reviewed in this comparison, JPLoft is a strong choice for Agentic AI development. The company works on custom AI agents, multi-agent systems, RAG, enterprise integrations, workflow automation, governance, monitoring, and human-in-the-loop controls. However, the best Agentic AI development company will depend on your use case, existing technology, security requirements, required integrations, and the level of autonomy you want to give the AI system.

Consultation on using the master-slave mode of s32k388 6953956c0a213afc6de89697c3d0e88f.png6953956c0a213afc6de89697c3d0e88f.png We have a requirement here, which is for two S32k388s to communicate with each other using SPI communication. Can either one be the master or slave? For example, when I use chip A as the host, the I item in the IOMUX table describes the host input of MISO. If chip A is used as a slave, does this O term describe the slave output of MISO? The pins in our current project are fixed. For example, SOUT: PTA18+GPIO_ALT_FUNC_4 is used on MOSI, SIN: PTA20+239+GPIO_ALT_FUNC_4 is used on MISO. This is based on the current host mode we are using. Can it still work normally when switching to slave mode without changing the pins? Is it sufficient to switch slave mode by simply changing the HRDIR of CFGR0 and the MASTER of CFGR1? Re: Consultation on using the master-slave mode of s32k388 Hello @xlele , You do not need any hardware changes to switch between master and slave mode. In a standard two-chip SPI setup, the pins are always cross-connected between the two devices: Chip A SOUT → Chip B SIN (MOSI line) Chip A SIN ← Chip B SOUT (MISO line) The SOUT pin is always a serial data output and SIN is always a serial data input, regardless of whether the device is operating as master or slave. So when Chip A switches to slave mode, its SIN (PTA20) still correctly receives data from the new master and its SOUT (PTA18) still correctly drives data back — no rewiring needed. Regarding the register changes: CFGR1[MASTER] = 0 — this is the key bit to switch the module into slave mode. CFGR0[HRDIR] —  this bit controls the direction of the HREQ (Host Request) pin, which is multiplexed with PCS[1]. It has no effect on the SOUT/SIN data lines. In slave mode, HRDIR can be set to 1 (output) so that the slave drives the HREQ pin to signal the master that it has data ready to transmit. Note that on S32K388, there is no dedicated external LPSPI_HREQ pin — the host request function uses the LPSPI_PCS[1] mux (enabled via CFGR0[HREN]). If you are not using the host request feature (CFGR0[HREN] = 0), HRDIR is not relevant to your use case and CFGR1[MASTER] alone is sufficient. Best regards, Pavel

Guideline for Porting a New YOLO Variant - YOLO26 on Ara2 This slides firstly introduce the YOLO26 model, and NXP Ara2 Model Zoo, Ara2 SDK/Runtime. Then it explains the CNN model compilation flow with Ara2 toolchain in SDK package, how to compile the newly added model - Yolo26n, how to setup the inference environment in i.MX95FRDM+Ara2-240 board. Finally present the inference result. Patches and user guide are provided in attachment as well.

TJA1410_10Base_T1s Hi,NXP I am testing 10BASE-T1S using the S32K5 and TJA1410. Currently, I can see waveforms on the TX pin, and there are also waveforms on the RX and ED pins, which indicates that signals can be received on the MDI. However, the TX pin is unable to send data to the MDI. TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp Best Reagrds. xianlong Ethernet PHY Re: TJA1410_10Base_T1s Hello @wuxianlong , How have you measured the MDI? MDI is differential interface so you need to use differential oscilloscope probe. MDI requires proper differential termination - please refer to AN14787 - Application note 10BASE-T1S Ethernet PMD transceiver TJA1410, Rev. 1.0 , chapter 3.3. Best regards, Pavel Re: TJA1410_10Base_T1s Hello @wuxianlong , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) - S32K5 - which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. We appreciate your understanding in this matter. Thank you for your understanding. Best regards, Pavel Re: TJA1410_10Base_T1s Hi,@PavelL  I did not use a differential probe. When I transmit (TX), the MDI shows no fluctuation on the oscilloscope — it remains flat/horizontal. However, when the PC sends data, the MDI clearly shows a differential waveform. It feels like the TJA1410 is not being correctly switched into transmit mode and the chip remains in normal mode. Are there any methods to verify the PHY's current mode? Currently, our TJA1410 is not connected to an SMI interface — what precautions should we take regarding this? Best Regards, xianlong Re: TJA1410_10Base_T1s Hello @wuxianlong , Since S32K5 is an NPI device, please note that we are currently unable to validate the complete S32K5 and TJA1410 setup on our side.   The TJA1410 operating mode is not selected through the SMI interface. The transitions between Normal and Transmitting modes are controlled by commands received on the TX pin. Therefore, observing data activity on TX does not necessarily confirm that the TJA1410 has entered Transmitting mode. The preceding TRANSMIT command and its timing must also comply with the timing specified in the TJA1410 data sheet.   Please verify the transition from Normal to Transmitting mode according to Figure 10 in the TJA1410 data sheet. In particular, please capture the TX command together with the differential VLINE signal and ED output. This should confirm whether the TJA1410 recognizes the TRANSMIT command and activates its MDI transmitter.   Best regards, Pavel

Audifort评测：它真的能一夜之间消除耳鸣吗？ Audifort评测：它真的能一夜之间消除耳鸣吗？ 如果你每天都要忍受耳朵里持续不断的铃声、嗡嗡声或咔哒声，你就知道寻求缓解这种痛苦有多么令人绝望。在网上寻找解决方案时，您可能会遇到诸如液体营养滴剂之类的铺天盖地的广告。 奥迪福特 这暗示着可以立即见效或一夜之间缓解耳鸣。 简而言之，答案是否定的：Audifort 并不能在一夜之间消除耳鸣。 没有任何口服补品或天然滴剂能在 24 小时内立即治愈慢性耳鸣或重建受损的听觉神经。 但这并不意味着该公式毫无用处。如果将 Audifort 视为一种天然膳食补充剂而不是灵丹妙药，那么它提供的营养成分可以滋养内耳血管，并随着时间的推移镇静过度活跃的神经信号。 在此 Audifort 评测，我们超越销售营销，分析滴剂的实际作用原理、核心成分、合理的预期时间、潜在的副作用，以及如何避免虚假的在线信息。

TJA1410_10Base_T1s 您好，NXP 我正在使用 S32K5 和 TJA1410 测试 10BASE-T1S。目前，我可以在 TX 引脚上看到波形，RX 和 ED 引脚上也有波形，这表明 MDI 可以接收到信号。但是，TX 引脚无法向 MDI 发送数据。 TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp 此致敬礼。 显龙 以太网 PHY Re: TJA1410_10Base_T1s 你好@wuxianlong ， 你是如何测量MDI的？MDI是差分接口，所以你需要使用差分示波器探头。MDI 需要正确的差分终端匹配 - 请参阅 AN14787 - 应用笔记 10BASE-T1S 以太网 PMD 收发器 TJA1410，修订版 1.0，第 3.3 章。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 希望你一切安好。我写信给您是关于您目前拥有的一款产品——NPI（新产品导入）——S32K5——该产品尚未正式发布。 请注意，已获准提前体验此类产品的客户已指派了现场工程师。您指定的现场工程师应作为您解决有关本产品任何问题、疑虑或疑问的主要支持渠道。 我们的在线支持团队将在该产品正式发布后，提供更广泛的支持服务。在此之前，我们将无法提供所需的帮助。 感谢您的理解。 感谢您的理解。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 嗨， @PavelL 我没有使用差分探头。当我发射（TX）时，示波器上的 MDI 没有波动——它保持平坦/水平。但是，当 PC 发送数据时，MDI 明显显示出差分波形。感觉TJA1410没有正确切换到发射模式，芯片仍然处于正常模式。是否有方法可以验证PHY的当前模式？目前，我们的 TJA1410 未连接到 SMI 接口——我们应该对此采取哪些预防措施？ 此致， 显龙 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 由于 S32K5 是 NPI 设备，请注意，我们目前无法在我们这边验证完整的 S32K5 和 TJA1410 设置。   TJA1410 的工作模式不是通过 SMI 接口选择的。正常模式和传输模式之间的转换由 TX 引脚上接收到的命令控制。因此，观察 TX 上的数据活动并不一定能确认 TJA1410 已进入发射模式。前面的 TRANSMIT 命令及其时序也必须符合 TJA1410 数据表中规定的时序。   请根据 TJA1410 数据表中的图 10 验证从正常模式到传输模式的转换。特别地，请捕获 TX 命令以及差分 VLINE 信号和 ED 输出。这应该可以确认 TJA1410 是否识别 TRANSMIT 命令并激活其 MDI 发射器。   顺祝商祺！ 帕维尔

TJA1410_10Base_T1s こんにちは、NXP S32K5とTJA1410を使用して10BASE-T1Sのテストを行っています。現在、TXピンに波形が見え、RXピンとEDピンにも波形があり、これはMDIで信号が受信できることを示しています。しかし、TXピンはMDIにデータを送信できません。 TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp よろしくお願いいたします。 シアンロン イーサネット PHY Re: TJA1410_10Base_T1s こんにちは@wuxianlongさん MDIはどのように測定しましたか?MDIは差動インターフェースなので、差動オシロスコーププローブを使う必要があります。MDIは適切な差動終端を必要とします。AN14787 - アプリケーションノート10BASE-T1S イーサネットPMDトランシーバ TJA1410、Rev. 1.0、第3.3章を参照してください。 よろしくお願いいたします。 パベル Re: TJA1410_10Base_T1s こんにちは@wuxianlongさん このメールが、あなたがお元気でいらっしゃる時に届くことを願っています。現在お手元にある製品、NPI(新製品紹介)S32K5についてお手伝いしていますが、まだ正式に発売されていません。 これらの製品の早期アクセス権を得たお客様は、現場エンジニアを割り当てていることにご注意ください。指定されたフィールドエンジニアが、この製品に関する問題や懸念、問い合わせの主要なサポートチャネルとなります。 正式リリース後、オンラインサポートチームはより幅広いサポートを展開していきます。それまでは、私たちは必要な支援を提供する体制が整っていません。 この件についてご理解いただき感謝いたします。 ご理解いただきありがとうございます。 よろしくお願いいたします。 パベル Re: TJA1410_10Base_T1s こんにちは、 @PavelL 私は差動プローブを使用しませんでした。私が送信（TX）すると、オシロスコープ上のMDIには変動が見られず、平坦／水平な状態が維持されます。しかし、PCがデータを送信すると、MDIには明確な差動波形が表示される。TJA1410が正しく送信モードに切り替わっておらず、チップは通常モードのままにしているように感じます。PHYの現在のモードを確認する方法はありますか?現在、私たちのTJA1410はSMIインターフェースに接続されていませんが、どのような注意点を取るべきでしょうか? 敬具 仙龍 Re: TJA1410_10Base_T1s こんにちは@wuxianlongさん S32K5はNPIデバイスであるため、現時点では弊社側でS32K5とTJA1410の完全なセットアップを検証することができませんのでご了承ください。   TJA1410動作モードはSMIインターフェースを通じて選択されません。通常モードと送信モード間の遷移は、TXピンで受信したコマンドによって制御されます。したがって、TXでデータアクティビティを観測したとしても、TJA1410が送信モードに入ったことを必ずしも確認できるわけではありません。前述のTRANSMITコマンドとそのタイミングは、TJA1410データシートに指定されているタイミングにも準拠する必要があります。   TJA1410データシートの図10に従って、通常モードから送信モードへの遷移を確認してください。特に、TXコマンドと差動VLINE信号、およびED出力を併せて取得してください。これにより、TJA1410がTRANSMITコマンドを認識し、MDIトランスミッタを起動するかどうかが確認されます。   よろしくお願いいたします。 パベル

IMX95データシート こんにちは、 レジスタマップやペリフェラルなどを含むIMX95のデータシートをどうやって入手できますか? 敬具 アルトゥール Re: IMX95 datasheet ありがとうございます。良い一日をお過ごしください。 よろしくお願いいたします。 アルトゥール Re: IMX95 datasheet データシート単独では完全なレジスタマップやペリフェラルの説明は含まれていません。 そのためには、 https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdfが必要です。 よろしくお願いします。

i.MXRT1176 上的 WiFi (SDIO) 断开连接与 Qt/QML UI 的复杂性相关 大家好， 我们目前正在研发一款具有屏幕镜像功能的仪表盘。在我们的架构中，配套的移动应用程序通过 Wi-Fi 将帧流传输到我们的主机 MCU。数据通过 SDIO 连接的 Wi-Fi 模块接收，使用 FFmpeg 解码，并在显示屏上呈现。我们的网络协议栈采用 lwIP，集群 HMI 的 MCU 采用 Qt。 系统规格： 主机MCU： NXP i.MX RT1176 Wi-Fi 模块： u-blox MAYA-W161（SDIO 接口） 显示屏： LCDIFV2（并行RGB接口） 操作系统： FreeRTOS 问题：我们遇到了间歇性的 Wi-Fi 断开连接问题，这似乎与图形负载直接相关。只有当显示器运行资源密集型 GUI（包含大量元素和动画）时，才会出现 Wi-Fi 掉线的情况。切换到轻量级用户界面后，Wi-Fi 连接依然非常稳定。 请指导我们如何解决这个问题。 此致， 维格内什 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 你好@Vignesh_VInayak ，希望你一切都好。 由于图像处理需要较高的 CPU 使用率和较大的内存占用，因此对于 GUI 相关应用程序，两个核心中的一个将是专用的，用于管理界面。请问您的实现方案是否使用了两个核心？每个线程是否有专用的堆栈空间？ 此外，能否请您提供已启用调试日志记录的 Wi-Fi 协议栈日志，以便我们进一步分析 Wi-Fi 线程的状态？要启用调试日志，请在wifi_config.h 文件中启用“CONFIG_WLCMGR_DEBUG”和“CONFIG_WIFI_SDIO_DEBUG”宏。头文件？ Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 嗨@RomanVR ， 感谢您如此迅速地回复我。 请查看下方所需详细信息和日志： 目前，我们的项目只使用 Cortex-M7 内核；没有使用 M4 内核。 是的，所有线程都已分配了足够的堆栈空间。我们还使用 FreeRTOS 堆栈溢出钩子函数验证了这一点，没有发生溢出。 我已附上启用建议宏后的日志文件。在日志中，最后一个 wlcm 日志之后的所有内容都是我们的应用程序日志，每当收到 Wi-Fi 数据包时，这些日志都会打印一些随机帧大小。如您所见，日志在某个点停止了——这就是 Wi-Fi 断开连接发生的地方。断开连接的那一刻，我们没有看到来自 wlcm 或 SDIO 的任何日志。 此致， 维格内什。

MCXN947 HPDAC 反向移植 我正在将 Zephyr nxp_hpdac 驱动程序移植到 Zephyr 4.3，用于基于 MCXN947 的板。 上游驱动程序未使用设备初始化回调。然而，在 Zephyr 4.3 上，除非我在使用该外设之前显式初始化 DAC2 时钟、SPC 模拟模块并进行RESET，否则 HPDAC 无法正常工作。 我添加了一个 nxp_hpdac_init() 函数，该函数执行以下步骤： CLOCK_SetClkDiv(kCLOCK_DivDac2Clk, 1U) CLOCK_AttachClk(kFRO_HF_to_DAC2) CLOCK_EnableClock(kCLOCK_Dac2) SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac2) SPC_EnableLowPowerModeAnalogModules(SPC0, kSPC_controlDac2) RESET_PeripheralReset(kDAC2_RST_SHIFT_RSTn) DAC14_DoSoftwareReset() DAC14_DoFIFOReset() SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlVref) 这些初始化步骤基于 MCXN947 参考手册，并使用相应的 MCUX SDK API 实现。 init 函数通过 DEVICE_DT_INST_DEFINE() 注册为设备初始化回调函数。经过这些更改，HPDAC 可以正常工作了。 我还检查了 Zephyr MCUX SYSCON 时钟控制驱动程序和 mcux_lpc_syscon_clock.h 文件。虽然有绑定，但我找不到 HPDAC/DAC2 时钟标识符或该外设的时钟控制实现，因此我目前直接使用 MCUX SDK 时钟、SPC 和复位 API。 我的问题是： 1. 在向后移植 MCXN947 HPDAC 驱动程序时，这种方法是否正确？ 2. 在较新的 Zephyr 版本中，这些资源是在其他地方初始化的，还是上游 nxp_hpdac 驱动程序假定它们已经配置好了？ 3. HPDAC 设备初始化回调是否是进行此 MCXN947 特定初始化的正确位置，还是应该在 Zephyr 的其他地方处理这些步骤？ 我已附上完整的移植驱动程序供您参考。 模拟（ADC|CMP|DAC|运算放大器） 时钟|计时器 MCX N 回复： MCXN947 HPDAC backport 嗨@wesOS 1. 在向后移植 MCXN947 HPDAC 驱动程序时，这种方法是否正确？ 是的，这对于向后移植来说是一个合理且实用的方法。如果 Zephyr 4.3 环境中的其他位置没有初始化所需的 DAC2 时钟、SPC 模拟模块、VREF 和 RESET 资源，则必须在驱动程序中执行初始化，以确保 HPDAC 正确运行。 2. 在较新的 Zephyr 版本中，这些资源是在其他地方初始化的，还是上游 nxp_hpdac 驱动程序假定它们已经配置好了？ HPDAC 支持已在上游添加： https://github.com/zephyrproject-rtos/zephyr/pull/104642 然而，我使用当前的上游实现进行了快速验证，发现 DAC2 时钟似乎没有配置。例如，在我的测试环境中，CLOCK_GetDacClkFreq(2) 报告为 0 Hz，而配置 DAC 时钟后，相应的 MCUX SDK 示例报告为 48 MHz。 根据这一观察结果，当前驱动程序似乎假定某些设备资源已经配置完毕。请您也检查一下您那边的时钟配置路径好吗？ 我也会将此情况报告给我们的 Zephyr 团队，以便他们进一步调查，如果确认存在时钟初始化错误，我将与他们合作解决这个问题。 3. HPDAC 设备初始化回调是否是进行此 MCXN947 特定初始化的正确位置，还是应该在 Zephyr 的其他地方处理这些步骤？ 对于向后移植来说，将此逻辑放在 HPDAC 设备初始化回调中是一个实用且可接受的解决方案。 也就是说，MCXN947 特有的 DAC2 时钟、SPC、VREF 和 RESET 配置最好明确地隔离为 SoC 特有的功能，而不是作为通用 HPDAC 行为嵌入。从长远来看，这些资源最好通过 Zephyr 基础设施进行管理，例如时钟、RESET 或电源管理单元框架（如适用）。 BR 哈里

请问能否提供LS1021A的IFC接口的PCB设计指南？ 您好， 在我的板上，LS1021A 的 IFC 接口将直接连接到两个 Flash、两个带 MCU 接口的 PHY 和 2 个缓冲器（ SN74LVC16245A ）。PCB 布线将非常复杂。所以， 1. 从系统集成角度来看，可以接受什么样的路由拓扑结构？ 2. 请问能否提供LS1021A的IFC接口的PCB设计指南？ 提前感谢！ 顺祝商祺！ 杰森 QorIQ LS1设备 Re: Could you please provide me the PCB design guide for IFC interface of LS1021A 嗨，June： 如下图所示，我的电路有点复杂。IFC总线将驱动总共8个芯片通过一些缓冲器。由于IFC接口采用异步模式，因此IFC速率不高。您是否有像 Yiping.wang 给我的那种 IFC 接口的通用路由指南？ Jason_in_job_0-1789111004993.pngJason_in_job_0-1789111004993.pngJason_in_job_0-1789111004993.png 提前感谢！ 顺祝商祺！ 杰森 Re: Could you please provide me the PCB design guide for IFC interface of LS1021A 请分享您的拓扑结构详情 1. 这两个 SN74LVC16245A 设备将用于缓冲或隔离 IFC 地址/数据总线吗？ 2. 将哪些类型的闪存设备连接到 IFC 接口（或非 闪存、与非 闪存等）？ 3. 这两个 PHY 设备是如何连接到 IFC 接口的？他们使用的是GPCM模式吗？ 4. 请您确认完整的IFC装载清单？它由两个闪存设备和两个MCU接口PHY设备组成吗？ 谢谢！ Re: Could you please provide me the PCB design guide for IFC interface of LS1021A 我们没有专门针对 LS1021A IFC 接口的专用 PCB 布线指南。 与 DDR 或以太网等高速接口不同，IFC 是一种异步并行接口，信号完整性考虑因素很大程度上取决于实际拓扑结构、负载、工作频率和 PCB 实现。因此，NXP 没有提供具有通用布局规则的专用的 IFC 布线指南。 一般来说，我们建议尽量缩短分支（短截线）长度，尽可能缩短从 LS1021A 到锁存器和缓冲器的走线，并在可行的情况下使用缓冲器来隔离下游加载。 如果条件允许，我们建议使用短截线的菊花链式布线（例如，尽可能在 1 英寸/25 毫米以内），而不是大型星形拓扑连接。对于您的拓扑结构，通常最好将地址锁存器放置在最靠近 LS1021A 的位置，然后是启动 Flash 设备，同时保持缓冲区足够接近，以最大限度地减少 IFC 总线上的负载。 我们还建议将 IFC 走线的单端阻抗控制在 50 Ω ±10% 以内。±10% 的容差考虑了 PCB 制造过程中的变化，而理想的设计目标应在 ±2% 以内。 如果在验证过程中发现信号完整性问题，可以根据实际波形测量和 PCB 实现情况，考虑在 LS1021A 输出端使用源端电阻（例如 22 Ω 至 33 Ω）。 请参考 AN4878（LS1021A 设计检查清单）和 TWR-LS1021A 参考设计。 考虑到拓扑结构的复杂性和所连接负载的数量，建议在最终确定 PCB 设计之前进行信号完整性 (SI) 仿真，以验证布线拓扑、负载和时序裕量。 谢谢！

MCF51JE256 的替代产品 我想请您推荐一款符合以下要求的MCU芯片：32位数据总线/传输；1MB或更大的程序存储空间；集成至少一个I2C总线控制器；集成至少两个SPI总线控制器；至少六个或更多A/D模数转换通道；集成至少一个3×3矩阵键盘控制器；集成至少两个定时器；集成TOD（时间）定时器中断和其他外部中断；集成USB接口控制器。以上就是全部要求——谢谢您的帮助。我们希望找到一款能够替代我们目前使用的芯片 MCF51JE256 功能的芯片。如果您需要，我还可以帮助您寻找符合这些要求的特定MCU推荐产品。 模拟（ADC|CMP|DAC|运算放大器） 音频（PDM | I2S | SAI） 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: a replacement product for MCF51JE256 你好@ly_12_31 我建议考虑MCXA或MCXN系列，因为它们是恩智浦最新的主流MCU系列，并且正在积极推广用于新设计。 除了专用的 3×3 矩阵键盘控制器之外，这些设备可以满足您的所有要求。然而，这种功能可以通过软件中的 GPIO 来实现。 MCX A13 A14x MCX A15x Arm Cortex-M33 - 低功耗智能外设 | 恩智浦半导体 MCX N94、N54、N53、N52 和 N24 MCU | 恩智浦半导体 谢谢！ BR 爱丽丝