关于 i.MX 93 的 Windows 10/11 物联网企业版 - bootcmd 嗨，朋友们、 有人知道吗，如何为 i.MX93 配置正确的 bootcmd 以允许它从 U-Boot 正确启动，然后从 ARM 上的 Windows 启动？ 在过去的时间里，我们在 defconfig 中对 i.MX 8 Series bootcmd 进行了如下配置： CONFIG_BOOTCOMMAND="fatload mmc${mmcdev}:${mmcpart} ${loadaddr} /uefi.fit；bootm${loadaddr} ；" 因为当我们版本 i.MX 8 固件，例如 i.MX 8M Plus 时，在 ~/win10-iot-bsp/imx-MKIMAGE/IMXImage/ IMX8M 中，你可以找到：imx8mp-evk.dtb，您还可以检查 soc.mak它将处理 imx8mp-evk.dtb并将其合并为最终固件文件。 但 i.MX93 文件夹结构相同、 soc.mak并没有做同样的事情。它不会在路径中创建 imx93-11x11-evk.dtb：~/win10-iot-bsp/imx-mkimage/imx-mkimage/IMX 9。 因此，如果我们按照同样的方式在 defconfig 中配置 CONFIG_启动 COMMAND，i.MX 8 系列的 U-Boot 程序将不一样，它不会进入 microSD WinPE（efi/boot/bootaa64.efi），它将继续重启。 有人知道如何正确操作吗？我们无法在 i.MX Windows IoT 用户指南、快速入门指南......中找到相关信息。 谢谢你们的帮助！ 祝您有美好的一天 亚历克斯-张 参考。 适用于 i.MX 应用处理器的 Windows 10/11 物联网企业版 Windows Windows 10 物联网企业版 Re: About Windows 10/11 IoT Enterprise for i.MX 93 - bootcmd 关于 Windows I0/11 IOT，我建议您 与 [email protected] 的 IOT 团队联系。 看看他们是否有这方面的信息。 Re: About Windows 10/11 IoT Enterprise for i.MX 93 - bootcmd 嗨，朋友们、 我们尝试对imx93_11x11_evk_nt_deconfig CONFIG_BOOTCOMMAND进行如下配置： mmc dev 1；如果 mmc 重新扫描；那么 fatload mmc 1:2 ${kernel_addr_r} EFI/启动/bootaa64.efi && fatload mmc 1:2 ${fdt_addr_r} dtb/imx93-11x11-evk.dtb && fdt addr ${fdt_addr_r} && fdt header && bootefi ${kernel_addr_r} ${fdt_addr_r}; fi 在重新编译固件并将其闪存到 microSD 卡并将其放入 i.MX 93 EVK 后，我们的 PuTTY 消息如下： 剧透 （高亮部分可供阅读） U-启动 2023.04-g93957155-dirty(Aug 08 2025 - 09:59:05 +0800) CPU：i.MX93 (52) rev1.1 1700 MHz（运行频率为 1692 MHz） CPU：30 摄氏度的工业温度等级（-40 摄氏度至 105C） 型号：恩智浦 i.MX93 11X11 EVK 板 动态随机存取存储器(DRAM)：2 GiB 内 核：218 个设备，30 个 u 类，设备树：独立的 MMC：FSL_SDHC：0，FSL_SDHC：1 来自 MMC 的加载环境... 好吧 ... 输入：串行 输出：串行 错误：串行 BuildInfo: - ELE 固件版本 0.1.0-e943c57c 切换到分区 #0，OK mmc1 是当前设备 闪存目标是 MMC：1 Fastboot：正常 正常启动 按任意键停止自动启动：0 切 换到分区 #0，OK mmc1 是当前设备 1 303 毫秒 (1.9 MiB/s) 读取 50392 字节在 7 毫秒 (6.9 MiB/s) 内 工作 FDT 设置为 83000000 魔法：0xd00dfeed 总大小：0xd00dfeed 总大小：0xd00dfeed 总大小：0xd00dfeed 总大小：0xd00dfeed 总大小：0xd00dfeed 总大小：0xd00dfeed 总大小：xc4d8 ( 50392) off_dt_struct：0x38 off_dt_strings：0xb5f8 off_mem_rsvmap：0x28 版本：17 last_comp_version：16 boot_cpuid_phys：0x0 size_dt_strings：0 xedb size_dt_struct：0xb5c0 数字 mem_rsv：0x0 正在启动 /EFI\启动\bootaa64.efi BlinitializeLibrary 失败 0xc0000225 ## 应用程序 失败，r = 14 启动= > U-启动 2023.04-g93957155-dirty（2025 年 8 月 8 日-09:59:05 +0800）CPU：i.MX93 (52) rev1.1 1700 MHz（以 1692 MHz 运行）CPU：30摄氏度的工业温度等级（-40摄氏度至 105摄氏度）型号：恩智浦 i.MX93 11X11 EVK BoardDRAM：2 GibCore：218 个设备，30 个 u 类，设备树：separateMMC：FSL_SDHC：0，FSL_SDHC：0，FBoardDRAM：2 GibCore：30 个设备，30 个 u 类，设备树：SeparateMMC SL_SDHC: 1正在从 MMC 加载环境...好的... 输入：SerialOut：SerialErr：SerialBuildInfo：-ELE 固件版本 0.1.0-e943c57cswitch到分区 #0，OKMMC1 是当前设备闪存的目标是 mmc: 1FastBoot：normalNormal 启动按任意键停止自动启动：0 切换到分区 #0，okmmc1 是当前设备在 1303 毫秒 (1.9 MiB/s) 内读取 50392 字节 (6.9 MiB/s) 工作 FDT 设置为 83000000magic：0xd00dfeedtotaltalmcmic：0xd00dfeedtotaltalmc1 大小：0xc4d8 (50392) off_dt_struct：0x38off_dt_strings：0xb5f8f8off_mem_rsvmap：0x28版本：17last_comp_versize：16boot_cpuid_phys：0xedbsize_dt_struct：0xb5c0number mem_rsvt：0xb5c0number mem_rsvt v: 0x0启动 /EFI\ Boot\ boot\ bootaa64.efiblinitializeLibrary 初始化库失败 0xc0000225## 启动失败，r = 14u-boot= > 我们曾尝试从 microSD\ WinPE\ boot.wim 中删除 Lanage P ackage 以缩小尺寸。(从 2.X GB 到 347 MB） 但是 i.MX 93 仍然无法启动。 有人有解决这个问题的经验吗？ 谢谢您！ 亚历克斯-张

PF5030はすべての出力が失われた状態でI2Cを読み取ります こんにちは。致命的なエラーが発生すると、入力電源は維持されますが、PF5030 のすべての出力が失われます。I2C 経由で詳細な障害情報を取得する方法はありますか? VDDIO は出力の 1 つから供給されます。この状況では、VDDIO が失われ、I2C インターフェースが機能しない可能性があります。しかし、致命的なエラーが発生した後に外部 VDDIO を提供するとどうなるでしょうか? エラー メッセージは保持されたままになりますか、それともすでに失われていますか?エラーが発生した後に外部 VDDIO を供給し、I2C 通信を試行することで、エラーの原因をCANますか? Re: PF5030 read I2C while all output lost こんにちは、ポニーさん 致命的なエラー (ウォッチドッグ障害、監視対象レールの過電圧、障害カウンタのオーバーフローなど) が発生すると、PF5030 は DEEP-FS 状態に移行します。 DEEP-FS では、すべてのレギュレータがオフになります。 フェイルセーフロジックはVINから内部的に電源供給されている I²C インターフェースはフェイルセーフ ドメインにあり、VDDIO (1.71 V ～ 5.25 V の範囲) が存在すると再び機能するようになります。 VIN が POR しきい値を上回っており、デバイスの電源がオフ/オンされていない限り、フェイルセーフ レジスタ (例: FS_GRL_FLAGS 、 FS_OVUVREG_STATUS1 、 FS_DIAG_SAFETY 、 FS_STATES ) には次の内容が含まれます。 どの電圧モニターがトリガーされたか（OV/UVフラグ） ウォッチドッグエラーフラグ 障害カウンターとステートマシンのステータス これらのレジスタはPORまたは明示的な書き込みによってのみクリアされ、DEEP-FSに入ることによってはクリアされません。 FS_GRL_FLAGS （一般的な障害の概要） FS_OVUVREG_STATUS1 （VMONがトリガー） FS_DIAG_SAFETY (ウォッチドッグ、CRC、BIST ステータス) FS_STATES （現在のフェイルセーフ状態） VIN が失われていない限り、VDDIO に外部電源を供給して致命的なエラーが発生した後に詳細な障害情報を回復 CAN。VIN が POR を下回ると、すべての揮発性レジスタがクリアされます。 敬具、 ヨゼフ

MCX Lab MCX Lab: Empowering University Innovation with NXP FRDM-MCXN947 What is MCX Lab? MCX Lab is an NXP initiative designed to foster collaboration with universities, providing students and educators with cutting-edge hardware, software, and educational resources. The program centers around the powerful NXP FRDM-MCXN947 development board, enabling hands-on learning and advanced research in embedded systems, AI/ML, IoT, and more. Key Features of the MCX Lab Program 1. FRDM-MCXN947 Comprehensive Hardware Platform MCXN947 MCU: Dual Arm® Cortex®-M33 cores @150MHz, up to 2MB dual-bank flash, Neural Processing Unit, PowerQuad, Smart DMA, and more. Rich Peripherals: User LEDs, buttons, accelerometer, temperature sensor, touch pad, Ethernet, USB Type-C, CAN-FD, WiFi, and extensive expansion options (Arduino®, FRDM, mikroBUS™, Pmod™, FlexIO/LCD, SmartDMA/Camera headers). Custom Shields: NXP-designed shields for introductory labs, featuring buttons, joystick, DIP switch, rotary encoder, LED ring, potentiometer, IR sensors, OLED display, and more. See MCX Lab Expansion Boards page for more. Add-on Modules: Wide portfolio of sensors, actuators, interfaces, displays, and wireless modules. Explore the Expansion Board Hub for more options. 2. Powerful Software Ecosystem Development IDEs and Build Tools: MCUXpresso IDE MCUXpresso for Visual Studio Code Third-party toolchains from Arm, IAR, Keil Examples and Quick Start Software: MCUXpresso SDK Debugging and Visualization Tools: LinkServer FreeMASTER Software Development Resources: MCUXpresso Config Tools Secure Provisioning Tool Secure Provisioning SDK (SPSDK) Device HSM Trust Provisioning RTOS: Zephyr™ OS AI Software Development: eIQ Toolkit HMI Design Software: GUI Guider Connectivity Software NXP Platform Accelerator 3. Educational Materials Lecture & Lab Content: Tailored for all levels—introductory (embedded basics), medium (GPIO, ADC, timers, serial comms), and advanced (Zephyr, AI/ML, UI/UX). See MCX Lab Educational Materials page for more. Invited Lectures: On-demand sessions by NXP engineers at partner universities. Documentation: Reference manuals, datasheets, getting started guides, application notes, and access to the MCUXpresso Training Hub. 4. Application Examples Application Code Hub: Application software packs, demo apps, code snippets, and integration with GitHub and VS Code for easy access and collaboration. Diverse Domains: AI/ML, audio, graphics, low power, motor control, power conversion, safety, security, networking, touch sensing, vision, voice, wireless connectivity, and more.

2015 年飞思卡尔杯 EMEA 球队名单 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 截至 2014 年 11 月 17 日，已有 159 支球队注册参加 2015 年飞思卡尔杯欧洲、中东和非洲赛区比赛 （见附件） 团队名称以 INNOV 开头的团队为创新挑战团队 未举办飞思卡尔杯资格赛的国家的队伍可以自由选择参加比赛的地点。请联系Flavio Stiffan以确保您的选择被记录在案。

フリースケール・カップ2015 EMEAチーム一覧 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 2014年11月17日現在、159チームがThe Freescale Cup 2015 EMEA に登録しています( 添付資料を参照) INNOVで始まるチーム名は、イノベーションチャレンジチームです フリースケール・カップ予選イベントが開催されていない国のチームは、選択した場所に自由に参加できます。Flavio Stiffanに連絡して、選択が記録されることを確認してください。

BAN-N1928 MIFARE Beyond Access - 智能校园一体化解决方案 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MIFARE ®在门禁领域占有 50% 的市场份额，但它的功能远不止于此。除了向员工和学生授予物理和逻辑访问权限外，MIFARE 还可以成为您的小额支付和忠诚度解决方案 - 集所有功能于一身。通过 NFC 功能，您的应用程序甚至可以读取数据并将新数据存储到 MIFARE 卡中。整体用户体验——只需轻轻一点。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MIFARE ®在门禁领域占有 50% 的市场份额，但它的功能远不止于此。除了向员工和学生授予物理和逻辑访问权限外，MIFARE 还可以成为您的小额支付和忠诚度解决方案 - 集所有功能于一身。通过 NFC 功能，您的应用程序甚至可以读取数据并将新数据存储到 MIFARE 卡中。整体用户体验——只需轻轻一点。 观看视频演示 智能银行和智能零售

SMI-N2078 SECO-从制造到制造-缺失的环节 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 得益于新的创客运动，如今的新企业家和创新者可以快速制作原型。然而，这个看似无限可能的世界在大规模生产产品时却遇到了很大的限制，因为在概念验证和制造之间缺少一个步骤或环节。本次演讲将展示 SECO 如何通过其社区运动和委员会 UDOO 将其嵌入式专业知识与新获得的创客运动经验融合在一起，弥补创客与工业之间的差距。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 得益于新的创客运动，如今的新企业家和创新者可以快速制作原型。然而，这个看似无限可能的世界在大规模生产产品时却遇到了很大的限制，因为在概念验证和制造之间缺少一个步骤或环节。本次演讲将展示 SECO 如何通过其社区运动和委员会 UDOO 将其嵌入式专业知识与新获得的创客运动经验融合在一起，弥补创客与工业之间的差距。 智能机械和工业自动化

DES-N1849 多核 ARM ® v8 QorIQ 处理器中的异常处理 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解ARM®v8异常水平处理(ELO至EL3)，以及基于最新的QorIQ LS系列处理器的通用中断控制器v3 (GICv3)逻辑在预封装的Linux SDK环境之外使用具有挑战性。 本次演示将介绍如何配置分发器(GICD)、再分发器(GICR)、CPU接口(ICC_*_EL*)和ARM内核，以处理专有外设中断(PPI)和软件触发的中断(SGI)。 它将用于嵌入式开发人员编写异常处理程序，以及被缩略词弄糊涂的任何人。 CodeWarrior将用于显示异常处理项目示例。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解ARM®v8异常水平处理(ELO至EL3)，以及基于最新的QorIQ LS系列处理器的通用中断控制器v3 (GICv3)逻辑在预封装的Linux SDK环境之外使用具有挑战性。 本次演示将介绍如何配置分发器(GICD)、再分发器(GICR)、CPU接口(ICC_*_EL*)和ARM内核，以处理专有外设中断(PPI)和软件触发的中断(SGI)。 它将用于嵌入式开发人员编写异常处理程序，以及被缩略词弄糊涂的任何人。 CodeWarrior将用于显示异常处理项目示例。 观看视频演示 设计 | 软件与服务

KSDK发布的内容 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetis SDK v2 现已推出！ Kinetis SDK v2 简介 KSDK 的第一步 如何开始使用 KSDK * 已发布示例列表： KSDK示例列表* 已发布文件清单： KSDK 文件清单* *以上所有源代码仅供示例使用。恩智浦不对用户应用程序中使用这些代码承担任何责任。 概述

S32Z RTU0 core0 性能问题 我在 S32Z270 RTU0 内核 0 (R52) 上运行一些测试代码，RTU0_CORE_CLK 设置为 1GHz，执行时间似乎过长。 相比之下，我在 SS32K388 内核 0 (CM7) 上运行相同的代码，内核时钟设置为 320MHz。 鉴于时钟频率的提高，我本以为执行速度会更快一些，但执行时间反而更长了。 两个二进制文件的版本/编译标志保持不变（参见随附的 txt 文件 buildinfo.h） (1) 由于 S32 配置工具中的时钟配置对于 S32Z 来说有点复杂，我如何才能确保 RTU0 内核 0 的时钟频率按计划为 1GHz？ 我已经通过 MC_CGM_3_MUX4_CSC（例如，SEL_CTL = 0x3D）将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4（BGA594 的 PAD_040），包括 MC_CGM_3_MUX4_DC_0（例如，DIV = 0x9）中为 10 的分频器。另请参见所附的登记册读数。 如果我在 CLKOUT_4 测量到 50MHz，我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz，(b) RTU0_CORE_CLK 为 1GHz？ (2) 我使用 S32Z RTD2.0.1 测量了引脚写入 GPIO 的执行时间，并测量了示波器通道 CH5 - TESTFLAG 的高/低时间，大约为 3.4us。您是否有可能确认一下它们看起来是正常还是太慢了？ (3) 我不知道我错过了什么。     Re: S32Z RTU0 core0 performance issue 随函附上包装标记的照片。 0   Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 感谢您的快速回复。 下面是我对这些问题的回答： 1) 我使用的是 S32Z2XX 主板 + S32Z2XX 子板的组合。 a) S32ZXX 主板 X-S32X-MB A 版 b) S32ZXX 子板 SCH-50588 REV B2 / 700-50588 REV A2 2) 代码使用 S32DS 版本 3.6.7 Build 260420 进行编译和链接。使用 S32DS 的先前版本（例如版本 3.6.6 或 3.6.5）时没有任何变化。我正在为 S32Z2XX 使用 RTD2.0.1。 3) 我会使用 DM 发送项目副本。 Re: S32Z RTU0 core0 performance issue 你好，德克-埃兹勒 感谢您与我们联系。 1. 你使用开发板还是客户板？ 2.您使用的是 S32DS 的 IDE 吗？您测试的 IDE 版本是什么？ 3.能否与我分享您的测试代码？ BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 感谢您的答复和详细资料。 我会帮你检查，并在晚些时候回复你。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 抱歉，回复晚了。 (1) 我已经通过 MC_CGM_3_MUX4_CSC（例如，SEL_CTL = 0x3D）将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4（BGA594 的 PAD_040），包括 MC_CGM_3_MUX4_DC_0 中的分频器 10（例如，DIV = 0x9）。另请参见所附的登记册读数。如果我在 CLKOUT_4 测量到 50MHz，我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz，(b) RTU0_CORE_CLK 为 1GHz？ >>>关于这个问题，数字 7 被分配给 RTU0_CORE_DIV2_CLK，您还应通过编程 GPR3.CLKOUT4SE 来设置该值。您能确认一下是否设置了这个寄存器吗？ BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好@Joey_z 关于这个问题： >>>关于这个问题，数字 7 被分配给 RTU0_CORE_DIV2_CLK，您还应通过编程 GPR3.CLKOUT4SE 来设置该值。 您能确认一下是否设置了这个寄存器吗？ 我检查了 GPR3.CLKOUT4SEL[MUXSEL] 的寄存器设置，该寄存器设置为 7，用于在相应的多路复用器中选择 RTU0_CORE_DIV2_CLK。 Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 我不确定我之前的留言是否已被确认为回复。 我检查了 GPR3.CLKOUT4SEL[MUXSEL]是否设置为 0x7，因此RTU0_CORE_DIV2_CLK 通过多路复用器路由。 使用所述配置并在输出引脚上看到 50MHz，我推测 RTU0 内核的时钟频率为 1GHz。 如果内核频率设置为 1GHz，但我仍然没有看到预期的性能（例如，使用 CoreMark 测试台），还有什么其他不正确的配置吗？ 如何检查缓存配置是否正确？ 我查看了汇编器启动脚本和使用过的链接器脚本，没有发现任何可疑之处。 Re: S32Z RTU0 core0 performance issue 你好，德克-埃茨勒 感谢您的答复和详细资料。 您可以尝试参考 AN14245 的第 3、4 章来检查缓存配置。 高速缓存机制有助于提高内存性能。您可以下载以下图片。 此外，GPIO 翻转到测量时间，主要反映了外设的"延迟" 访问路径，但会对 CPU 内核运算性能产生偏差。另外，在此应用程序中包含CoreMark的内容，您可以作为测试的参考。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好，@Joey_z、 谢谢，我将阅读上述应用笔记（AN14245 S32ZE 安全可靠的高性能实时处理器）的第 3 章和第 4 章，了解缓存的正确设置。 顺便提一句，获得的 CoreMark 分数太低，这也是支持案例的起因。

如何转换数字信号的电压？（日语博客） 0. 目录 0. 目录 1. 什么是电压电平转换器？ 2. 数字信号 2.1 各种数字信号 2.2 CMOS 和 TTL：使用简单的电压高电平和低电平表示逻辑电平信号 2.3 输入/输出电压规格：VOH/VOL 和 VIH/VIL 2.3.1 输出电压规格：VOH 和 VOL 2.3.2 输入电压规格：VIH 和 VIL 2.3.3VOH/VOL 与 VIH/VIL 之间的关系 3. 基本电压电平转换方法：单向信号转换 3.1 即使芯片的电源电压不同，也不需要进行转换的示例。 列：TTL 值 VIH(min) = 2.0V 和 VIL(max) = 0.8V 是如何确定的？ 3.2 需要转换的示例 3.2.1 利用开漏输出进行转换 3.2.2使用标准逻辑（通用逻辑）芯片进行转换 4. 需要自动方向切换的双向信号转换。 4.1 使用单个MOS晶体管的双向转换 4.2 使用专用设备的双向转换 4.2.1 I²C信号电压转换芯片 4.2.2 高速双向开漏信号电压转换芯片 4.2.3 双向推挽式信号电压转换器芯片 4.2.4I3C信号电压转换器芯片 4.2.5 基于缓冲区的转换 5. 总结 5.1 博客中介绍的方法/零件编号的比较 6. 参考资料 1. 什么是电压电平转换器？ 连接数字电路时，可以直接连接信号线…… 事实并非如此；如果“逻辑电平电压”不匹配，它可能无法工作、变得不稳定，或者在最坏的情况下，损坏芯片。 这时，电压电平转换器（也称电压电平移位器）就派上用场了。 电压电平转换器是一种允许不同电源电压的数字电路之间交换信号的电路。 例如，在以下情况下需要用到它： 3.3V 微控制器 ↔ 5V 传感器连接 将 1.8V FPGA 连接到 3.3V 外围设备 图 1：信号电压差异   本博客解释了数字电路中使用的各种逻辑电路类型（*TTL、*LVTTL、*CMOS）之间的电压电平差异，以及 VOH / VOL / VIH / VIL 在确定这些差异时的重要含义。此外，它还解释了在各种转换方法中如何选择合适的电压电平转换器。 此外，本博客将探讨电压电平转换器的具体示例，这些转换器可以自动检测和转换信号的方向。 NXP 还提供用于 SD 卡/SIM 卡的电压电平转换器和特定应用转换器，例如 GTL↔TTL 电平转换，但本博客将重点介绍面向通用或串行总线应用的产品。 *TTL（晶体管-晶体管逻辑） *LVTTL（低压晶体管-晶体管逻辑） *CMOS（互补金属氧化物半导体） *GTL（Gunning Transceiver Logic） 2. 数字信号   2.1 各种数字信号 所谓的“数字信号”是逻辑电平 1 和 0 的电信号表示。历史上，处理逻辑电平 1 和 0 有多种电路设计方法。这些方法包括用简单的电压高低来表示逻辑电平的方法，以及使用电压差来表示高低电平的方法。 TTL简单地用 5V/0V 表示高电平/低电平。进一步将 TTL 电压降低到 3.3V/0V，例如LVTTL ，这类系统的电压电平是根据双极型晶体管电路确定的。 类似地，ECL（电子分类）也使用双极型晶体管，但采用负电源来实现低幅度差分逻辑电平，从而获得更高的速度。GTL（全局晶体管叠层）则使用参考电压来传输高/低信号，以及低幅度单端信号等等。 此外，即使采用简单的高/低表示法，为降低功耗而开发的 4000 系列CMOS通用逻辑电路也允许使用 3V 至 18V 作为高电平。 https://en.wikipedia.org/wiki/Logic_family 本博客将解释如何处理 TTL (LVTTL) 和 CMOS 中的电压电平，它们使用简单的高电平和低电平来表示逻辑，以及上面提到的各种逻辑电平。 其他信号转换使用专用芯片，因此本文不予赘述。 此外，近年来半导体技术变得更小、更快、更节能，电源电压也随之降低。因此，用于桥接信号电压差的电压电平转换器变得尤为重要。 图 2：信号波形 - 电压电平（高/低）表示逻辑电平。   2.2 CMOS 和 TTL：使用简单的电压高电平和低电平表示逻辑电平信号 在数字电路中，简单的基于电压的逻辑电平信号通常使用高电平（HIGH）和低电平（LOW），高电平通常使用电源电压，低电平通常使用0V。只要高低电平的电压值相同，即使电源电压不同，信号也能传输。 例如，TTL（LVTTL）将2.0V或更高的输入信号解读为高电平，0.8V或更低的输入信号解读为低电平。由于这种约定，即使电源电压不同，TTL信号的高/低电平也不会改变。 另一方面，CMOS电路以电源电压的一半作为高/低电平的定义依据。因此，当电源电压变化时，CMOS电路的高/低电平电平也会发生变化。 图 3：输入信号电压规格   2.3 输入/输出电压规格：V OH /V OL 和 V IH /V IL 在数字电路中，高电平和低电平的输出电压以及用于判断输入信号是高电平还是低电平的电压都是有明确规定的。这些规定在每个芯片的规格书中都有明确说明，因此您需要查阅数据手册。 V OH ：高电平输出电压 VOL ： 低电平输出电压 V IH ：高电平输入电压 VIL ： 低电平 输入电压 2.3.1 输出电压规格：V OH 和 V OL 考虑输出时，必须考虑输出高/低信号所需的电流。电流会根据负载的变化而增大或减小。 在最大流出电流下，高输出时可保证的电压称为 VOH （最小值） ；在最大流入电流下，低输出时可保证的电压称为 VOL （最大值） 。 V OH (min) 是电路输出级中上方晶体管导通时的输出电压。该晶体管具有一个称为“导通电阻”的电阻。 当大电流流过晶体管时，会产生一个等于“晶体管电阻乘以流过电流”的电压。这会导致输出电压比电源电压低相应的数值，从而导致 VOH 值降低。因此， VOH (min)是指在达到预期最大输出电流时能够保证的最小电压。 图 4：数字信号输出电路（推挽式）   图 5：高输出电压随负载而变化。   VOL 则相反。当电路输出级中的低电平晶体管导通时，如果输入电流较大，由于晶体管导通电阻产生的电压，输出电压将高于 0V，如上所述。考虑到这一点， VOL (max) 是在预期输入电流最大时能够保证的最大电压。 图 6：低输出电压也会根据负载而变化。   2.3.2 输入电压规格：V IH 和 V IL 输入端有两个电压电平，用于判断高电平和低电平： V IH （最小值）和V IL （最大值） 。如果电压高于 V IH （最小值），则判定为高电平；如果电压低于 V IL （最大值），则判定为低电平。 在CMOS输入中，电源电压的一半用作高电平和低电平的参考电压，但这并不直接用作V IH (min) 和V IL (max) 。这是因为不同芯片之间的差异会导致阈值波动。此外，为了减轻输出端缓慢上升沿信号噪声引起的毛刺，通常会在输入端引入迟滞。基于这些原因，V IH (min) 和V IL (max) 被定义为具有一定的电压差。 2.3.3 VOH / VOL 与 VIH / VIL 之间的关系 要实现正常的信号交换，输出和输入之间的关系必须满足以下等式。 高水平：V OH （分钟）> V IH （分钟） 低水平： VOL （最大值）< VIIL （最大值） 如果保持这种关系，输出电路就能正确地将高/低信号传输到下一个输入电路。此外，它们之间的电压差“V OH (min) - V IH (min)”和“V IL(max) - V OL (max)”就成为“ 噪声容限”，并作为保持高抗噪性的指导原则。 图 7：V OH (min) / V OL (max) 和 V IH (min) / V IL (max) 3. 基本电压电平转换方法：单向信号转换   3.1 即使芯片的电源电压不同，也不需要进行转换的示例。 当“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”满足关系式时，通常不需要进行电压电平转换。例如，尽管TTL和LVTTL芯片使用的电源电压不同，但它们的输入和输出电压规格相同。 在 TTL (5V) 和 LVTTL (3.3V) 模式下， VOH (最小值) 为 2.4V， VOL (最大值) 为 0.4V。由于在两种情况下 VIH (最小值)/ VIL (最大值) 也均为 2.0V/0.8V，因此它们可以毫无问题地相互连接。 但是，如果输出电压高于输入芯片的电源电压，则需要格外小心。如果输出芯片使用 5V 电源，而输入芯片使用 3.3V 电源，则输入芯片必须支持“ 5V 耐受输入”。 5V 耐压输入是指即使将 5V 高电平信号连接到工作电压为 3.3V 的芯片的输入端，也能正常工作的输入端。虽然典型的芯片输入端都配备了静电放电 (ESD) 保护电路来防止静电损坏，但如果该 ESD 保护电路的配置如下图所示，5V 输入可能会导致电流从输入端反向流回 3.3V 电源，从而可能损坏芯片。5V 耐压输入的设计正是为了避免此类问题。耐压输入并非缺少 ESD 保护；它们内置了 ESD 保护电路，该电路能够处理高于电源电压的信号而不会造成任何问题。 如图 7 所示的 ESD 保护二极管，即使输入芯片断电，也可能导致问题。在独立控制每个芯片电源的系统中，即使输入芯片已关闭，输出信号也可能反馈到电源，导致输入芯片继续工作。 图 7：ESD 保护二极管 - 非容错输入 列：对于 TTL 电路，如何确定 V IH (min) = 2.0V 和 V IL (max) = 0.8V？ CMOS的输入阈值基于电源电压的中点(VCC/2)，而TTL的V IH (min) /V IL (max) 为2.0V/0.8V，相对于电源电压(5V)而言，这个比例并不十分理想。这与TTL的输入级由双极型晶体管构成有关。 标准 TTL 逻辑 IC 的内部电路示例：SN7400（2 输入 NAND）。 该信息包含在《1988 年最新通用逻辑器件规格表》（CQ 出版社）中。 典型的TTL门电路的输入级由一个多发射极输入晶体管和一个串联的相位分离晶体管组成。门电路开始响应的“开关阈值”由这两级中PN结的正向电压决定。由于单个硅PN结的正向电压约为0.6至0.7V，因此两级的总正向电压约为1.3至1.5V，这就是TTL门电路的有效开关阈值。 然而，约 1.4V 的值仅仅是一个“典型值”， 由于个体差异和温度变化，它会因批次和工况的不同而有所波动。 因此，数据手册中指定的 V IH (min) 和 V IL (max) 值被定义为保证值，在约 1.4V 的典型值上下留有足够的裕量，这意味着“如果电压降至此值，则可以可靠地判断为低电平 (V IL (max) = 0.8V)”，“如果电压升至此值，则可以可靠地判断为高电平 (V IH(min) = 2.0V)”。 此外，该值并非孤立地确定，而是根据 VOH 和 VOL 之间的关系设计而成，如第 2.3.3 节所述。在标准 TTL 电路中，由于输出级配置，高电平输出并非电源电压，而是略低的电压（比上述电路示例中的 130Ω 电阻、晶体管和二极管产生的电压低 2.4V）。当与 VOL(max)=0.4V 结合时， 高噪声容限：V OH （最小值）− V IH （最小值）= 2.4 − 2.0 = 0.4V 低侧噪声容限：V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V 如图所示，其设计旨在确保上下对称地提供 0.4V 的噪声容限。换句话说，TTL 的 2.0V/0.8V 数值相对于电源电压而言可能看起来“奇怪”，但实际上是合理的数值，其计算基于两个要求：双极型晶体管结电压的物理特性和噪声容限设计。 此图显示的是一个 SN7420（4 输入 NAND），其中三个输入引脚设置为高电平，一个引脚接收 100kHz 三角波（通道 1）。 当高电平 (Vcc=5V) 时，空载 (ch2) 输出小于 4V。 本专栏介绍的电路是一个没有指定型号的标准 TTL 电路示例（例如 74 LS 00 或 74 HC 00，没有 LS/HC 前缀；有时在英语中被称为“vanilla TTL”），但 V IH /V IL 规格相同的原因（输入级的双极结特性）与其他 TTL 系列（例如 74LS）相同。   3.2 需要转换的示例   虽然 TTL 和 LVTTL 连接由于电压电平匹配而可行，但当连接电源电压不同的 CMOS 芯片，或将 CMOS 芯片连接到 TTL 芯片时，逻辑电平不匹配的情况时有发生。这是因为上述关系“V OH (min) > V IH (min)”和“V OL (max) < V IL (max)”不成立，或者电平差过小，导致噪声容限不足。 电压电平转换器可以解决这个问题。 图 9：逻辑电平不匹配示例 (1)：高电平输入电压不足   图 10：逻辑电平不匹配示例（2）：输入的低电压不足。     3.2.1 利用开漏输出进行转换 无需使用电压转换芯片，也有简便的方法可以调节电压。 如果信号方向从输出芯片到输入芯片是固定的且不会切换，那么这种方法需要将高电平输出设置为开漏输出，以匹配输入电压。开漏输出是指数字电路输出级的上部晶体管缺失，高电平电压是通过连接到输入芯片电源电压的上拉电阻获得的。 图 11：数字信号输出电路（开漏）   明渠排水是一种简单且廉价的方法，但有几点需要注意。 首先，输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种类型的输出。 首先，输出端必须能够实现开漏输出。许多微控制器的GPIO引脚可以通过配置提供这种输出。如果输出固定为推挽输出且无法配置为开漏输出，则需要外部晶体管或类似器件将其转换为开漏输出。 此外，上拉电阻的选择也很重要。 为了获得高电压，需要使用上拉电阻，但如果电阻值太小，输出为低时流过的电流就会很大（类似于重负载），这将增加功耗，导致 电压 升高。 相反，如果该值过大，则会受到线路和引脚电容的影响，导致从低电平到高电平的上升时间变慢，从而降低通信速度。 3.2.2使用标准逻辑（通用逻辑）芯片进行转换 对于简单的电压电平转换，您也可以使用标准逻辑电路。例如， Nexperia 的 74AVCH4T245是一款通用 CMOS 逻辑芯片，可以执行 4 位双向电平转换。 该芯片可转换0.8V至3.6V的信号，并可通过DIR引脚切换信号方向。信号传输速度取决于转换电压，但可支持约100Mbps至380Mbps的速度。 图 12：标准逻辑示例 - 74AVCH4T245 该芯片能够实现高速双向电压信号转换，但转换方向必须由外部信号控制。虽然在并行总线上可以通过读/写等信号实现这种控制，但在串行总线等通信系统中，由于通信方向会根据协议而切换，因此难以应用这种控制方式。 图 13：标准逻辑示例。信号方向必须由外部指定。 4. 需要自动方向切换的双向信号转换。 迄今为止介绍的“开漏输出”和“使用标准逻辑芯片的电压转换方法”主要只能在一个方向上进行转换，或者需要通过外部信号来切换方向。 像I²C和I3C这样的通信方式，由于信号方向会动态变化，需要“双向电压电平转换”来自动检测并切换信号方向。外部控制这类信号的方向非常困难，而且使用上述缓冲芯片实现起来也很有挑战性。 此外，由于 I²C 是开漏信号，因此无法将标准的开漏逻辑缓冲器反向连接。图 14 展示了一个示例，其中开漏缓冲器反向连接。当缓冲器的两端均为高电平时，不会出现问题；但一旦其中一端变为低电平，缓冲器就会持续将另一端的输入拉低，并且无法恢复到高电平。 图 14：典型的开漏缓冲器不能自动在双向通信之间切换。   4.1 使用单个MOS晶体管的双向转换   迄今为止，I²C信号到电压的转换一直采用简单的电路。我们将以MOS晶体管为例，介绍一种最简单的方法。 图 15：使用 MOS 晶体管进行转换的示例   图 15 取自 I²C 规范 2.1 版（2000 年），展示了一个使用两个 MOS 晶体管（TR1、TR2）分别转换 3.3V 和 5V 信号的示例。尽管由于后文所述的问题，这种仅使用晶体管的简单转换示例已从当前的 I²C 规范中移除，但此处仍将其保留以帮助理解其原理。 I²C信号线，分别称为SDA和SCL，均为开漏双向信号。上拉电阻分别连接到3.3V和5V端。 在这个电路中，当3.3V和5V信号均为高电平时，该晶体管的栅极(g)和源极(s)处于同一电位，因此源极(s)和漏极(d)截止，它们之间的连接断开。当3.3V信号在此状态下变为低电平时，3.3V侧的晶体管（位于s和d之间）导通， 5V侧的信号也变为低电平。 当3.3V侧变为高电平，5V侧变为低电平时，连接3.3V侧和5V侧的寄生二极管（体二极管）首先导通。二极管导通后，电源电压下降。因此，晶体管导通， 3.3V侧的信号也变为低电平。 虽然这种使用晶体管作为开关的简单机制可以实现电压电平转换，但它也存在一些问题。晶体管的差异会影响信号转换的阈值电压。此外，随着处理更低信号电压的需求日益增长，例如在1V左右的信号电压下，这种电路无法工作，因为它无法获得足够的栅源电压（Vgs）。 附录： 与图 15 相同的电路仍以应用笔记 AN10441“I²C 总线设计中的电平转换技术” 的形式公开提供，该笔记由 Nexperia 公司发布。Nexperia 是一家由恩智浦半导体 (NXP) 分拆出半导体分立/逻辑产品业务后成立的公司。该应用笔记最初于 2007 年（版本 01）发布，与 I²C 规范分开，并于 2020 年以 Nexperia 品牌进行了修订（版本 2）。 4.2 使用专用设备的双向转换   通过使用 专用电压电平转换器 IC ， 可以轻松实现 I²C 和 I3C 等双向通信总线的电压电平转换。 4.2.1 I²C信号电压转换芯片 PCA9306和NVT20xx系列（ NVT2001/02 、 NVT2003/06 、 NVT2008/10 ）是专为双向信号转换而设计的电压电平转换器。这些芯片可以同时处理多条信号线（多位信号线）。虽然它们被指定为 I²C 信号电压转换芯片，但如果信号规格匹配，它们也可以用于其他用途（例如 SPI 和其他推挽信号） 。 PCA9306 和 NVT20xx 系列具有相同的内部结构，只有当要转换的电压差为 1V 或更大时，才需要将上拉电阻连接到较高的电压侧。 图 16 显示了其内部结构以及与外部芯片的连接（摘自应用笔记AN11127的图 2：“双向电压电平转换器 NVT20xx 和 PCA9306” ）。该芯片包含信号线（比特）数 + 1 个 MOS 晶体管。每个晶体管的源极和漏极可以互换。 信号传输路径中的晶体管称为传输晶体管，其余的晶体管称为参考晶体管。 图 16：NVT20xx (PCA9306) - 芯片工作原理示意图。   观察电路图，参考晶体管的栅极和漏极短接，并通过一个200kΩ的电阻连接到高压电源。参考晶体管的源极连接到低压电源。在这种连接方式下，参考晶体管相当于一个二极管，其栅极电压比低压电源高一个二极管电压。 剩余的传输晶体管的漏极连接到高压信号线和一个1kΩ的上拉电阻，其源极连接到低压信号线，其栅极连接到参考晶体管的栅极。当传输晶体管的高电平和低电平信号均为高电平时，高压侧的电压由1kΩ电阻上拉至高电平。 一个传输晶体管构成一个称为“源极跟随器”的电路。低压侧（源极）的电压比施加在栅极上的电压低，低的电压值等于晶体管导通所需的Vgs值。换句话说，源极的电压与低压电源的电压相同。此时晶体管处于半导通状态（工作在线性区），既非完全导通也非完全截止。 在这种状态下，当高电平或低电平信号变为低电平时，栅极和信号端之间的电压差会使晶体管导通（工作在完全导通的饱和区），另一个端也变为低电平。 该系列芯片可处理的信号速率受上拉电阻和信号线电容的影响。数据手册显示，PCA9306 最高可处理 2MHz 的信号速率。NVT20xx 系列芯片在上拉电阻为 192Ω、电容为 50pF 时，最高可处理 33MHz 的信号速率。对于 1MHz 左右的信号，即使不太在意上拉电阻和电容（假设其在 I²C 的常用范围内），也能正常工作。但是，如果要将该芯片用于推挽电路以处理更高速率的信号，则必须充分了解其特性并仔细选择合适的元件。 此类电压电平转换器的运行细节在文章“ PCA9306 的内部结构和运行”中进行了描述。 4.2.2 高速双向开漏信号电压转换芯片 我们推出NTS030x系列（ NTS0302JK 、 NTS0304E ）高速双向开漏信号转换芯片。 该芯片可执行 2 位或 4 位双向信号转换，可处理高达 2Mbps (1MHz) 的开漏信号和 20Mbps (10MHz) 的推挽信号。   图 17：NTS030x - 芯片内部框图   图 17 显示了 NTS030x 中一个信号比特的内部结构。 在图中，晶体管T3是一个直通晶体管，并对其施加了栅极偏置电压，因此当信号 A 或 B 变为低电平时，它会导通。 当 A 和 B 都为高电平时，T3 关闭，由于 A 和 B 通过相对较大的上拉电阻 (10kΩ) 连接到各自的电源，因此它们将具有各自的电压。 这款芯片包含T3以及T1和T2 。其中T1和T2用于一种名为“边沿速率加速器”的功能。我们将重点介绍其中一个T1，并解释其工作原理。 T1位于 A 侧，其源极连接到 A 信号，漏极连接到 A 侧电源。栅极连接到标有“单稳态和转换速率控制”的模块，该模块控制 T1。 “单次触发和转换速率控制”模块连接到另一端的 B 信号，用于检测 B 信号从低电平到高电平的变化。检测到此变化时，晶体管 T1 暂时导通，绕过 10kΩ 上拉电阻，允许电流通过，从而加速 A 信号从低电平到高电平的变化。通过这种方式加快信号的上升时间，可以处理更快的信号。 顺便一提，当 T1 打开时，其转换速率受到控制，以抑制电流突然增加引起的振铃。 另一个T2使用相同的机制，但方向相反，也应用于 B 面信号。 NTS系列还有另一个方便用户使用的功能。 对于前面提到的MOS晶体管和PCA9306/NVT20xx，存在一个问题：如果一个电源关闭，另一个电源的信号会被置为低电平。为了解决这个问题，NTS030x的设计使得当两个电源都未开启时，信号引脚会被置为高阻抗状态，从而避免相互影响。利用此功能，可以对系统的电源进行部分控制，使其处于开启/关闭状态。 NTS010x 系列（ NTS0102 、 NTS0104 ）与 NTS030x 系列等效，但缺乏处理高速信号的转换速率控制功能。 NTS0304E 配有评估板NTS0304EUK-ARD，可进行快速简便的运行验证。有关 NTS0304EUK-ARD 评估板的概述和操作方法，请参阅视频“如何操作 NTS0304EUK-ARD” 。 4.2.3 双向推挽式信号电压转换器芯片 此外，对于仅用于推挽信号的器件，还有NTB010x系列（ NTB0102 、 NTB0104 ），它提供了一种更快的选择。 当信号稳定处于高电平或低电平状态时，信号会通过一个 4kΩ 电阻。与 NTS030x 系列类似，它在高电平和低电平两端都具有单稳态功能，并且具有一种机制，当任一端的信号发生变化时，该机制会改变另一端的信号。 该机制能够以 70-80 Mbps 的速度实现信号到电压的转换，同时还具有自动信号方向检测功能。   图 17：NTB010x - 内部芯片框图 4.2.4I3C信号电压转换器芯片 I3C规范允许在开漏和推挽通信模式之间切换。在开漏模式下，它与 I²C 兼容，工作频率最高可达4MHz 。在推挽模式下，则使用12.5MHz 的时钟频率。由于信号电压通常在 1V 到 3.3V 的范围内，因此当存在电压差时，需要一个符合信号规范的电压电平转换器。 图 18 显示了P3A1604一位的内部框图。如图所示，该芯片集成了一种机制，不仅可以加速低电平到高电平的转换，还可以加速高电平到低电平的转换，并且还集成了一个可以开关的上拉电阻。   图 18：P3A1604 - 芯片内部框图 P3A1604是一款 4 位 I3C 电压电平转换器。另有 2 位版本P3A9606可供选择。   4.2.5 基于缓冲区的转换 转换双向信号的另一种方法是使用专用缓冲区。 缓冲器的主要目的是增强驱动能力并隔离连接信号线的电容，但也有一些产品支持电压转换。 正如这篇博客中所述，简单的缓冲器无法相互缓冲双向开漏信号。因此，市面上出现了各种具有双向开漏信号专用功能的缓冲器产品。 我会在以后的场合详细解释缓冲区的问题。 5. 总结 电压电平转换器是安全可靠地在不同电源电压的数字电路之间交换信号的关键组件。了解 TTL、LVTTL 和 CMOS 等逻辑电平的定义，以及 VOH/VOL/VIH/VIL 之间的关系，有助于选择合适的连接和转换方法。 对于单向转换，可以使用开漏输出或标准逻辑集成电路；而对于双向转换，可以使用MOS晶体管或专用集成电路（例如PCA9306/NVT/NTS/NTB/P3A系列）。 具有自动信号方向检测功能的电压电平转换器对于需要双向通信的总线（例如 I²C 和 I3C）特别有用。 此外，半导体技术的最新进展带来了更低的电压和更高的速度，这就对电压电平控制提出了更高的要求。虽然电压电平转换的方法和方案有很多，但根据应用需求，并考虑信号规格、速度和系统电源管理等因素，选择最佳的方法和元件至关重要。 5.1 博客中介绍的方法/零件编号的比较 方法/部件编号 目的 位数 方向改变 开放式布线兼容 低压侧 [V] 高压侧 [V] 比特率 [bps] 具有开漏输出的转换器 通用 1 单向 - - - - 标准逻辑（例如，74AVCH4T245） 通用型（并行总线等） 4 + 4 外部控制 不支持 0.8 ~ 3.6 0.8 ~ 3.6 1亿~3.8亿 使用单个MOS晶体管进行双向转换 I²C，通用 1 自动的 一致 根据晶体管规格而定 约100万 PCA9306 I²C，通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz，视情况而定） NVT2001 I²C，通用 1 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2002 I²C，通用 2 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2003 I²C，通用 3 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2006 I²C，通用 6 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2008 I²C，通用 8 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NVT2010 I²C，通用 10 自动的 一致 1.0 ~ 3.6 1.8 ~ 5.5 4M（2MHz @ 开漏），66M（33MHz @ 优化条件） NTS0302JK I²C、SPI、通用 2 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口，20米@推拉式排水口 NTS0304E I²C、SPI、通用 4 自动的 一致 0.95 ~ 3.6 1.65 ~ 5.5 2米@明排水口，20米@推拉式排水口 NTS0102 I²C、SPI、通用 2 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTS0104 I²C、SPI、通用 4 自动的 一致 1.65 ~ 3.6 2.3 ~ 5.5 50米 @ 推拉 NTB0102 SPI，通用 2 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 NTB0104 SPI，通用 4 自动的 不支持 1.2 ~ 3.6 1.65 ~ 5.5 7000万~8000万 P3A9606 I3C、I²C、SPI、通用 2 自动的 一致 0.72 ~ 1.98 0.72 ~ 1.98 （12.5MHz） P3A1604 I3C、I²C、SPI、通用 4 自动的 一致 0.72 ~ 1.98 1.62 ~ 3.63 6.8米（明排水），40米（推拉式排水） 表 1：博客中介绍的方法/零件编号对比   6. 参考资料 产品介绍页：电压电平转换器 NXP系统管理I2C、I3C、SPI选型指南 I2C总线规范和用户手册（版本5.0）（日语版） I2C总线规范和用户手册（版本7.0）英文版） NXP社区博客： I3C总线概述——下一代串行总线 日本网络研讨会视频： “您现在需要了解的下一代接口‘I3C’基础知识” Qiita @teddokano： PCA9306 的内部运作和运行 变更历史记录： 2025年8月28日：第一版 2025-08-28：添加了有关 NTS0304EUK-ARD 的信息以及包含视频的博客链接。 2026-04-10：修正表 1 中的低压侧 [V] 和高压侧 [V]。 2026-06-20：第 3.1 节“列：TTL 的 VIH（最小值）”新增“如何确定 VIL(max) = 2.0V 和 VIL(max) = 0.8V？”。新增标准 TTL 逻辑 IC 的内部电路示例：SN7400（2 输入 NAND 门）和 SN7420 的输出波形。 2026-07-10：在第 4.1 节中添加了图 15 中的电路也作为 Nexperia 应用笔记 AN10441 发布。 ========================= 即使您在本文的“评论”栏留言，我们目前也无法回复。 给您带来不便，我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 （如果您已经是NXP的代理商或与其有合作关系，可以直接向负责人咨询。） 本博客解释了数字电路中使用的各种逻辑电路（*TTL、*LVTTL、*CMOS）之间的电压电平差异，以及 VOH 、 VOL 、 VIH 和 VIL 对于识别它们的重要含义。 此外，我们将解释在各种转换方法中应该选择哪种电压电平转换器。 我们将仔细研究双向开漏信号的转换，这需要特殊的处理方法。 界面 介绍 日本博客

S32K148 FlexCAN2が動作しない こんにちは、 Eclipse OpenBSWプロジェクトを使用しながら、S32K148でFlexCAN2を有効にしようとしています。 FlexCAN0は正常に動作していますが、FlexCAN2は有効なフレームを送信しません。 構成： MCU: S32K148 CANインスタンス: FlexCAN2 ピン: PB12 → CAN2_RX (ALT4) PB13 → CAN2_TX (ALT4) 外部トランシーバ：MCP2551（5V電源） バス終端：合計約60Ω ビットレート：500 kbps（従来型CAN） 観察された行動： バス上ではエラーフレームのみが観測される ビットスタッフィングエラーが発生する ACKは受信されませんでした。 質問: MCP2551（5Vトランシーバ）は、S32K148 FlexCANのI/Oレベルと互換性がありますか？ PB12/PB13のALT4はFlexCAN2の正しいピンですか？ FlexCAN0とFlexCAN2の間には、考慮すべき特定のクロックまたは構成上の違いはありますか？ どのようなご指導もいただければ幸いです。 よろしくお願いします。 Re: S32K148 FlexCAN2 not working こんにちは、 @sousou54 さん。 1.MCP2551との互換性に問題は見当たりません。 2. はい。 3. 追加の設定は不要です。CAN0/1/2は同じクロックで動作します。 ノードのテストを段階的に試してみてください... トランシーバを使わずにTX/RXピン同士を接続してメッセージを送信してみてください。ACKが欠落しているため、メッセージが繰り返し表示されるはずです。TXエラーカウンタは0x80で、モジュールはエラーパッシブ状態です。それ以外の表示が出た場合は、PIN設定が間違っています。 TX/RXピンをトランシーバに通常通り接続し、バスからは切り離してください。メッセージを送る。上記と同じ画面が表示されるはずです。そうでない場合、トランシーバが無効になっているか、または終了していない可能性があります。 MCP2551のデータシートを見ると、RsピンをVssに接続して高速モードを選択する必要があることがわかります。 トランシーバを他のノード（例：CANツール）、メッセージの送受信。エラーが検出された場合、おそらくCANビットのタイミングが正しくないと考えられます。すべてのノードが同じビットレートとサンプルポイントを使用していることを確認してください。 以下のツールを使用できます: MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FD ビットタイミング計算。 最後に、これはカスタムボードですか、それともS32K148EVBを使用していますか？カスタムボードの場合は、 AN5426「S32K1xxのハードウェア設計ガイドライン」に記載されている接続を確認してください。 よろしくお願いします、 ジュリアン

RT1170 USB CDC は、実行されていないコードにブレークポイントを設定しても kStatus_USB_Busy で停止します。 こんにちは、 私は i.MX RT1170 (M7 コア) で以下の作業を行っています: SDKバージョン25.09 FreeRTOS USB CDC (仮想COM) CAN-FDの並列実行 初期化は正常です。 USB 列挙が正常に完了しました。 通常実行中は、CAN-FD と USB 通信は両方とも正常に動作します。 通常の状態でのシステムの動作: CAN-FDはデータを正しく受信します USB CDCはPC（Tera Term）にデータを正常に送信します USB_DeviceCdcAcmSend() は期待通りに動作します USBコールバックが実行され、ビジーフラグが適切にクリアされます 問題： プロジェクトの任意の場所にブレークポイントを配置すると、現在実行されていないコード内であっても (たとえば、初期化後の main() 内や関連のない関数内)、システムは実行を継続しますが、USB CDC は最終的に停止してしまいます。 重要な観察事項: ブレークポイントはヒットしていません。 コードは正常に実行され続けます。 FreeRTOS タスクは実行を継続します。 CAN-FD は正常に動作し続けます。 USB CDC のみが機能を停止します。 この現象が発生すると、次のようになります。 USB_DeviceCdcAcmSend() は kStatus_USB_Busy を返します USB転送コールバックが呼び出されない ビジーフラグが消えない ボードをリセットするまでUSB通信は永久に停止します 実行時に printf() を使用した場合でも、同様の動作が引き起こされることがあります。 構成： #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 2 #USB_DEVICE_INTERRUPT_PRIORITY (6U) を定義します。 USBタスクスタックサイズ: #APP_TASK_STACK_SIZE を 8000L と定義します スタックオーバーフローは発生しません。 システムはクラッシュしません。 USB CDC 通信のみが停止します。 質問: 実行されていないコードにブレークポイントが設定されている場合でも、USB CDC が停止するのはなぜですか? デバッガーは、USB HS タイミングに影響を与えるような方法で M7 コアを一時的に停止しますか? USB 割り込みの遅延サービスにより、CDC ドライバが永続的に kStatus_USB_Busy 状態のままになる可能性はありますか? これは、CPU が停止したときの USB HS コントローラ (EHCI) の予想される動作ですか? 転送の破損を起こさずに RT1170 上の USB CDC をデバッグするための推奨方法は何ですか? どのようなご指導でもいただければ幸いです。 よろしくお願いします。 USB Re: RT1170 USB CDC stuck in kStatus_USB_Busy even when breakpoint is placed in non-executing code こんにちは@Harisha 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 問題に関しては、次の調整を試すことをお勧めします。 1：USB がタイムリーな割り込みサービスを確実に受信できるように、USB 割り込み優先度を FreeRTOS が管理できる最高の優先度に設定します。 2：他のモジュール（アプリケーション内の CAN-FD など）の割り込み優先度を下げて、USB プロセッシングが停止しないようにします。 これらの変更を試して、もう一度テストしてください。   よろしくお願いいたします。 メイリュー  

Arducam B0353 Camera Integration with i.MX93 Dear Team, We need to integrate the Arducam B0353 MIPI 2-lane camera (https://www.arducam.com/arducam-full-hd-color-global-shutter-camera-for-raspberry-pi-2-3mp-ar0234-wide-angle-pivariety-camera-module-b0353.html) with the i.MX93 / i.MX9352 platform. We are new to this platform and would like to know the procedure for camera integration. If anyone has already integrated this camera (or a similar MIPI CSI-2 camera), please share: Integration steps Driver details Device tree configuration (if available) Looking forward to your support. Regards, Ajnas C Re: Arducam B0353 Camera Integration with i.MX93 I couldn't open the link, based on your link name description, the camera is ar0234? for the dts, you can refer to the imx93 dts as below which uses AP1302,  https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts for the camera driver, nxp doesn't offer this, need customer ask for the vendor, you also can check if current bsp has your camera driver or not https://github.com/nxp-imx/linux-imx/tree/lf-6.12.y/drivers/media/i2c

Cortex-M33 上的 i.mx93 LPSPI + eDMA 问题 我使用的是 Tria i.MX9332（B1 硅）SMARC 模块，并尝试在 Cortex-M33 上使用带有 eDMA 的 LPSPI6，但无法正常工作。 开发环境 VS 代码 1.109.0 用于 VS 代码扩展的 MCUXpresso 26.1.56 SDK 25.09.00 硬件 在定制载板上试用 SM2S-IMX93 通过 SPI（LPSPI6）连接带有ILI9341控制器的 LCD 现状 使用不带 DMA 的 LPSPI6 时，显示正常。 我试图切换到LPSPI6 + eDMA以提高吞吐量，但无法收到完成通知。 问题 基于 DMA 的传输似乎开始了，但我从未在传输结束时收到 LPSPI DMA 完成回调。 详细信息和相关代码/配置见附件。 有人能指出我可能遗漏了什么，或者为什么没有触发信号吗？ Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 感谢您提供的示例代码。回顾范例让我明白了这一点。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 你好@albi84 请参考附件中的补丁文件配置 LPDPI 与 EDMA B.R Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 你好 能否请您分享带有 eDMA 的 LPSPI 的骨架？ 谢谢。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 这不是一个骨架，而是我使用的实际代码。这有帮助吗？

RDMMA845X issues with Win 7 Pro. As a retired electronics man (but total newbie with PC + dev. boards) I hope this isn't too much of a stupid question. I have bought the above board. It works great on a Win 8.1 PC, but not on the Win 7 Pro PC - which is a shame because that's the one in my hobby lab! Win 7 finds the USB device and the Demo Screen correctly identifies the chip in use, etc. But hitting any of the 'lit' buttons just generates an Exception Handler window and I can go no further than that. I don't know what Ex Handler means so am at a loss! Wisdom greatfully accepted. Tks. John Accelerometers Re: RDMMA845X issues with Win 7 Pro. As an addition to my original post I should say that the exception window calls this an "unhandled exception". After some internet research I updated the .net framework to the latest ver (4.6.2) in case that was the cause. But it is not! Tks. J 

在 MIMXRT685-EVK 上配置 8CH-DMIC 板、闪存和测试 您好， 我正在尝试使用 8-DMIC 阵列板在 EVK-MIMXRT685 上运行 dmic_multi_channel CM33 演示。 根据演示文档，在 J31 上启用 8-DMIC 板需要移动多个电阻器（例如R379、R380、R384、R389、R390、R391、R392 至 2-3）。执行此操作后，FlexSPI 八进制闪存 (U19) 变得无法访问： -LinkServer 闪存失败 -ROM ISP (blhost) 已连接，但是 FLEX-SPI-或非显示扇区大小 = 0 /页面大小 = 0-无法擦除/写入闪存 我的问题是： 该演示能否在不使用八进制闪存（仅使用内存的工作流程）的情况下运行？ 更换电阻器后是否有官方的闪存/启动程序？ 是否所有电阻器都需要更改，还是某些电阻器可以保持默认状态以保证 FlexSPI 闪存工作？ 现在看来所需的DMIC硬件设置会阻止正常的闪存编程/启动。如何测试和运行演示程序？ 感谢您的指导。 MIMXRT685-EVK 8通道-麦克风 i.MX RT600 Re: 8CH-DMIC board configuration, flashing and testing on MIMXRT685-EVK 你好@mlkezarev、 非常感谢您关注我们的产品并使用我们的社区。 问题 1：该演示能否在不使用八进制闪存（仅使用内存的工作流程）的情况下运行？ A1: 是的。该演示设计为仅通过 SRAM 运行，不需要八进制闪存。 问题2：更换电阻器后是否有官方的闪烁/启动程序？ A2: 电阻器更改后，外部闪存将被物理断开。 因此，此硬件配置不支持闪存刷新或从闪存启动。 问题 3：是否所有电阻器都需要更改，还是某些电阻器可以保持默认状态，以保证 FlexSPI 闪存工作？ A3： 如果要启用 8 个 DMIC，则需要更改所有指定的电阻。 我已经发布了引脚配置屏幕截图供您参考。 问题 4：现在看来所需的DMIC硬件设置会阻止正常的闪存编程/启动。如何测试和运行演示程序？ A4：您可以在 SRAM 上运行，就像 SDK 演示一样"evkimxrt685_dmic_multi_channel_cm33" 顺祝商祺！ MayLiu

RT1040 ADCの問題 IMXRT1040RMに従い、ADC入力信号のGPIOキーパーを無効にします。 ADC 入力 gpio が NC の場合、ADC 読み取り値は異常であり、NC 入力ピンはマルチメーターで測定して 0V になります。 NTC 温度センサにコネクテッドされた別の ADC チャネルがあります。ADC 読み取り値は正常です。 ADC GPIOピン構成をデフォルトに設定すると（ IOMUXC_SetPinConfig(ADC_PIN、0x10B0U))、これはキーパー有効をデフォルトで設定し、NC である入力チャネルの ADC 読み取り値はほぼゼロになります。今回は仕事です。 SO、ADC 入力信号の GPIO の Keeper 機能を無効にする必要がありますか? アナログ（ADC、CMP、DAC、オペアンプ） Re: RT1040 ADC issues こんにちは、メイ: モジュールがコネクテッドではない場合、ADC はフローティングになるように設計されています。モジュールはオプションです。 「ECKMIMXRT1040_ADC_12B1MSPS_SAR_POLLING」に従って、GPIO_AD_B1_04 の ADC 入力ピンをキーパー機能が無効に設定されます。 NC ADC 入力ピンは 0V として測定されますが、キーパーが無効になっている場合、ADC 読み取り値は 0.6 または 0.7V になります。 キーパーがデフォルトで有効になっている場合、ADC の読み取り値はほぼ 0V になります。この方法により、ADCの読み取り値をモジュール検出として使用することができます。 では、キーパーを有効にするとどのような副作用があるのでしょうか。 オプション モジュールの自動検出が必要なので、NC である ADC 入力ピンを読み取るにはどうすればよいですか? Re: RT1040 ADC issues こんにちは@Xiao_Liuさん 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 ご質問に関してですが、   はい。ADC 入力ピンの場合、キーパー機能を無効にする必要があります。 NXP SDK デモ PIN 設定を参照してください。   ADC チャネルは浮いたままにしないでください。ピンが NC の場合、変換結果は未定義になります。 キーパーを有効にすると、読み取りが安定しているように見えますが、信頼できる解決策ではなく、推奨される解決策でもありません。   お役に立てれば幸いです よろしくお願いいたします。 メイリュー Re: RT1040 ADC issues こんにちは@Xiao_Liuさん 最新情報をありがとうございます。 ADC ピンでキーパーを有効にすることはお勧めしません。キーパーは最後の状態を保持するため、ADC の読み取りが不正確になり、モジュール検出の信頼性が低下する可能性があります。 安定した正確な結果を得るには、ADC が接続されていないときに明確なデフォルト レベルを設定するために外部抵抗を追加することをお勧めします。 よろしくお願いいたします。 メイリュー Re: RT1040 ADC issues こんにちは、メイ わかった。ADC が接続されていない場合は外部プルアップを使用します。 ご協力いただきありがとうございます。 Re: RT1040 ADC issues こんにちは@Xiao_Liuさん 最新情報をありがとうございます。 この投稿があなたの質問への回答である場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ よろしくお願いいたします。 メイリュー

[RTD600 IP] S32K3X4EVB-T172 GPIOウェイクアップ このサンプル プロジェクトでは、WKPU + SIUL2 (GPIO) の基本機能を使用および構成する方法をユーザーに示します。 ------------------------------------------------------------------------------ * テストハードウェア: S32K3X4EVB-T172 (SCH-53148 REV B2) * MCU: S32K344 * IDE: S32DS v3.5 および S32DS v3.6.x * SDKリリース: RTD 6.0.0 * デバッガ: PE Micro * ターゲット: internal_FLASH ------------------------------------------------------------------------------ このサンプル ルーチンは、GPIO 割り込みウェイクアップ用に WKPU ユニットを構成します。これは最も単純な WKPU の例です。ピン PTB19 (WKPU42) はウェイクアップ用に構成されています。 ルーチンはSW5が押されるのを待機し、緑色の LED をオフにして、次の処理を実行する Wkpu_EnterStandby() 関数に入ります。 コアクロックを FIRC に切り替えます。 WKPU インスタンスを初期化します。 WKPU42 (PTB19) を設定します。 スタンバイ（または高速スタンバイ）状態になります。 SW6を押すと、MCU が起動してリセットし、 SW5が再度押されるかどうかをポーリングします。 この例は現状のまま提供されており、保証やサポートはありません。

PCIe：i.MX 95：分配多个 MSI IRQ 向量 您好， 我们在基于 i.MX95 的系统上使用 ATH12K Wi-Fi 模块，通过 PCIe2 实例连接。 在基于 linux-imx lf-6.12.y 的内核上，这个设置失败了，而在基于 lf-6.6.y 的内核上，它却能正常工作。 内核驱动程序成功请求并接收了 16 个 MSI 中断。但是，它随后无法启动 Wi-Fi 模块： [ 5.888139] ath12k_pci 0001:01:00.0：添加到 iommu 组 5 [ 5.888506] ath12k_pci 0001:01:00.0：BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0：启用设备 (0000-> 0002) [5.889315] ath12k_pci 0001:01:00.0：MSI 向量：16 [ 5.889334] ath12k_pci 0001:01:00.0：硬件名称： wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0：chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0：fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0：无法接收控制响应完成，轮询... [8.675241] ath12k_pci 0001:01:00.0：服务连接超时 [ 8.681002] ath12k_pci 0001:01:00.0：连接 HTT 失败： -110 [ 8.692180] ath12k_pci 0001:01:00.0：未能启动核心：-110 在使用不同的 PCIe 设备的内核邮件列表 [1] 上进行了相关讨论，但尚未确定我们系统的有效配置。 最好的办法是什么？ 感谢您的支持。 最大值 [1]https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 你好 i,MX95 还处于早期阶段，某些配置还没有设计出来。然而，您的 i.MX95（带 ATH12K，通过 PCIe2）在下列情况下出现故障 lf-6.12.y 但可在 lf-6.6.y 上运行提示新内核的 PCIe 或 Wi-Fi 堆栈存在回归或驱动程序交互变化，可能涉及 ATH12K 的 PCIe 电源管理单元 (ASPM)、MSI 映射或 PCIe 特定 PCIe 端点异常，通常可通过内核补丁或在较新内核的启动参数中禁用 ASPM 来解决；检查 dmesg 中是否有 PCIe 错误，比较设备树，并在 NXP/Linux 内核邮件列表中查找相关提交。  以下是潜在原因和故障排除步骤的详细介绍： 1.检查内核日志 （dmesg） 查找 PCIe 错误： 在失败的 lf-6.12.y 内核的 dmesg 中搜索"PCI","MSI","ATH12K","Error","Firmware", 或"Timeout" 消息。 固件加载：验证是否正确加载了 ath12k 固件，以及初始化过程中是否出现任何错误。  2。PCIe 电源管理单元 (ASPM) 常见问题：较新的内核通常默认启用主动状态电源管理 (ASPM)，这可能会导致嵌入式系统上的 ATH12K 等 PCIe 设备出现问题，尤其是较旧的固件/硬件。 尝试禁用 ASPM：将 p cie_aspm=off 添加到内核启动参数（例如，在 U-Boot 或 GRUB 中），然后再次测试。  3.Devicetree/DTB 的差异 比较 DTB： 生成并比较两个内核（.dtb 文件）中使用的设备树 Blob (DTB)。 查看 p ci2 的 PCIe 节点的变化，尤其是与中断、功率域或兼容性特性相关的变化。  4.内核驱动程序/固件回归 特定提交： lf-6.12.y 中的 ATH12K 驱动程序 ( ath12k)、 mac80211 或核心 PCIe/ARM 代码可能引入了一项破坏设置 的更改。 搜索邮件列表：查看 Linux 内核邮件列表 (LKML) 和恩智浦列表，了解相关补丁或有关 ath12k 、 i.MX95 和较新内核（6.12 以上）的讨论。  5.微星处理 中断重映射：在接收中断的同时，处理中断的方式（MSI-X 与 MSI、中断重映射）可能会发生微妙的变化。 检查 proc/interrupts 中的中断：查看不同内核的中断分布或计数是否不同。  6.固件 Blob 固件版本：确保为 ATH12K 使用正确的固件，并与较新内核的驱动程序兼容。有时，更新的驱动程序需要更新的固件。  总之，从 dmesg 开始，尝试禁用 ASPM；这些是导致嵌入式平台上较新内核出现 PCIe Wi-Fi 故障的最常见原因   此致 Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors 虽然这些建议是调试问题的好指导，但我找不到解决方案，也就是说，并非所有的 MSI IRQ 向量都触发了驱动程序中的 IRQ 例程。 最后，我改变了 ath12k 驱动程序，只请求一个 MSI IRQ，从而解决了这个问题。 请注意，当前的 Linux 主版本不存在这个问题。 此致 最大值