Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
frdm-i.mx93 无法在 M33 之后启动准备就绪;Linux 和 Windows 上的 UUU SDPS 启动超时 您好,恩智浦技术支持、 我正在请求帮助恢复 FRDM-i.MX93 主板。在 “M33 准备就绪” 之后,板在早期的 SPL 启动期间会立即停止,并且不会继续运行 BL31 或完全 U-Boot。在 SDPS 启动期间,UUU 恢复也会因超时而失败。 董事会详情: 板:FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的串行输出: U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok 重建的 2025 SPL 也出现了同样的停止点: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000) PMIC:PCA9451A PMIC:过载电压模式 DDR:3733MTS DDR:3733 MTS DDR:3733MTS M33 准备好了 使用的硬件设置: P1 = 外部电源,使用 45 W USB-C 墙式适配器进行测试 P16 = 调试串行控制台 P13 = microSD 卡插槽 P2 = 用于 UUU / 串行下载器模式的 USB-C 连接 我还测试了用墙壁适配器供电,而不是用电脑 USB 供电。行为没有改变。 测试的主机系统: Linux Mint / Ubuntu 主机 Windows 主机 已测试的 UUU 版本: uuu 1.5.141 uuu 1.5.243 主要问题是电路板达到 SPL,初始化 PMIC 和 DDR,然后打印 “M33 准备就绪”,然后什么也没发生。它永远不会达到 “正常启动”、“正在尝试从 BOOTROM 启动”、“注意:BL31” 或完整 U-Boot。从 SD 和 eMMC 启动时会发生这种情况。 在 USB 串行下载器模式下,UUU 会检测到主板: sudo ./uuu-lsusb 连接的已知 USB 设备 路径芯片 Pro Vid Pid bcdVersion 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 但是,在 SDPS 启动期间,UUU 会失败。使用的命令是 sudo ./uuu-V-b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst 在 Linux 系统上,故障是 启动 cmd: sdps: boot-scanterm-f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT 在 Windows 系统中,故障是 启动 cmd: sdps: 启动-scanterm-f。\ imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 14% 失败 HID (W):LIBUSB_ERROR_TIMEOUT (-7) 在 Linux 和 Windows 上进行了测试,结果相同。 测试过的图像: 我测试了恩智浦官方 frdm-i.mx93 Rev 4.0 演示映像包: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 启动映像哈希值为: 7aba6102e5ec64add64add632cd6667e77fa3f6f6f6f6f6f6fd72c314e4c01f2964c0fc056a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 我还测试了自己的 Yocto 镜像 imx93frdm,它使用相同的启动映像哈希值。 我验证了 SD 启动选择是否有效。在未插入 SD 卡的 SD 启动模式下,没有串行输出。在插入 SD 卡的 SD 启动模式下,SPL 在 “M33 准备就绪” 时开始和停止。因此,SD 启动开关似乎正在工作。 我还验证了恩智浦官方的 .wic映像包含预期偏移量为 32 KiB/0x8000 的启动映像。使用的命令 wic=nxp.wic 启动=imx -启动-imx93frdm-sd.bin-flash_singleBoot xxd -l 64 -s $((32*1024))"$WIC" xxd -l 64 -s 0"$BOOT" cmp-n " $ (stat-c%s " $BOOT ") "-i $ ((32*1024)): 0 " $WIC " " $BOOT " & & echo " " NXP WIC 包含 32K 的启动映像" 恩智浦 WIC 不包含 32K 的启动映像 " 结果: 恩智浦 WIC 包含 32K 的启动映像 因此,SD 映像似乎正确包含了启动容器。 为了排除只有 2024.04 SPL 映像是问题所在,我使用 Flexbuild/U-Boot 构建了一个更新的启动映像。内置映像中的 SPL 显示: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000)恩智浦 FRDM-IMX93 我将这个新的 flash.bin 文件写入 SD 卡,偏移量为 32 KiB: sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync 然后,主板打印了新的 SPL 标语,确认它正在执行新的 SD 启动映像: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000) PMIC:PCA9451A PMIC:过载电压模式 DDR:3733MTS DDR:3733 MTS DDR:3733MTS M33 准备好了 但是,它仍然在同一时间停止了,没有继续使用BL31/Full U-Boot。 eMMC 状态: 最初,eMMC 启动到足以登录 Linux 的程度,但由于根文件系统中缺少 /bin/sh,根登录被中断。在尝试恢复过程中,eMMC 使用 .wic 文件从 SD Linux 重写。图像之后,在 “M33 准备就绪” 之后,eMMC 启动也会停止。但是,使用恩智浦官方镜像启动SD时以及重建的2025 SPL也会出现同样的停止点,因此当前的问题似乎早于Linux/rootFS。 我所相信的已经被排除: 串行端口错误:串行端口正常工作并显示 SPL 输出。 电脑电源不良:使用外置 45 W 墙式适配器测试。 错误的 SD 启动开关:没有 SD 卡的 SD 启动模式没有输出。 SD 映像中缺少启动映像:经过验证的启动映像存在于恩智浦官方 WIC 中的 0x8000/32 KiB。 Linux/rootFS 问题:故障发生在 BL31/Full U-Boot/Linux 之前。 UUU 的主机操作系统问题:UUU SDPS 启动超时出现在 Linux 和 Windows 上。 只有旧的 2024 SPL 是坏的:重建的 2025.04 SPL 也在 "M33 准备就绪 "后停止。 你能帮忙确定这是否是已知的 frdm-i.mx93 提前启动问题吗? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你在使用我们发布的 BSP 版本吗? 适用于i.MX应用处理器的嵌入式Linux|恩智浦半导体 您正在使用并选择哪个版本的 BSP? 劳动节回来后,我会尝试在我们的电路板上进行测试,我将在下周三回到办公室然后进行测试,然后给你回复我的测试结果。 祝您有美好的一天 顺祝商祺! Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我使用的是 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93。图像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我回到办公室将在我们的板上进行测试,然后告诉你结果。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你想出来了吗?
查看全文
如何转换数字信号的电压?(日语博客) 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引脚可以通过配置提供这种输出。如果输出固定为推挽输出且无法配置为开漏输出,则需要外部晶体管或类似器件将其转换为开漏输出。 此外,上拉电阻的选择也很重要。 为了获得高电压,需要使用上拉电阻,但如果电阻值太小,输出为低时流过的电流就会很大(类似于重负载),这将增加功耗,导致 电压 升高。 相反,如果该值过大,则会受到线路和引脚电容的影响,导致从低电平到高电平的上升时间变慢,从而降低通信速度。 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)。 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 的输出波形。 ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 本博客解释了数字电路中使用的各种逻辑电路(*TTL、*LVTTL、*CMOS)之间的电压电平差异,以及 VOH 、 VOL 、 VIH 和 VIL 对于识别它们的重要含义。 此外,我们将解释在各种转换方法中应该选择哪种电压电平转换器。 我们将仔细研究双向开漏信号的转换,这需要特殊的处理方法。 界面 介绍 日本博客
查看全文
S32K312MINI-EVB Segger JTAG-SWD接続エラー こんにちは、S32K312MINi EVBを持っています。SWD/JTAG経由でこれをプログラムしようとしています(opesdaが搭載されていることは知っていますが、私のカスタムPCB設計には搭載されません)。 接続しようとすると、次のエラーが表示されます。 不明なSDA AP IDが検出されました: 0xFFFFFFFF 不明なSDA AP IDが検出されました: 0xFFFFFFFF InitTarget() 終了 - 1.09秒かかりました ****** エラー: J-Link スクリプトファイル関数 InitTarget() がエラーコード -1 を返しました   R0と消去を試しましたが、うまくいきませんでした Re: S32K312MINI-EVB Segger Jtag-SWD connection error こんにちは、 ご返信ありがとうございます。 Seggerソフトウェアの最新バージョンを使用していますが、vrefが3.3Vになっているのを確認しています。 ピンもテストしましたが、配線は正しいです。リセットボタンは、複数のテスト段階において押し続けられました。 JTAGも、チップとの接続に失敗したというエラーコードを出力しています。 速度を落とそうともしましたが、効果がないようです。 PC上でS32用のjlinkscriptを探してみましたが、見つかりませんでした。どこにあるのでしょうか? Re: S32K312MINI-EVB Segger Jtag-SWD connection error こんにちは、 エラー: J-Link スクリプトファイル関数 InitTarget() がエラーコード -1 を返しました。 J-LinkはターゲットMCUの初期化手順を正常に実行できず、初期化スクリプト(InitTarget())が失敗しました。 初期化に失敗したため、デバッガーはデバイスと通信できません。 このメッセージは、J-Linkが接続のごく初期段階でDAP(デバッグアクセスポート)にアクセスできない場合に表示されます。 「不明なSDA AP IDが検出されました: 0xFFFFFFFF」 InitTarget() 関数は、SEGGER が使用する J-Link スクリプト ファイル (.JLinkScript) の一部です。 時計を設定する デバッグインターフェースを起動する MEM-AP / AHB-AP の設定 デバイス固有の設定を実行する デバッグに必要なアクセスが失敗した場合、SEGGER はスクリプトを中止し、エラー -1 を返します。 解決策の概要 J-Linkソフトウェアをアップデートする SEGGER社はS32K31xのアルゴリズムにバグがあることを確認した。 J-LinkへのVTref(3.3V)を確認してください。 VTrefが欠落しているため、AP ID = 0xFFFFFFFF → InitTargetが失敗します。 SWD配線を確認する SWD_DIO、SWD_CLK、RESET、およびGNDが正しく接続されていることを確認してください。 リセットして接続し、SWD速度を下げてください。 ファームウェアがピンを早期に再構成してくれると助かります。 SWDモードの代わりにJTAGモードを試してください 同様のNXPデバッグエラーで提案された解決策です。 よろしくお願いします、 ピーター
查看全文
Imx8xm IPC A53 cores I am trying to use the Rmesg lite library to send messages from A53 core 1 to A53 core 2. I will be using the MU in both cores to synchronize the core messaging. Is this feasable, and is there any example of this protocol on github? I am using the IMX8mm Som It has to be secure i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Imx8xm IPC A53 cores Hi @rheslar1  Please refer 3 Heterogeneous Multicore Framework in below guide. https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf Best Regards, Zhiming
查看全文
UART プロトコル テスト MCXN546VKL で、while (0U == (base->STAT & LPUART_STAT_TDRE_MASK)) で停止しました。 こんにちは。私は NXP の初心者です。IoT モジュールへの UART PIO8 および PIO9 ピンを備えた MCXN546VKL PCB を使用して、MCUXpresso IDE で LPUART プロトコルをテストしようとしています。その前に、UART ポーリングと DMA の TX および RX 機能をテストしようとしています。ポーリングモードのシンプルなループバックUARTテストで、UART TX経由でサンプルデータを送信しようとすると、fsl_lpuart.cファイルの「while (0U == (base->STAT & LPUART_STAT_TDRE_MASK))」で停止してしまいます。FLEXCOMM4に12MHz、システムクロックに150MHzを指定しているのですが、なぜこのようなことが起こるのでしょうか。設定のスクリーンショットの.pngファイルをこの投稿に添付しましたので、ご確認の上、詳細をお知らせください。ありがとうございます。 クロック|タイマー 通信と制御(I3C | I2C | SPI | FlexCAN | イーサネット | FlexIO) 開発ボード MCX N 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya   MCXN デバイスでは、UART モジュールが実際にクロックされ、TX FIFO レベルが構成された TX ウォーターマーク以下の場合にのみ、TDRE ビットが 1 になります。 FlexComm クロックを有効にしていただいてもよろしいでしょうか? mcxn547 sdk lpuart デモを参照できると思います。   BR ハリー 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Harry_Zhang 、私は MCXN546VKL PCB ボードを持っていますが、あなたの指示に従って、MCXN547V の SDK からの LPUART ポーリングのサンプル ファイルを使用して、uart ピンの同じピン PIO8 と PIO9 を使用し、clock_config.c 内でプロセッサのGlobalInfoと package_id を MCXN456VKL に手動で変更しました。そして pin_mux.c。 プロセッサ: MCXN546 パッケージID: MCXN546VKL プロジェクトをビルドすると、エラーは発生せず、UART ポーリング操作の送受信は正常に行われますが、それでもピン構成設定内でエラー通知が表示されます。問題ツール: MCUconfiguration に表示される通知とエラーの問題のスクリーンショットを共有しました。 構成ページからエラー通知を削除するには、構成でプロセッサ設定も MCXN547 から MCXN546 に変更して、エラーをすばやく修正するにはどうすればよいですか。スクリーンショットを確認し、解決策を更新してください。前もって感謝します。 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya あなたの以前の投稿を確認しました。 clock_config.c 内のプロセッサの GlobalInfo と package_id を MCXN456VKL に手動で変更しました。および pin_mux.c。 プロセッサ: MCXN546 パッケージID: MCXN546VKL" この方法は間違っているため、エラーが報告されます。現時点では、このエラーを防ぐ方法はありません。 まず、MCXN546とMCXN547は、GPIOの数とフラッシュRAMのサイズ以外はほとんど同じです。 上記のメッセージに基づきます。私には2つの提案があります。 1.MCXN546 SDKをベースにプロジェクトを作成する場合は、mcxn5xxevk_lpuart_pollingをベースにいくつかのファイルを変更するだけで、設定ツールを直接使用できます。 2. mcxn5xxevk_lpuart_polling をベースとして使用する場合は、config tool を直接使用することはできません。しかし、別のmcxn546プロジェクトを作成し、設定ツールを使用して必要なピンとクロックを設定し、生成されたコードをプロジェクトmcxn5xxevk_lpuart_pollingにコピーすることもできます。 BR ハリー 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya 返信が遅くなり申し訳ありません。mcxn946 SDKパッケージをベースにしたFreeRTOSプロジェクトを作成してみましたか?   BR ハリー 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは、 @Harry_Zhang さん。上記の問題について、アップデートと解決策を教えていただけないでしょうか。startup_mcxn546_cm33_core0.c でプロジェクトを実行する必要があります。startup_mcxn547_cm33_core0.c で実行する代わりに。手動で作成すると、UARTとMCUでクロック設定の問題が発生します。プロセッサとクロックをmcxn547からmcxn546に手動で変更しましたが、起動ファイルに変更を加えることができず、チップ構成ページにもプロセッサのエラー警告が表示されました。もしくは、mcxn546構成でFreeRTOSを使用したUARTポーリングおよびDMA動作のテストコードを含む、私のシンプルなプロジェクトを提供してください。上記の件について、最新情報をお知らせください。ありがとう。 回复: In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは、 @Harry_Zhang さん。mcxn546 や mcxn946 では作成していませんが、最初に mcxn546 で基本的な UART 操作を実行しようとしましたが、動作せず、UART と MCU でクロックの問題が発生しました。そこで、SDKからmcxn547のUARTポーリングのサンプルプロジェクトを作成し、pin_mux.cでプロセッサとパッケージIDを手動で変更しました。および clock_config.cmcxn546 MCU向けに構築・製造する。私のmcxn546ボードでは、UARTデータの送受信が行われています。しかし、startup_mcxn547_cm33_core0.c で実行されており、.mex のピン構成ページに表示されます。下記にファイルを示します。 startup_mcxn546_cm33_core0.c で実行して、config のこのエラーを解消する必要があります。この投稿にプロジェクトを添付しましたので、ご確認ください。 問題: MCUXpresso_IDE プロジェクトで検出されたプロセッサ「MCXN547」が、現在選択されている「MCXN546」と一致しません。 レベル: エラー
查看全文
带有 C++ S32DS 项目的 SDK <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 如何使用 S32 SDK 创建 C++ S32DS 项目? (我正在尝试使用 S32K144 EVB)。 谢谢! 尼科拉 S32K1系列的S32SDK Re: SDK with C++ S32DS project 对不起,对于新项目,我仍在使用曾经创建过的项目副本,所以我不记得具体步骤了,但我检查了原始 C (SDK) 链接器文件和 C++(非 SDK)链接器文件的差异,并将 C++ 链接器文件中的部分添加到 C 项目(现已转换为 C++ 项目)的旧文件中。我已经有了一些经验,所以这对我来说并不难。 或许也可以使用 C++ L.F.,只需从 SDK 项目中添加正确的内存部分即可。 也许彼得提供的链接会对你有所帮助。我认为您只需调整 S32K358 链接器文件中的内存大小/位置即可。 Re: SDK with C++ S32DS project 请参阅本帖: https://community.nxp.com/t5/S32K/S32K358-C-project-based-on-S32DS3-5/m-p/2058809#M46635 Re: SDK with C++ S32DS project 看来到了 2026 年,这个问题依然存在,我们依然需要这种解决方法。 下一步 - 创建不含 SDK 的 C++ 项目,并将其链接器文件复制到含 SDK 的项目中。 您能具体介绍一下您是如何一步步完成的吗?例如,您是否删除了带有 SDK 的项目(基于 C 的恩智浦 S32DS 项目)中的旧链接器文件,然后用 C++ 项目中的链接器文件替换了它们? Re: SDK with C++ S32DS project 请参阅本帖: 关于基于 S32DS3.5 的 S32K358 C++ 项目 - NXP Community Re: SDK with C++ S32DS project 大家好 你们能详细介绍一下诺瓦利斯给出的提示吗?我尝试用 SDK 创建 C 项目并将其转换为 C++,但没有成功。 谢谢! Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好, ,我可能找到了方法,这样就不必在构造函数中使用 new() 了 只需在 main.c 中添加 __libc_init_array(); 调用即可。 void __libc_init_array(void); void main(void) { __libc_init_array(); main_app(); // 如上所述 } 现在 cObject 对象(构造参数); 似乎运行正常。 Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好,特拉维斯、 请参阅 Martin 的说明来构建与您的 C 代码兼容的 C++ 应用程序项目。它对我很有效,但有两个小缺点: (1) 您必须将生成的代码保存在另一个 C 应用程序项目中,然后复制粘贴到您的 C++ 项目中。 (2) 为 C++ 项目设置包含路径在开始时可能会很麻烦。也许有更简单的方法。 干杯, 梓潼 Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,马丁、 感谢您的答复!我用 S32 SDK 在 C 语言中创建一个 C++ 项目的路径也差不多。 我关注这篇文章来封装 C++ 对象以便它们可以在 C 代码中使用:教程:如何将 C++ 库/类集成到 C 程序中-Teddy Engineering GmbH 我还读到,如果使用 freeRTOS,建议使用 ``pvPortMalloc()`` 和 ``pvPortFree()`` 来覆盖 ``new`` 和 ``delete```:无法正确创建新对象 - FreeRTOS 干杯, 梓潼 Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我对此也非常好奇。在某些应用程序中,使用面向对象的基本原理更容易编写和维护更简洁、无错误的代码,而使用 C++ 则要容易得多。如果能更直接地提供这种支持,而不需要所有的步骤,生活就会轻松很多。 我更愿意使用恩智浦工具,但我觉得这限制了我。 Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我的做法是,使用 SDK 创建普通 C 项目,然后将文件/新建/转换为 C/C++ 项目 然后你必须进入项目属性、C/C++ 版本/设置/标准 S32DS C 编译器/包含,然后复制必要的行并将其粘贴到 C++ 编译器/包含中 下一步 - 创建不含 SDK 的 C++ 项目,并将其链接器文件复制到含 SDK 的项目中。 然后,我创建了 main_app.cpp,将函数 main_app() 定义为 extern"c" ,并从 main.c 中的 main() 函数调用 main_app(),然后我就可以从 main_app()调用 C++ 类了。 现在我可以编译它,应用程序似乎也可以工作,我还可以使用处理器专家等...... 我发现的唯一问题是,像这样使用构造函数: cObject object(constructor params); 并不能像预期的那样 我必须使用 cObject *object = new cObject(constructor params); Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,吉日、 请允许我提出一个后续问题:如果我真的需要在 S32K 项目中使用一些 C++ 代码,您有什么建议?到目前为止,我想到了以下几种可行的方法: 1.使用 S32K DS 以外的其他编译器。 2。将 C++ 代码构建到与 C 兼容的静态库(包含封装器等)中,然后将其添加到 S32K DS 中的 C 项目中。 非常感谢、 梓潼 Re: SDK with C++ S32DS project <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,尼古拉 遗憾的是,S32DS 不支持在 S32K SDK 中使用 C++。 Jiri 
查看全文
[Introduction to NXP Microcontrollers] [Motor Control] [Basics Part 3] How Permanent Magnet Synchronous Motors Work and How to Control Them (Japanese blog) table of contents   [Introduction to NXP Microcontrollers] [Motor Control] [Basics Part 3] Mechanism and Control Method of Permanent Magnet Synchronous Motors The unsung hero! What are Clark Transform and Park Transform? It all began with the complex waves of three-phase AC Step 1: Clarke Transformation - Simplifying 3D into 2D Step 2: Park Transformation - "The Magic of the Merry-Go-Round" - Freeze the Moving World Why go through such a tedious conversion process? What are the huge benefits? Summary: The power of mathematics to manipulate complex waves at will [Introduction to NXP Microcontrollers] [Motor Control] [Basics Part 3] Mechanism and Control Method of Permanent Magnet Synchronous Motors The unsung hero! What are Clark Transform and Park Transform? Hello! When an electric vehicle (EV) takes off smoothly and a high-performance air conditioner operates surprisingly quietly, microcomputers perform complex calculations at ultra-high speeds and skillfully control the motor. This time, let's unravel the mysteries of the "Clark Transformation" and the "Park Transformation" (transformations named after two great experts who work in " vector control ," the heart of control technology), with the GIF animation below! (function() { var wrapper = document.getElementById('lia-vid-6377224605112w540h540r855'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (View My Videos) It all began with the complex waves of three-phase AC First, the top row. This is the world of three-phase AC , the basic energy required to run a motor. Graph on the right (Three-Phase Sine Waves) : Three waves, A, B, and C, are constantly changing in magnitude and direction as they flow. These three waves are interconnected, but as they are, it is extremely difficult to intuitively determine how much force should be applied to the motor at any given time. It's like trying to conduct three musicians who are each playing different pieces of music at the same time. Left graph (Rotating Vector) : However, when the forces of these three waves are combined, something interesting happens. A single force ( rotating vector ) is created that rotates smoothly and constantly, while maintaining a constant magnitude. Physically, this is the " rotating magnetic field " created by the stator coil. It is this rotating magnetic field that attracts the rotor magnet and is the source of the force that turns the motor. Problem: How can we easily and accurately control these "three constantly changing waves" using a microcontroller? Step 1: Clarke Transformation - Simplifying 3D into 2D The first magic is the " Clark transformation ," which transforms a complex 3D world into a more understandable 2D world. The calculation formula is as follows: In normal motor control, the following simplified formula is used, assuming amplitude invariant transformation (K=2/3) and balanced three-phase (i_a+i_b+i_c=0).   ​ The graph on the right (Two-Phase Sine Waves α-β) : Look! The three waves have been consolidated into two waves, α (alpha) and β (beta). The wave shape (alternating current) is still there, but one variable has been removed, making it much easier to see. Graph on the left (Clarke Transformation α-β) : This shows the world as seen from two axes (α, β) that intersect at right angles to the rotation vectors seen from three axes (A, B, C). It's like turning a solid object seen from an angle into a flat view from directly above. The rotation vector itself continues to rotate in the same way without any change. [Key points of Clarke conversion] Without losing any information, we simplified the problem by converting from the somewhat difficult to handle three-phase coordinate system to Cartesian coordinates (α-β stationary coordinate system), which are familiar from mathematics. Step 2: Park Transformation - "The Magic of the Merry-Go-Round" - Freeze the Moving World The values of α and β are still changing like waves, and it is difficult to keep track of them. This is where the essence of vector control, the " Park transformation ," comes in! The calculation formula is as follows: ​​ This is a major shift in thinking : "Let's stop looking at the rotating vector from the stationary ground (α-β coordinates) and jump on a merry-go-round that rotates at the same speed as the rotating vector!" This new rotating coordinate system is called the " dq rotating coordinate system ." Right graph (Two-Phase Value dq) : What an amazing result! The two waves that had been changing so drastically have now turned into **almost constant values (direct current)** called d and q! Left graph (Park Transformation dq) : You can see that the dq coordinates rotate in perfect synchronization with the rotation vector. If you stand right next to a horse on a merry-go-round, the horse appears stationary to you, right? It's the exact same principle. From the perspective of the rotating object, it appears stationary. [Points to note about park conversion] By observing from a coordinate system (dq coordinates) that rotates at the same speed as the rotating vector, AC values can be treated as DC values. Why go through such a tedious conversion process? What are the huge benefits? This two-step transformation brings us a tremendous benefit: overwhelming simplification of control . Controlling constantly changing AC values is difficult, but what about DC values? If it's higher than the target value, lower it; if it's lower, raise it. With this simple operation (PID control) that even an elementary school student can understand, you can achieve perfect control of a motor. The DC values of d and q each have an important physical meaning. q-axis value (Quadrature-axis): This directly controls the motor's torque (rotational force). When you step on the accelerator of an EV, the car accelerates sharply because the microcomputer is raising the target value of this q-axis. It is truly a "power dial." d-axis value (Direct-axis): Controls the motor's magnetic flux (magnet strength). In the case of a permanent magnet motor, the strength of the rotor magnet is constant, so basically it is most efficient to control the d-axis current to zero. It is truly an "efficiency dial." In other words, the Clarke and Park transformations are magical in that they separate the "power" and "efficiency" elements of a motor, which are normally mixed together, into two independent DC dials (d and q) . Summary: The power of mathematics to manipulate complex waves at will The complex wave of three-phase AC creates a rotating force (rotation vector) inside the motor. Clarke transformation simplifies the problem by redrawing the three-dimensional world into two dimensions (α-β). The park transformation involves riding on a rotating merry-go-round (dq coordinates) and converting AC values into DC values. The DC torque (q) and magnetic flux (d) values can be easily and accurately controlled using a PID controller! This series of elegant mathematical processes is the basis of "vector control," which supports modern high-performance motors. It is this magic that allows us to enjoy the full benefits of powerful, quiet, and energy-efficient motors. Thank you for reading to the end! If you would like to read the next basic chapter, click here ↓ [Basics Part 4] Practice! Let's see how vector control works using a block diagram! Click here for an explanation of the specific setup method and how to run the sample code. [Introduction to NXP Microcontrollers] [Motor Control] [Practical Part 1] Mechanism and Control Method of Permanent Magnet Synchronous Motors (Japanese blog) Here is a website that compiles articles about NXP motor control: NXP Motor Control - Summary Page - (Japanese blog) =========================​ We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may contact the person in charge directly. ) This article will provide an easy-to-understand explanation of motor control using the NXP FRDM board "FRDM-MCXA156." It is divided into a basic section and a practical section, so we hope you will refer to the section that interests you. ・Basics ①~⑦, Practical ①~③ This time, as part 3 of the Basics, we will explain the mechanism and control method of permanent magnet synchronous motors using NXP microcontrollers. MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX Motor Control Technology Focus Japanese Blog
查看全文
TDA8035 运行模式下的 IDD (INTF) 电流消耗 大家好,团队, 当 TDA8035 处于运行模式时,VDD (INTF) = 3.3 V 时 VDD (INTF) 的近似功耗是多少? 顺祝商祺! 西尔万 Re: TDA8035 IDD(INTF) current consumption in active mode 你好@sylvainbouriot TDA8035 的大电流通路(板卡电源、VCC 限流、DC/DC)均位于 VDDP 中,与 VDD (INTF) 无关。 VDD (INTF) 主要负责数字控制逻辑、I/O 参考和时钟分频控制。其功耗非常低。 运行模式下的 IDD (INTF) 通常在 1 到 3 mA(典型值)的范围内。
查看全文
Cortex-M33 における i.mx93 LPSPI + eDMA の問題 私はTria i.MX9332 (B1 シリコン) SMARC モジュールを使用しており、 Cortex-M33 上の eDMA で LPSPI6 を使用しようとしていますが、動作しません。 開発環境 VSコード 1.109.0 VS Code拡張機能26.1.56用のMCUXpresso SDK 25.09.00 ハードウェア カスタムキャリアボード上のTria SM2S-IMX93 SPI (LPSPI6) 経由でコネクテッドされたILI9341コントローラを備えた LCD 現在の状況 DMA なしで LPSPI6を使用すると、ディスプレイは正常に動作します。 スループットを向上させるためにLPSPI6 + eDMAに切り替えようとしていますが、完了通知を取得できません。 問題 DMA ベースの転送は開始されたように見えますが、転送の終了時にLPSPI DMA 完了コールバックを受信しません。 詳細および関連するコード/構成は添付ファイルにあります。 何が欠けているのか、またはコールバックがトリガーされない理由を誰か指摘してもらえますか? Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 こんにちは@albi84 EDMAを使用したLPDPIの設定については、添付のパッチファイルを参照してください。 BR Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 サンプルコードをありがとうございます。例を確認することで、うまく動作するようになりました。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 こんにちは、 LPSPI と eDMA のスケルトンを共有していただけますか? ありがとうございます。 Re: i.mx93 LPSPI + eDMA problem on Cortex-M33 これはスケルトンではなく、私が実際に使用するコードです。これは役に立ちますか?
查看全文
Creating SREC file for HAB bootable image generation I'm generating command line tools for flashing the application image to the NOR flash of the MIMXRT1170 (EVKB board). I know that the nxpimage tool helps create SREC format files from axf/elf files like this:  nxpimage utils binary-image convert -i "%AXF_FILE%" -f s19 -o "%SREC_FILE%"   But the SREC file generated is different from the SREC file that is created when using the MCUXpresso Secure Provisioning Tool in terms of the contents and addressing. When I use the MCUXpresso Secure Provisioning Tool to load an elf/axf file to create a bootable image, it adds the srec file and parsed dcd file in the source folder of the MCUXpresso Secure Provisioning Tool's workspace.  I would like to know how those srec and parsed dcd file is generated by the MCUXpresso Secure Provisioning Tool. Also checking if there is a way to extract the parsed DCD file from SREC/elf/axf file separately with any CLI tools?   I know that the MCUXpresso Secure Provisioning Tool can be invoked from CLI to automate the whole process, but we are trying to create a script that can flash the MCU with just the nxpimage and blhost tools.     Re: Creating SREC file for HAB bootable image generation Hi @tj787 , What can be seen here is the following command creates this output into specified “parsed-directory”: nxpimage.exe hab parse -f mimxrt1176 -o parsed-directory -b my-application-with-dcd.bin Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
查看全文
从中断处理程序进行 I/O 操作 本问题的相关参数如下: 1。IDE:适用于 ARM v 2.2 的 S32 DS(是的,我知道这个已经过时了,但是有问题的产品也是;我们需要支持现有代码) 2.芯片:S32K148 3.操作系统视窗 11 4.系统操作系统:裸机 在 ISR 中尝试执行任何类型的 SPI 主传输都会挂起,通常被中断的 API 是阻塞 I/O(I2C 或 SPI)调用。 在阻塞调用(调用 LPSPI_DRV_MasterTransferBlocking())中,通话挂起是因为 SysTick 中断似乎没有发生,因此 MCU 无法感知时间流逝。 在非阻塞调用(LPSPI_DRV_MasterTransfer(),然后是 LPSPI_DRV_MasterGetTransferStatus(SPI1,&byte_remaining))中,byte_remaining 保持原值。我尝试在调用 LPSPI_DRV_MasterAbortTransfer() 进行异步传输之前,添加对 LPSPI_DRV_MasterAbortTransfer(SPI1) 的调用,但结果还是一样。 关于一个半相关的问题,是什么触发了 SysTick_Handler()?我的直觉告诉我,它应该一直运行,每 1 毫秒增加一次刻度计数,但在其正文中设置一个断点似乎只能在某些时间触发。奇怪的是,即使阻塞性 SPI 传输成功,有时也不会触发,如果系统定时器之前未触发,则应触发系统定时器。 另一个半相关的问题是,在 SPI 的 S32 Cookbook 示例代码中,没有使用 SDK 提供的应用程序接口;这些示例直接完成了所有寄存器位操作。是否有更接近生产价值代码的示例,因为它们至少调用了恩智浦的应用程序接口,而不是重新发明轮子? Re: Doing I/O from an interrupt handler 你好@PetrS 非常感谢。中断优先级确实解决了这个问题。不过,我有一个问题: 我同意在 ISR 中阻塞不是一个好主意,但在单线程应用程序中又有什么办法呢?我可以在应用程序上下文中旋转,直到 SPI 传输完成。这将允许其他 I/O 中断发生(我的理解是,负优先级中断无论如何都会触发;当进入正优先级 ISR 时,它们不会被禁用)。但是在我的情况下,进行重叠的 I/O 既不可能,也不可取。 1.这是不可能的,因为 S32K148 是所有总线的总线主控器。因此,如果它在 ISR 中进行 SPI 传输,则可能无法驱动另一条 I/O 总线,因此无法触发中断。 2.这并不可取,因为 ISR 之间可能存在共享全局,所以我不想在当前 I/O 完成之前启动新的 I/O。 对于单线程裸机应用程序,您建议如何处理这种情况? Re: Doing I/O from an interrupt handler 您好, 好吧,那么只需中断优先级就能导致这种行为。阻塞 API 会挂起的原因很简单,如果两个中断具有相同的优先级,那么当 GPIO ISR 处于活动状态时,LPSPI ISR 就无法运行。阻塞调用等待 ISR 完成传输并发布信号,但在 GPIO ISR 退出之前,ISR 永远不会获得 CPU 时间。SDK 的驱动程序确实在 LPSPI 中断中完成传输,然后才发布信号量以释放屏蔽调用,因此同等优先级 ISR 将以这种方式使传输陷入僵局。 非阻塞 API 的行为相同:如果从具有相同优先级的 GPIO ISR 调用,LPSPI ISR 无法抢占它的优先级,因此 byte_remaining 永远不会改变,因为驱动程序状态机永远不会被 LPSPI IRQ 服务。只有将 LPSPI 提高到更高优先级(数值较低)后,LPSPI 中断才会立即触发,完成传输,并允许阻塞和非阻塞 API 按预期工作。尝试 /* 在 Cortex-M 上,数字越小优先级越高 */ INT_SYS_SetPriority(SysTick_IRQn, 0); // 如果依赖于 tick 超时 INT_SYS_SetPriority(LPSPI1_IRQn, 1); // 必须高于 GPIO INT_SYS_SetPriority(PORTC_IRQn, 2); // 您按钮的 PORTx IRQ   注意:无论优先级如何修正,建议还是不要在 ISR 中使用阻塞的 SPI API,同样也不要在 ISR 中等待非阻塞传输完成。S32K LPSPI 驱动程序在其中断处理程序中进行传输,长时间的 ISR 会阻止其他中断运行。   BR, Petr Re: Doing I/O from an interrupt handler 您好, S32K1 SDK 无法阻止 ISR 的 I/O。LPSPI_DRV_MasterTransferBlocking() 等待 OSIF semaphore;在 ISR 上下文中,没有地方可以阻塞,也没有 tick/time base 可以前进,因此会挂起。使用非阻塞 API(LPSPI_DRV_MasterTransfer),在 LPSPI ISR/回调中完成传输,然后向任务/主循环发出信号。此外,SysTick 会在定时器结束时触发,但其处理程序只有在未被屏蔽且具有足够的 NVIC 优先级时才会运行--因此,如果设置了 PRIMASK 或处于更高优先级的 ISR 中,它将被推迟。 烹饪手册项目特意采用轻量级设计,直接展示外围设备的使用,而不使用更高级别的驱动程序抽象;这些项目旨在作为学习的起点,而非生产使用。如果您需要恩智浦驱动程序风格的示例,请参考 SDK 或 RTD 驱动程序/示例项目,而不是烹饪手册。   BR, Petr Re: Doing I/O from an interrupt handler 您好, 即使它现在 "工作 "了,你仍然不应该在 ISR 内进行 SPI 传输。 如果你以后改变了优先级,或添加了另一个外设,你可以很容易地重新创建刚刚诊断出的死锁状态。 最安全的设计是始终缩短 ISR,将真正的工作推迟到主循环。 仅将 ISR 用作触发信号;在 main () 中同步执行 SPI 传输,或者在 ISR 中启动但由 LPSPI ISR 完成的非阻塞传输,主等待完成标志。 BR, Petr
查看全文
iMX93 FRDM 上的 DMS 嗨,团队、 是否有人在 i.MX93 FRDM 平台上实施或评估过驾驶员监控系统 (DMS) 演示? 我正在寻找与以下功能相关的详细信息或引用: 人脸侦测 人脸地标检测 虹膜/眼睛地标检测 驾驶员行为检测,如吸烟和使用手机 如果有任何演示、参考设计、SDK 示例或合作伙伴解决方案,请分享详细信息或相关文档。 提前感谢您的支持。 致以最诚挚的问候, Ajnas FRDM 培训 Re: DMS on iMX93 FRDM 你好@ajnas-c、 感谢您联系恩智浦支持中心! 您可以通过下面的链接查看该演示的详细信息和源代码: https://github.com/nxp-imx-support/nxp-demo-experience-demos-list/tree/lf-6.12.3_1.0.0/scripts/machine_learning/dms 此致 查维拉
查看全文
BSDL file for the FS32K142H 64LQFP I'm trying to find a BSDL file for the FS32K142H 64LQFP Re: BSDL file for the FS32K142H 64LQFP I find a BSDL file for the FS32K142HAT0MLHT 64LQFP Can someone send it to me? Thanks Re: BSDL file for the FS32K142H 64LQFP Hi @titi  I sent you a private message. BR, VaneB
查看全文
Expected v30 U3 SD CARD Write Performance on MIMXRT1020-EVK Starting with the sdcard_fatfs example in MCUXpresso, and adding the semc driver, I am able to declare an array in SDRAM and write large amounts of data from SDRAM to the SDCARD. Using a SanDisk V30 U3 card, I get 20MB written in 2119ms and 3MB written in 311ms. Is this result within the expected performance? Are there particular parameters I can tune for V30 U3 to improve it? Thanks, Doug Re: Expected v30 U3 SD CARD Write Performance on MIMXRT1020-EVK Hi @dougcl , Thank you so much for your interest in our products and for using our community. Regarding your question, the entire time include reading data from Sdram, and write to SD card? I think the  result within the expected performance. For SDRAM high performance, I suggest you can refer to this AN   AN12437: i.MX RT Series Performance Optimization – Application Note For USDHC, I suggest you use the 4 bit mode in stead of 1 bit mode(if you use uSDHC1), and also use DMA to transfer data. You can also refer to the AN below.  Using the i.MXRT L1 Cache Best Regards MayLiu
查看全文
i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, I am currently evaluating the H265 decode → encode pipeline on i.MX95 and I am observing significantly worse latency and stability compared to i.MX8MP, using similar workloads and configurations. Context On i.MX8MP, using: imxvpudec_h265 vpuenc_hevc I am able to achieve: Very low end-to-end latency (≈ 10 ms) Stable operation with multiple streams No visible freezes or artifacts On i.MX95, using: v4l2h265dec v4l2h265enc I observe: ~90 ms latency for a single decode → encode pipeline Freezes and visual artifacts when running 4 simultaneous camera streams Test pipeline To reproduce the issue, I used IP cameras (H265 over RTSP) with the following pipeline: test-launch "( rtspsrc location=rtsp://10.42.0.85 drop-on-latency=true latency=0 buffer-mode=4 ! rtph265depay ! h265parse config-interval=1 ! v4l2h265dec ! v4l2h265enc ! rtph265pay name=pay0 pt=96 )" This pipeline works correctly with a single camera, but when scaling to 4 cameras, freezes and artifacts start to appear. Questions Why is the H265 VPU pipeline on i.MX95 significantly more latent than on i.MX8MP? Is DMABUF zero-copy fully supported between v4l2h265dec and v4l2h265enc on i.MX95? If not, is there an implicit memory copy that could explain the additional latency and bandwidth pressure? Are there known limitations in the current i.MX95 VPU driver regarding: Low-latency operation Multi-stream decode + encode Internal buffering depth Are there recommended V4L2 controls or io-modes (capture/output-io-mode) to minimize latency on i.MX95? Is the i.MX95 VPU driver expected to reach performance parity with i.MX8MP in future BSP releases, or is the higher latency an inherent design tradeoff? Goal My objective is real-time, low-latency video processing (decode → process → encode), similar to what is achievable on i.MX8MP. Thank you for your support. Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, Which BSP version are you using on i.MX8MP and i.MX95 to recreate this issue? Are you using the same GST pipeline (other than the decoder/encoder elements) on both 8MP and 95? AFAIK, there is no known limitation that results in high latency on i.MX95. On i.MX95, encoder support mmap and dmabuf, which can make a pipeline to transfer dma-buf without copy b/w decoder and encoder. Does the IP camera encode without B frames? Then we can disable decode frame reorder, which will reduce the latency. Please check this. You can disable frame reorder using below v4l2 control " v4l2h264dec extra-controls="decode,display_delay_enable=1,display_delay=0" " You can list all v4l2 controls using below command: v4l2-ctl -l -d Regards Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) The kernel versions: imx95: 6.6.101-0 imx8mp: 6.6.84-0 Yes it is the same gstreamer pipeline. The IP camera encode without B frames. I tired your command and it doesn't solve the issue. There are still artifacts on the screen and the latency is high. However qualitatively speaking, it seems to remove the freezes. ``` v4l2-ctl -l -d /dev/v4l/by-path/platform-4c480000.vpu-video-index0 User Controls min_number_of_capture_buffers 0x00980927 (int) : min=1 max=32 step=1 default=1 value=1 flags=read-only thumbnail_mode 0x00981901 (bool) : default=0 value=0 flags=write-only Codec Controls h264_profile 0x00990a6b (menu) : min=0 max=4 default=0 value=0 (Baseline) hevc_profile 0x00990b67 (menu) : min=0 max=0 default=0 value=0 (Main) display_delay 0x00990b8d (int) : min=0 max=0 step=1 default=0 value=0 display_delay_enable 0x00990b8e (bool) : default=0 value=0 ``` ``` v4l2-ctl -l -d /dev/v4l/by-path/platform-4c480000.vpu-video-index1 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 rotate 0x00980922 (int) : min=0 max=270 step=90 default=0 value=0 flags=modify-layout min_number_of_output_buffers 0x00980928 (int) : min=1 max=32 step=1 default=1 value=1 flags=read-only Codec Controls video_gop_size 0x009909cb (int) : min=0 max=2047 step=1 default=30 value=30 video_bitrate_mode 0x009909ce (menu) : min=0 max=1 default=1 value=1 (Constant Bitrate) flags=update video_bitrate 0x009909cf (int) : min=1 max=1500000000 step=1 default=2097152 value=2097152 frame_level_rate_control_enable 0x009909d7 (bool) : default=1 value=1 h264_mb_level_rate_control 0x009909da (bool) : default=1 value=1 number_of_mbs_in_a_slice 0x009909dc (int) : min=0 max=262143 step=1 default=1 value=1 slice_partitioning_method 0x009909dd (menu) : min=0 max=1 default=0 value=0 (Single) force_key_frame 0x009909e5 (button) : value=0 flags=write-only, execute-on-write intra_refresh_period 0x009909ec (int) : min=0 max=2160 step=1 default=0 value=0 intra_refresh_period_type 0x009909ed (menu) : min=0 max=1 default=1 value=1 (Cyclic) h264_i_frame_qp_value 0x00990a5e (int) : min=0 max=51 step=1 default=30 value=30 h264_p_frame_qp_value 0x00990a5f (int) : min=0 max=51 step=1 default=30 value=30 h264_b_frame_qp_value 0x00990a60 (int) : min=0 max=51 step=1 default=30 value=30 h264_minimum_qp_value 0x00990a61 (int) : min=0 max=51 step=1 default=8 value=8 h264_maximum_qp_value 0x00990a62 (int) : min=0 max=51 step=1 default=51 value=51 h264_8x8_transform_enable 0x00990a63 (bool) : default=1 value=1 h264_cpb_buffer_size 0x00990a64 (int) : min=0 max=18750000 step=1 default=0 value=0 h264_entropy_mode 0x00990a65 (menu) : min=0 max=1 default=1 value=1 (CABAC) h264_i_frame_period 0x00990a66 (int) : min=0 max=2047 step=1 default=0 value=0 h264_level 0x00990a67 (menu) : min=0 max=16 default=14 value=14 (5) h264_loop_filter_alpha_offset 0x00990a68 (int) : min=-6 max=6 step=1 default=0 value=0 h264_loop_filter_beta_offset 0x00990a69 (int) : min=-6 max=6 step=1 default=0 value=0 h264_loop_filter_mode 0x00990a6a (menu) : min=0 max=2 default=0 value=0 (Enabled) h264_profile 0x00990a6b (menu) : min=0 max=4 default=4 value=4 (High) vertical_size_of_sar 0x00990a6c (int) : min=0 max=65535 step=1 default=0 value=0 horizontal_size_of_sar 0x00990a6d (int) : min=0 max=65535 step=1 default=0 value=0 aspect_ratio_vui_enable 0x00990a6e (bool) : default=0 value=0 vui_aspect_ratio_idc 0x00990a6f (menu) : min=0 max=17 default=0 value=0 (Unspecified) h264_constrained_intra_pred 0x00990a7f (int) : min=0 max=1 step=1 default=0 value=0 h264_chroma_qp_index_offset 0x00990a80 (int) : min=-12 max=12 step=1 default=0 value=0 hevc_minimum_qp_value 0x00990b58 (int) : min=0 max=51 step=1 default=8 value=8 hevc_maximum_qp_value 0x00990b59 (int) : min=0 max=51 step=1 default=51 value=51 hevc_i_frame_qp_value 0x00990b5a (int) : min=0 max=51 step=1 default=30 value=30 hevc_p_frame_qp_value 0x00990b5b (int) : min=0 max=51 step=1 default=30 value=30 hevc_b_frame_qp_value 0x00990b5c (int) : min=0 max=51 step=1 default=30 value=30 hevc_profile 0x00990b67 (menu) : min=0 max=0 default=0 value=0 (Main) hevc_level 0x00990b68 (menu) : min=0 max=8 default=7 value=7 (5) hevc_loop_filter 0x00990b6c (menu) : min=0 max=2 default=1 value=1 (Enabled) hevc_loop_filter_beta_offset 0x00990b6d (int) : min=-6 max=6 step=1 default=0 value=0 hevc_loop_filter_tc_offset 0x00990b6e (int) : min=-6 max=6 step=1 default=0 value=0 hevc_refresh_type 0x00990b6f (menu) : min=0 max=2 default=2 value=2 (IDR) hevc_num_of_i_frame_b_w_2_idr 0x00990b70 (int) : min=0 max=2047 step=1 default=0 value=0 hevc_constant_intra_prediction 0x00990b72 (int) : min=0 max=1 step=1 default=0 value=0 hevc_strong_intra_smoothing 0x00990b76 (int) : min=0 max=1 step=1 default=1 value=1 hevc_tmv_prediction 0x00990b79 (int) : min=0 max=1 step=1 default=1 value=1 prepend_sps_and_pps_to_idr 0x00990b84 (int) : min=0 max=1 step=1 default=1 value=1 frame_skip_mode 0x00990b86 (menu) : min=0 max=2 default=0 value=0 (Disabled) average_qp_value 0x00990b91 (int) : min=0 max=51 step=1 default=0 value=0 flags=read-only ``` Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) The BSP versions are : imx8mp: lf-6.6.52-2.2.0 imx95: lf-6.6.52-2.2.1 Thank you Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Yes the IP camera encode without B frames. I tried your command and it doesn't solve the issue. There are still artifacts on the screen and the latency is high. However qualitatively speaking, it seems to remove the freezes. Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) ok Also please confirm the B frame question I mentioned above. Regards Re: i.MX95 VPU H265 latency and performance(v4l2h265enc/v4l2h265dec) Hello, To confirm: the IP cameras encode without B frames (I-P only). I have applied display_delay_enable=1, display_delay=0 on the decoder. This helped remove freezes, but the latency remains at ~90 ms. To isolate the bottleneck, I used the GStreamer element-latency tracer on this pipeline: ``` rtspsrc location=rtsp://... drop-on-latency=true latency=0 buffer-mode=4 !  rtph265depay ! h265parse config-interval=1 !  v4l2h265dec extra-controls="decode,display_delay_enable=1,display_delay=0" capture-io-mode=4 output-io-mode=4 !  v4l2h265enc extra-controls="encode,video_bitrate_mode=1,video_bitrate=2097152,frame_level_rate_control_enable=0,video_gop_size=30" capture-io-mode=4 output-io-mode=4 !  h265parse config-interval=1 ! rtph265pay name=pay0 pt=96 ``` Per-element latency results (640x480 @ 30fps, single stream): v4l2h265enc: ~67 ms v4l2h265dec ~2 ms all other elements < 1 ms The encoder alone accounts for ~67 ms (~2 frame periods). This is consistent across runs. The decoder is fine at ~2 ms. I have tried: frame_level_rate_control_enable=0 capture-io-mode=4 and output-io-mode=4 (DMABUF) on both encoder and decoder Minimal queue buffering between elements (max-size-buffers=1) None of these significantly reduce the encoder latency. My questions, focused on the encoder: Is the Wave6 encoder expected to hold 2 frames internally before producing output? Is there a way to reduce this internal buffering (similar to display_delay=0 on the decoder side)? Does output-io-mode=5 (DMABUF_IMPORT) work on the encoder to achieve zero-copy from upstream? Would this help latency? Is there a V4L2 control or driver parameter to enable a low-latency / zero-delay encoding mode on the Wave6? On i.MX8MP, vpuenc_hevc achieves ~10 ms for the same workload. Is this latency gap with v4l2h265enc on i.MX95 expected to improve in future BSP releases? Thank you for your help.
查看全文
i.MX RT1060 API の LPSPI_MasterTransferEDMA は 24 ビットのフレーム サイズをサポートしていませんか? LPSPI を使用して DMA 経由で 24 ビット フレームを書き込もうとしています。アプリケーションは重要ではありませんが、私の例では、メモリから外部 DAC にデータを送信することです。私はこれを DMA で動作させたいと思っています。なぜなら、最終的には TCD のリンク リストを PIT と一緒に使用して、CPU オーバーヘッドなしで DAC を継続的に更新するためです。これは外部 ADC および DAC を使用する一般的なアプリケーションです。16 ビット DAC/ADC には 24 ビットのフレーム要件があることも一般的です (上位バイトはコマンド用、下位バイトはデータ用)。uint8_t データを使用して転送を 3 バイトに分割するのではなく、uint32_t データを使用して 24 ビットのフレーム サイズで送信し、先頭バイトを無視します。 さて、LPSPI と DMA の構成に移ります。 1.imxRT1060 SDK の API LPSPI_MasterInit 関数の lpspi_master_config_t 構造を使用すると、 bitsPerFrame を 24 に設定できます。DMA を使用せずに標準転送を行う場合、これは問題ではありません。 2. ただし、API の LPSPI_MasterTransferEDMA 関数で DMA を使用する場合、24 ビット フレーム サイズのケースは eDMA ハードウェアによって処理またはサポートされませんか?LPSPI_MasterTransferEDMALite では、DMA 転送幅は edma_transfer_config_t 構造体で設定されます。具体的には、srcTransferSize フィールドと destTransferSize フィールドは、SPI フレーム サイズ (bytesPerFrame) から導出される bytesEachRead 値と bytesLastWrite 値に基づいて構成されます。 /* LPSPI_MasterTransferPrepareEDMALite */ uint32_t bytesPerFrame = ((base->TCR & LPSPI_TCR_FRAMESZ_MASK) >> LPSPI_TCR_FRAMESZ_SHIFT) / 8U + 1U; if (bytesPerFrame <= 4U) { handle->bytesEachWrite = (uint8_t)bytesPerFrame; // for 24bit frames = 3 handle->bytesEachRead = (uint8_t)bytesPerFrame; // .... handle->bytesLastRead = (uint8_t)bytesPerFrame; // .... } /* now back in LPSPI_MasterTransferEDMALite */ switch (handle->bytesEachRead) //bytes each transfer { case (1U): transferConfigRx.srcTransferSize = kEDMA_TransferSize1Bytes; transferConfigRx.minorLoopBytes = 1; if (handle->isByteSwap) { addrOffset = 3; } break; case (2U): transferConfigRx.srcTransferSize = kEDMA_TransferSize2Bytes; transferConfigRx.minorLoopBytes = 2; if (handle->isByteSwap) { addrOffset = 2; } break; case (4U): transferConfigRx.srcTransferSize = kEDMA_TransferSize4Bytes; transferConfigRx.minorLoopBytes = 4; break; default: transferConfigRx.srcTransferSize = kEDMA_TransferSize1Bytes; transferConfigRx.minorLoopBytes = 1; assert(false); break; } デフォルトのケースが発生し、3 バイトのケースは処理されないためエラーが発生します。EDMAハードウェアは3バイト転送をサポートしていますか?基本的に、uint32_tのデータとフレームを3バイトとして扱い、最上位バイトを無視してDMA転送を行いたいのですが、可能ですか? Re: i.MX RT1060 API's LPSPI_MasterTransferEDMA does not support 24bit framesize? こんにちは@azoneさん、 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 次のリンクを確認してください。eDMA は 1、2、4、8、16、32、64 バイトの転送サイズをサポートしており、24 ビット (3 バイト) の転送サイズはサポートしていないことが説明されています。 MCUXpresso SDK APIリファレンスマニュアル: EDMA: 拡張ダイレクトメモリアクセス (eDMA) コントローラドライバ よろしくお願いいたします。 メイリュー Re: i.MX RT1060 API's LPSPI_MasterTransferEDMA does not support 24bit framesize? わかりました。確認してくれてありがとう。これで、動作させるために時間を無駄にすることがなくなりました。したがって、唯一の方法は、すべてをuint8_tデータとしてkLPSPI_MasterPcsContinuousで3バイトとして送信することです。これは他のすべてのペリフェラルでも同じ方法で実行しているので問題ありませんが、16ビットDAC実装の場合は不要なオーバーヘッドが発生します。ありがとうございます。
查看全文
[罗兰][SE050]多个 CPU 和 MCU 能否共用一个 SE050? 专家们好 客户是罗兰公司,该公司正在考虑在其乐器产品中采用 SecureElement SE050E。 此外,罗兰还在考虑利用云技术通过 OTA 更新 CPU 和 MCU 的固件。 不过,他们的系统有多个 CPU 和 MCU。 如果罗兰要更新每个 CPU 或 MCU 的固件、 是否每个 CPU 和 MCU 都需要单独的 SE050? 或者每个 CPU 和 MCU 能否共用一个 SE050? 详情请参见下文。 顺祝商祺! 坎 Re: [Roland][SE050]Can multiple CPU and MCU share one SE050? 你好,Kan、 对于纯粹的 OTA SW 更新,很可能不需要 SE,因为通常只需要处理公钥。但这取决于 OTA 流程,也许他们还需要设备进行一些身份验证才能请求新软件,然后设备需要可用的私钥。通常,还有其他流程/用例需要在设备中提供一些私钥/机密密钥,然后安全元件可以提供帮助。 从软件角度来看,每个 SOC 一个 SE 是最简单的,但没有必要每个 MCU/MPU 都有一个安全元件。" 但同样,一个 SE 最好由一个 SOC 拥有",该 SOC 驱动与 SE 的所有物理通信,而其他 SOC 只能通过一个连接的 SOC 在逻辑上访问 SE。 这样可以避免多台设备希望同时访问 SE 时出现问题。我希望所有设备无论如何都通过一些通用的数据总线连接,这可以用来从所有连接的系统向SE发送请求。 主连接系统可能使用 PlatformSCP 将 SE 与主机绑定。其他设备可以请求单独的AESKey或ECKey频道,为SE提供自己的私人频道。 从用例的角度来看,应该考虑元器件是否可以在现场更换-如果其他元器件应该对新元器件进行身份验证,则新元器件可能需要自己的 SE 或至少是验证芯片来进行自我验证。 亲切的问候, Michael
查看全文
S32 Design Studio for Power Architecture v2.1 - 更新 7 现已发布! <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />       产品发布公告 汽车微控制器和处理器 面向 Power Architecture 的 S32 设计工作室 v2.1 更新 7          新增内容 集成 S32 SDK,适用于 Power Architecture RTM 3.0.2(参见S32 SDK发行说明) 这是一个累积更新 - 它包含之前更新的所有内容(更新 1 、更新 2 ) 安装说明 此更新可供在线安装 (通过 S32DS 扩展和更新)或 离线安装(直接下载链接)  安装: 进入菜单"帮助" -> "S32DS 扩展和更新" 对话框 从可用项目中选择并点击 "Install/Update" 按钮 离线安装: 前往 S32 Design Studio for Power 产品页面 -> 下载部分或使用直接链接下载更新存档 zip 文件 启动 S32 Design Studio,转到“帮助”->“S32DS 扩展和更新”,然后单击“转到首选项”链接 并添加一个新的站点“添加...”存储库并浏览以选择您在上一步中下载的更新存档 zip 文件 选择“S32 Design Studio for Power Architecture Device Package”和“使用 S32 SDK 3.0.2 更新”对于 Power Architecture 包,然后单击“安装/更新”按钮。 此时将启动更新安装过程。 概述 SDK
查看全文
PCF2131——第二脉冲信号触发错误 Hello, 我是 Ramón,开始使用 PCF2131 和 STM MCU 进行工作。在设备中设置新的时间+日期后,我遇到了脉冲秒信号的问题。 我遵循的方案如下: 1.我将设备设置为无中断,只有秒脉冲信号。控制寄存器设置如下: ** 控制 1:0b0000 0001,控制 2、3、4、5:0b0。-> 仅使用第二脉冲信号。 ** INTA/B Mask1/2: 0b0 -> 所有中断禁用 ** WD 控制:0x20 -> 脉冲秒信号,无 WD。 2. 然后我从 RTC 读取并检查完整性。然后设置我的MCU的时间。 3. 设备定期通过 SNTP 进行同步。问题就来了。 当收到新日期时,我们停止 RTC,清除预分频器,设置新时间(添加操作延迟)并重新启动 RTC。当这个时间接近于秒的变化(大概是920-950ms),并且设置增加延时的时间(这样就使得新的时间设置大约在50-80ms),秒脉冲信号被触发,使得MCU比实际时间提前一秒递增。我们不知道为什么会发生这种情况。尝试禁用、清除和重新启用中断,但情况仍然相同。知道为什么会发生这种情况吗? 我将我们测量的信号与我们发送的 I2C 数据附加在一起。第二个是在此特定帧中设置的日期时间的缩放,您可以看到第 100 秒设置为 4。
查看全文
How to refund a wrong transaction How do I get a refund from Phone, for wrong transaction?076995-95414 - If you mistakenly sent money to the wrong number on Phone it is generally ... Functional Safety
查看全文