Kinetisと競合製品のエネルギー効率性の比較 - デモ デモ所有者: Eduardo Montanez   Kinetis KシリーズとKinetis Lシリーズ・マイクロコントローラが競合他社を打ち負かす様子をご覧ください。     特長 EEMBCのCoreMarkベンチマークを実行する最新のKinetis K2マイクロコントローラ 4つの異なるマイクロコントローラがテストにかけられます。 すべての製品に対して同じ容量で、すべて同じイテレーション ベンチマークを実行する 注目のNXP製品 K22F(日本未発売) KL02 リンクス Kinetisマイクロコントローラ|ARM® Cortex-M® コア |NXPの Kinetis Lシリーズ・マイクロコントローラ:エネルギー効率ベンチマーク・デモ Kinetis Lシリーズ・マイクロコントローラのエネルギー効率ベンチマーク - YouTube   インダストリアル

如何真正实现PT60的中断嵌套 最近在支持几个PT60的家电项目，遇到一个共同的问题，就是程序运行的时候，显示数码管会有不规律的闪烁。 几个项目都是以触摸TSI为核心的，对方工程师反应，如果把TSI的中断关闭就不会有闪烁现象。数码管的扫描程序是在MTIM的中断中完成的，经初步分析推测，应该中断时序错乱导致的问题。 因此我们想着这个应该用中断嵌套的方式可以解决。 中断嵌套的定义简单来说，就是当MCU正在处理一个低优先级的中断的时候，来了一个高优先级的中断，系统此时就会放下低优先级转向去执行高优先级的，完了之后继续回来执行低优先级的。 按照这个逻辑，我们应该只要将各个中断的优先级预先设好就没有问题了。项目一共用了四个中断TSI，RTC（这两个中断组合完成TSI扫描按键，是基于sam之前写的的算法），MTIM（数码管扫描），KBI（用作低功耗唤醒）。 因此，我们把MTIM的优先级设成最高，就应该不会再出现闪烁的现象了，但改完之后，结果依旧失败。   经过不断讨论以及查找数据手册，最终实现了，但不得不说PT60实现中断嵌套还是挺麻烦的。 我们一步一步来：   1.首先我们来看CPU是执行中断的顺序。其余步骤没有什么特别，关键就在于第2步。 2.我们来看这个I位的作用。当进入某个中断之后，这个I位就会被自动置位，也就是系统将整个interrupts都给关掉了，这么做的原因也就是为了让系统在执行某个中断的时候，不会被其他的中断给干扰打断。 那么这就是为什么我们会中断嵌套失败的根本原因！ 3.因此，如果我们需要使用中断嵌套的话，那么就需要在每个中断程序里面添加这个清楚CCR寄存器I位的指令，asm cli。 4.因为中断嵌套被启用了，有潜在的风险会导致进中断前一些堆栈数据出错或者中断优先级出问题等，那么在中断程序的最后，我们再加一句话，让一切恢复正常就可以了 IPC_SC_PULIPM = 1;   经过以上步骤，中断嵌套就能够实现了。     但在这个过程中，遇到了几个问题，也和大家分享下 1.PT60的中断会自己嵌套自己： 手册中有提到，高优先级和同级中断都是可以抢占低优先级的。 我举个例子来说明： 现在有两个中断，1号中断--低优先级0级，2号中断--高优先级1级。 1号中断正在执行的过程中，此时2号中断过来打断了他，系统必然要先把2号中断执行完。之后再回去执行1号中断剩下的部分。但很不巧，此时新的1号中断又来了，就是说上一次的1号中断还没跑完，又被新的1号抢占了，也就是自己嵌套了自己，最后必然导致全部中断的时序都出现了问题。 这是一种潜在的隐患，我们的解决方法就是：让0级的1号中断一开始执行中断程序之后，让其把自身的中断等级提高一级，中断结束的时候在加上上面提到的恢复语句又变回0级。这样的话，我旧的1号中断（1级）还没执行完，新的一号中断（0级）即使来了，也无法抢占，必须乖乖的等着让旧的先执行完。下面这几条语句就是提高中断等级的，我们实验的时候让中断只有0和1级。   2.在执行asm cli指令之前必须要清除中断标志位： 接上，如果不清楚标志位的话就打开asm cli的话，那么系统就一直不断地让这个中断再进，也就是中断自己不断地在嵌套自己，最终把堆栈给压爆了，程序也就跑飞了。   东西很简单，但是确实值得注意。 附件是测试的程序，有需要的可以参考。  General

示例 MPC5674F eQADC_PMC_chnl_conv+calib CW210 ******************************************************************************** * 详细说明： * 初始化 eQADC 模块，执行校准并循环转换 PMC * 由宏 CHOOSEN_PMC_ADC_CHNL 指定的内部通道， * CHOOSEN_PMC_ADC_SCALE 和 CHOOSEN_PMC_ADC_COMMAND 用于检查特定电压 * 级别，并将其显示到终端窗口中。 * 除通过 eSCI 的终端外，无需任何外部连接。 * ---------------------------------------------------------------------------------------------- * 测试硬件：XPC567XKIT516 - MPC5674ADAT516 Rev.C、MPC567XEVBFXMB Rev.B * 微控制器: PPC5674FMVYA264 * 终端：19200-8-无奇偶校验-1 停止位-eSCI_A 上无流量控制 * 系统频率：264/200/150/60 MHz * 调试器：Lauterbach Trace32 * 目标：internal_FLASH，RAM * 终端：19200-8-无奇偶校验-1停止位-无流量控制 * EVB连接：默认 ******************************************************************************** ******************************************************************************** * 详细说明： * 初始化 eQADC 模块，执行校准并循环转换 PMC * 由宏 CHOOSEN_PMC_ADC_CHNL 指定的内部通道， * CHOOSEN_PMC_ADC_SCALE 和 CHOOSEN_PMC_ADC_COMMAND 用于检查特定电压 * 级别，并将其显示到终端窗口中。 * 除通过 eSCI 的终端外，无需任何外部连接。 * ---------------------------------------------------------------------------------------------- * 测试硬件：XPC567XKIT516 - MPC5674ADAT516 Rev.C、MPC567XEVBFXMB Rev.B * 微控制器: PPC5674FMVYA264 * 终端：19200-8-无奇偶校验-1 停止位-eSCI_A 上无流量控制 * 系统频率：264/200/150/60 MHz * 调试器：Lauterbach Trace32 * 目标：internal_FLASH，RAM * 终端：19200-8-无奇偶校验-1停止位-无流量控制 * EVB连接：默认 ********************************************************************************

适用于 Panther (MPC574xP) 系列处理器 2.0 的基于模型的设计工具箱 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 适用于 PANTHER (MPC574xP) 系列处理器 2.0 的基于模型的设计工具箱   支持 Panther (MPC57xP) 版本 2.0 的 MATLAB/Simulink基于模型的设计工具箱现已推出。   该产品免费，并可供公众使用。 下载 基于模型的设计工具箱 mbdt    发布亮点——基于模型的Panther设计工具箱（MPC574xP） 支持新的 Panther XDEVKIT-MPC5744P 板（ARDUINO 风格），该板与新的底盘 XDEVKIT-MOTORGD 配合用于电机控制应用。 结合最新的汽车数学和电机控制库版本 1.1.7。 支持最新的 MATLAB 版本，包括 64 位（2015/2016 a/b） 新的DMA模块，允许 ADC 采样数据通过 DMA 模块传输到内存，无需 CPU 干预。 用于串行通信支持的新LINFlexD块现在允许通过 UART 进行数据发送/接收操作。 添加了新的内存读/写块，现在可以使用它们来读取/写入任何内存区域。 添加了新的自定义初始化块，它可用于在模型第一步之前扩展默认设置之外的任何模块的配置。 除了新编译器版本 Wind River DIAB v5.9.4.8 和 Green Hills MULTI for PowerPC v2015.1 外，还支持 S32 Design Studio for Power Compiler v1.1 添加了新的高级电机控制模块，现在轨道观察器或反电动势观察器等新功能作为 Simulink 模块提供。 对齐ADC 时钟频率从 20MHz 到 80MHz（最大速度）。 新的ADC 通道配置块经过重新设计，允许对 ADC 通道进行无采样配置，从而可以实现 DMA 传输场景。 新的诊断面板可用于启用/禁用多个一致性检查。 构建新的Bootloader来支持 UART1 通信。 与 FreeMASTER 版本 2.0.2 同步支持。 全新！！！热修复：添加对随S32 Design Studio for Power v1.2发布的最新 e200 编译器的支持 。 请参阅HotFix_3设置以使 MBD 工具箱与最新的 e200 编译器协同工作。   提供社区支持 可通过 NXP 社区获得支持： https://community.nxp.com/community/mbdt 回复：基于模型的设计工具箱，适用于 Panther (MPC574xP) 系列处理器 2.0 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好， chandan24 ， 这可能只是一个小故障。如果它仍然不起作用，请使用此直接链接： https://nxp.flexnetoperations.com/control/frse/product? child_plneID=683951&cert_num=284425987 或者 使用基于模型的设计官方页面访问下载位置：基于模型的设计工具箱|NXP 希望这有帮助！ 丹尼尔 回复：基于模型的设计工具箱，适用于 Panther (MPC574xP) 系列处理器 2.0 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 工具箱下载链接无效

TuxTeam_Milestone_1 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在电影中，我们展示了我们将必要的连接连接到耳机内部电路板的“T”针（红线）和地线，这需要与 UDOO 电路板的地线（黑线）共用。这些线分别连接到 UDOO 板的 0（RX）引脚和 GND 引脚。在软件方面，我们使用了 Brain 库，它从串行接口接收数据包并对其进行解释，以 CSV 格式提供值，以便我们在下一步进行处理。为了接收来自耳机的数据，开发板的 M4 核心运行 Arduino 代码并使用 Serial0 对象（UART 5）获取原始数据，然后由 Brain 库进行处理。然后，使用提供的共享内存将结果字符串发送到 A9 核心。正如我们在视频中看到的，此步骤使用了 Serial 对象。接收到的字符串包含以下形式的值： 信号强度、注意力、冥想、δ、θ、低α、高α、低β、高β、低伽马、高伽马 我们将在接下来的里程碑中使用它们。 （在 “我的视频” 中查看） 2017 年 Linux 嵌入式挑战赛 回复：TuxTeam_Milestone_1 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 抱歉，视频未旋转...我不知道为什么会发生这种情况，我们旋转了它，但上传后，我发现它仍然在这个位置，我对此无法解释：smileysad： 编辑：我编辑了视频并再次上传，希望这次能够成功。

AUT-N1783 安全 CAN 网络实践研讨会 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 现代汽车已经超越了简单的交通工具，成为一种连接平台。随着汽车与世界其他地方的互联，平衡性能和成本的挑战带来了满足安全性的新要求。本课程将回顾 CAN 通信的安全影响。该课程将通过安全的 CAN 通信指导如何实际连接两个 MPC5748G 设备的 CAN 网络。利用 MPC5748G HSM 上的 SHE 固件。CAN 消息在传输前进行签名，并在接收端使用 CMAC 和 AES-128 进行验证。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 现代汽车已经超越了简单的交通工具，成为一种连接平台。随着汽车与世界其他地方的互联，平衡性能和成本的挑战带来了满足安全性的新要求。本课程将回顾 CAN 通信的安全影响。该课程将通过安全的 CAN 通信指导如何实际连接两个 MPC5748G 设备的 CAN 网络。利用 MPC5748G HSM 上的 SHE 固件。CAN 消息在传输前进行签名，并在接收端使用 CMAC 和 AES-128 进行验证。 安全互联汽车和自动化汽车

MHW-N1917 无线充电让您摆脱电线束缚！ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。 观看视频演示 安全移动 | 医疗保健和可穿戴设备

CIT-N1924 MIFARE 超越票务——智慧城市的非接触式解决方案 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 过去几年，交通票务要求发生了重大变化——从交易安全到多应用需求以及将移动票务集成到现有环境的可能性。NXP 的 MIFARE ®产品始终能够满足这些要求，并作为提供便利性、灵活性和可扩展性的领先非接触式解决方案建立了良好的声誉。开放的 MIFARE 社区和生态系统由超过 1,000 个业务合作伙伴组成，其中包括应用程序开发商、服务和解决方案提供商、系统集成商和卡制造商。MIFARE DESFire EV2 是下一代 MIFARE IC，具有最高的硬件和软件安全级别（EAL5+ 通用标准认证）。其增强的密钥管理使其成为无限应用程序的理想多应用平台。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 过去几年，交通票务要求发生了重大变化——从交易安全到多应用需求以及将移动票务集成到现有环境的可能性。NXP 的 MIFARE ®产品始终能够满足这些要求，并作为提供便利性、灵活性和可扩展性的领先非接触式解决方案建立了良好的声誉。开放的 MIFARE 社区和生态系统由超过 1,000 个业务合作伙伴组成，其中包括应用程序开发商、服务和解决方案提供商、系统集成商和卡制造商。MIFARE DESFire EV2 是下一代 MIFARE IC，具有最高的硬件和软件安全级别（EAL5+ 通用标准认证）。其增强的密钥管理使其成为无限应用程序的理想多应用平台。 智能城市和智能基础设施

HMB-N1984 开发 HomeKit 和 iPod -MFi- 配件，采用 NXP 处理器和软件 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍如何开发 Made For iPod (MFi) 配件，包括基于 NXP 微控制器 (MCU)、微处理器 (MPU)、HomeKit 软件开发套件 (SDK)、MFi SDK 和 NXP 专业服务软件的音频、非音频、CarPlay、AirPlay 和 HomeKit 应用程序。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍如何开发 Made For iPod (MFi) 配件，包括基于 NXP 微控制器 (MCU)、微处理器 (MPU)、HomeKit 软件开发套件 (SDK)、MFi SDK 和 NXP 专业服务软件的音频、非音频、CarPlay、AirPlay 和 HomeKit 应用程序。 智能家居和智能建筑

NET-N1886 QorIQ LS1043A 处理器硅片启动技巧 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将提供有助于加速 QorIQ LS1043A 处理器硅片启动的技巧。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将提供有助于加速 QorIQ LS1043A 处理器硅片启动的技巧。 智能网络

APF-ACC-T0983 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、KEAシリーズとKFAシリーズを含む、新しいKinetisマイクロコントローラの自動車製品ファミリの概要を説明します。Kinetisマイクロコントローラの自動車ファミリは、車載市場向けの32ビットARM® Cortex-M0®+/M4ベースのAEC Q100認定マイクロコントローラの、拡張性に優れたポートフォリオです。このファミリは、コスト重視のアプリケーション向けに最適化されており、非常に低い消費電力でピン数の少ないオプションを提供します。2.7-5.5V電源を備え、優れたEMC/ESD堅牢性に重点を置いたKinetisマイクロコントローラ・オート・シリーズ・デバイスは、ボディ・アプリケーション、インフォテインメント接続モジュール、パーキング・アシスタンス、セーフティ・コンパニオン・チップ、汎用センサ・ノードなど、幅広いアプリケーションに適しています。Kinetisマイクロコントローラのオート・ファミリのすべての製品は、同様のペリフェラルを共有しており、さまざまなサードパーティ製およびフリースケールのHW/SW開発ツールによってサポートされています。開発者は、Kinetisマイクロコントローラのオート・ファミリを使用して、設計を迅速に開始できます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、KEAシリーズとKFAシリーズを含む、新しいKinetisマイクロコントローラの自動車製品ファミリの概要を説明します。Kinetisマイクロコントローラの自動車ファミリは、車載市場向けの32ビットARM® Cortex-M0®+/M4ベースのAEC Q100認定マイクロコントローラの、拡張性に優れたポートフォリオです。このファミリは、コスト重視のアプリケーション向けに最適化されており、非常に低い消費電力でピン数の少ないオプションを提供します。2.7-5.5V電源を備え、優れたEMC/ESD堅牢性に重点を置いたKinetisマイクロコントローラ・オート・シリーズ・デバイスは、ボディ・アプリケーション、インフォテインメント接続モジュール、パーキング・アシスタンス、セーフティ・コンパニオン・チップ、汎用センサ・ノードなど、幅広いアプリケーションに適しています。Kinetisマイクロコントローラのオート・ファミリのすべての製品は、同様のペリフェラルを共有しており、さまざまなサードパーティ製およびフリースケールのHW/SW開発ツールによってサポートされています。開発者は、Kinetisマイクロコントローラのオート・ファミリを使用して、設計を迅速に開始できます。

传感器发布示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP技术支持发布的软件示例列表： NXP 技术支持发布的传感器软件示例* NXP技术支持设计的分线板列表： 飞思卡尔传感器分线板设计 – 主页 *以上所有源代码仅供示例使用。恩智浦不对用户应用程序中使用这些代码承担任何责任。

i.MX Multimedia Explained: How-to Effectively Create Multimedia Application for i.MX Applications Processors Lecture including a live demo, showing how to develop multimedia application for i.MX applications processors, taking advantages of the hardware multimedia accelerators of the i.MX SoC.  Presented by Daniele DallAcqua Presented at DwF Istanbul - May 12, 2015 Session ID: EUF-DES-T1474 Lecture including a live demo, showing how to develop multimedia application for i.MX applications processors, taking advantages of the hardware multimedia accelerators of the i.MX SoC.  Presented by Daniele DallAcqua Presented at DwF Istanbul - May 12, 2015 Session ID: EUF-DES-T1474 i.MX Applications Processors Re: i.MX Multimedia Explained: How-to Effectively Create Multimedia Application for i.MX Applications Processors Great presentation! Very complete. Would you share the hands on source code? I'm specially interested in the src/hmi.c and media_server.c.

调整 S08P MCU <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本文档的目的是展示调整微控制器单元 (MCU) 的重要性，并展示未调整和调整后的设备之间的差异。 概述

I.MXRT1021 Flash Operation Demo on FreeRTOS in XIP Mode        由于RT系列没有内置 Flash，大多数用户会选择外部 QSPI Flash 作为应用代码和数据的非易失存储设备，同时外部Flash的大容量在满足用户代码存储需求之外也会为用户提供了足够的灵活空间存储应用数据，但是其中涉及到的对数据读擦写以及用户的应用程序均需要在外部 Flash 执行，这为 Flash 的操作带来了麻烦。        对于在XIP（eXecute-In-Place）模式下的应用，对Flash读擦写的操作需要在内部 RAM 里执行，而RT系列由于高主频而引入了内核 Dcache 以及 Flexspi 模块自带的 Pre-fetch 功能，对外部 Flash 的操作会有很多需要注意的地方，这些问题在带有 RTOS 的系统里则更是突显出来，而无论在 XIP 模式下的裸机还是基于 RTOS 方式对 Flash 的操作，SDK 里均没有提供例程可供参考。        本参考方案来自很多客户的实际应用需求，所以编写了基于 FreeRTOS 下的对片外 QSPI Flash 的读擦写操作，客户可以基于此例程移植到自己的应用里面做相关的应用开发，并配套对应的指导文档提醒用户在移植过程中需要注意的几个常见的 tips。 Products Product Category NXP Part Number URL MCU MIMXRT1021 i.MX RT1020 Crossover MCU with Arm® Cortex®-M7 core MCUXpresso SDK Software SDK v2.6.1 Welcome | MCUXpresso SDK Builder    Tools NXP Development Board URL MIMXRT1020-EVK MIMXRT1020-EVK: i.MX RT1020 Evaluation Kit Industrial

Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi，pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey

FRDM-i.MX95 上的外部 JTAG 调试器连接未输出预期的 JTAG 信号 你好， 我正在尝试将外部 JTAG 调试器连接到 FRDM-i.MX95 板。 根据板原理图，JTAG/DAP 信号似乎被连接到 PCB 上的测试点，一些相关元器件被标记为 DNP。 基于此，我对电路板进行了如下修改： 连接测试点的 JTAG 信号 安装与 JTAG/DAP 信号路径相关的 DNP 电阻器 添加了外部调试器的连接器 将 VTref、GND、TCK、TMS、TDI、TDO 和 RESET 连接到外部调试器 但是，我无法从调试器/电路板端观察到预期的 JTAG 信号输出。 例如，在调试器连接序列期间，TCK/TMS/TDI 没有按预期出现。 请您确认以下几点？ 上述修改方法是否适用于将外部 JTAG 调试器连接到 FRDM-i.MX95 板？ 要启用外部 JTAG/DAP 接口，是否需要额外的电阻器、跳线、焊桥或板修改？ 外部调试器开始驱动 JTAG 信号之前，VTref 电压等级或电源时序是否有任何要求？ FRDM-i.MX95 上的 i.MX95 在 JTAG/DAP 接口可访问之前是否需要任何启动模式、熔丝设置、网络安全设置或软件初始化？ 外部 JTAG 调试器能否直接访问该板上的 Cortex-A55、Cortex-M33 和 Cortex-M7 内核，还是需要引导加载程序/固件进行额外的初始化？ 在使用 FRDM-i.MX95 时，是否有推荐的连接器引脚分配或参考修改指南，以便将外部调试器与 FRDM-i.MX95 配合使用？ 如果您能提供在 FRDM-i.MX95 板上启用外部 JTAG 调试的任何指导、原理图参考或所需修改细节，我将不胜感激。 顺祝商祺！ Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. 你的修改方法是否正确？ 原则上，是的。 如果 FRDM 原理图显示： TCK TMS TDI TDO nTRST 或 RESET VTREF GND 通过测试点和 DNP 填充选项，然后将这些信号路由到连接器通常是正确的方法。 但是，由于搜索结果中没有返回原理图，因此我无法确认所有必需的 DNP 电阻器是否都已安装到位。用户手册中不包含 JTAG 电路图。 2. 为什么检测不到 TCK/TMS/TDI 活性？ 通常情况下，当连接 JTAG 探针时： TCK/TMS/TDI 由调试器驱动。 目标板不会生成它们。 如果您在 TCK/TMS 上完全看不到任何切换： 最常见原因 1：未检测到 VTref 许多探针（Lauterbach、J-Link、PE Micro、ULINK 等）只有在 VTref 存在且在有效范围内时才会驱动 JTAG 引脚。 检查： 连接器处的 VTref 电压。 共用接地连接。 探针软件会报告目标电压。 对于 FRDM-i.MX95，DAP I/O 电源似乎与 3.3 V 功能域 (NVCC_CCM_DAP) 有关。板文档显示该功能域由VDD_3V3供电。 最常见原因二：电路板未通电 大多数调试器仅使用 VTref 进行检测。 它们不会为目标提供动力。 核实： 电路板由 J25 供电。 PMIC启动。 VDD_3V3 存在。 电路板上的LED指示灯亮起。 该板需要外部PD电源。 最常见原因#3：缺少信号路由重构 如果 JTAG 路径包含： 0Ω DNP电阻器 隔离电阻器 其他馅料选择 即使缺少一个电阻，也可能导致 TCK/TMS 断开连接。 由于搜索结果中没有原理图，我无法核实电阻器的确切配置。 最常见原因#4：引脚映射错误 用欧姆表验证： 探针引脚 → 连接器引脚 → 电阻器 → 测试点 → i.MX95 球。 不要假设测试点标签与标准的 ARM 20 引脚顺序一致。 3. 是否需要特殊的启动模式？ 对于不安全的设备： 观察 JTAG 时钟活动不应该需要启动模式。 一旦调试器检测到 VTref 并开始扫描序列，TCK/TMS 就应该切换。 启动开关会影响： eMMC启动 SD启动 序列号下载器 这与调试器是否生成 TCK 无关。 4. 是否涉及安全设置/熔丝？ 有可能。 i.MX95 实现了认证调试和调试访问控制。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] 然而： 网络安全设置通常会阻止成功的调试访问。 它们通常不会阻止调试器生成 TCK/TMS 本身。 由于您报告完全没有 TCK 活性，我首先会调查以下问题： VTREF 探针配置 电缆引脚排列 缺失的人口选项 在怀疑网络安全之前。 5. A55、M33 和 M7 可以调试吗？ i.MX95调试架构支持： Cortex-A55 Cortex-M33 Cortex-M7 通过 CoreSight/DAP 基础设施。[i.MX95RM_Rev2 | PDF] ， [i.MX95RM_Rev5 | PDF] 所以从硅芯片的性能角度来看，是的。 所有功能域是否立即可见取决于： 系统状态， 网络安全配置， 支持调试器。 但调试器通常不需要额外的引导加载程序初始化即可检测到 DAP 本身。 推荐测量方法 在进一步修改电路板之前，我会检查以下几点： 电源 VTref = ?V VDD_3V3 存在 板正常启动 连续性 TCK 连接器 ↔ SoC 路径 TMS连接器↔SoC路径 TDI 连接器 ↔ SoC 路径 TDO 连接器 ↔ SoC 路径 RESET 连接器 ↔ SoC 路径 探针侧 调试软件是否报告目标电压？ 它是否显示“检测到目标”？ 它是否报告尝试进行 JTAG 链扫描？ 示波器 直接探测： 调试器连接器引脚 SoC侧测试点 连接尝试期间。 如果调试器连接器处存在 TCK，但 SoC 测试点处不存在 TCK，则问题几乎肯定出在电路板返工上。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 感谢您的支持。 我们检查了外部 JTAG 调试器连接，发现 问题是由FRDM-i.MX95板和电路板之间的线路长度引起的。 外部 JTAG 调试器。 缩短并重新排列 JTAG 信号线后，调试器…… 能够正确检测到目标，并观察到了JTAG信号。 预期的。 因此，通过改进JTAG接线方式，这个问题已经得到解决。 长度和连接质量。 再次感谢您的帮助。

Solyball Cooling Ace 专为现代生活而设计 当气温升高时，保持舒适的室内环境成为许多人的首要任务。无论是在家、办公室还是个人工作空间，过高的温度都会影响注意力、放松度和整体舒适度。Solyball 正是为此提供了一个便捷实用的解决方案。Solyball 的设计兼顾便携性、简洁性和现代生活方式，是一款小巧的降温设备，可帮助用户在各种室内环境中营造更舒适的氛围。 Solyball 最显著的特点之一 是其轻巧便携的设计。与笨重难搬或占用大量空间的大型制冷系统不同，Solyball 体积小巧，几乎可以完美融入任何房间。其便携性使用户能够轻松地将其从一个地方搬到另一个地方，从而满足全天候不同需求。无论您是在家办公、在客厅放松，还是准备享受一夜安眠，Solyball 都可以放置在任何您需要额外舒适感的地方。 Solyball 的多功能性 使其成为各种室内环境的理想之选。在卧室里，它有助于在温暖的夜晚营造更舒适的氛围。舒适的睡眠环境对整体健康至关重要，而小巧的降温设备可以提升您的睡眠体验。Solyball 尺寸适中，可轻松放置在床头柜或其他平面上，不会造成空间杂乱。 对于专业人士和远程办公人员来说， Solyball能帮助他们保持舒适的工作空间，从而显著提高工作效率。室内温度过高有时会影响专注力，难以集中精力完成工作。Solyball 提供了一种切实可行的提升工作舒适度的方法，帮助用户在一天中营造更加愉悦的工作环境。其小巧的体积使其可以方便地放置在办公桌或工作台上，而不会占用过多空间。 Solyball的便利性也体现在客厅和家庭共享空间中。这些区域通常是人们聚集的中心场所，他们会在这里看电视、阅读、社交或放松身心。将 Solyball 融入这些空间，用户可以在日常活动中享受更舒适的氛围。其现代外观确保它能与现代家居装饰自然融合。

S32G_Howto_Boot_MiniLinux_from_QSPI This article explains how to boot a minimal Linux on the S32G using only QSPI Nor, for the most important purposes: emergency/upgrade/test mode for Linux, or fast booting catalogs 1 Background and Information Note... 2 1.1 Background note... 2 1.2 Description of the information required... 2 2 S32G QSPI Nor Mirror Layout Description... 3 2.1 S32G Linux BSP Support for QSPI Nor Boot... 3 2.2 S32G Yocto fsl-image-flash mechanism analysis... 5 2.3 Mirror Layout and Modification Targets for S32G QSPI Nor Boot... 7 3 Image modification and compilation... 8 3.1 Mirror image modification... 8 3.2 Yocto compilation methods... 10 3.3 Standalong compilation method... 11 4 How to shrink a Linux kernel image... 12 5 How to Make Minimum Rootfs. 12 5.1 Direct shrink based on existing rootfs... 12 5.2 Other methods... 14 6 Testing... 14 6.1 Burning Approach... 14 6.2 Running log. 16 7 How to add apps to Rootfs... 17 7.1 Adding methods to the Yocto environment... 17 7.2 Other methods ... 17 7.3 Test results... 17 8 Annexes... 17

2026 年最佳 IPTV 提供商有哪些？ 人们观看电视的方式发生了前所未有的变化。有线电视费不断上涨，观众希望获得更大的灵活性，流媒体已成为新常态。这就是为什么现在很多用户会问，2026 年最好的 IPTV 提供商是什么？他们希望有更好的频道选择、更流畅的播放以及不受传统电视限制的娱乐体验。 🛰️ 探索最佳 IPTV 供应商 IPTV 是互联网协议电视的缩写。它通过互联网连接提供直播电视频道、电影、体育和在线点播内容。用户不使用卫星或有线电视线路，而是直接在智能电视、Firestick、安卓设备、平板电脑和笔记本电脑上直播内容。 2026 年，IPTV 服务将继续增长，因为它们提供了便利、价值和现代化的观看功能。本指南将解释是什么让供应商脱颖而出，以及如何找到满足您需求的最佳 IPTV 解决方案。 2026 年最佳 IPTV 提供商因何而闻名？ 2026 年的最佳 IPTV 提供商不仅要拥有众多频道。质量比数量更重要。顶级供应商应提供稳定的数据流、便捷的导航和强大的客户支持。 可靠的 IPTV 服务投资于更好的服务器，以减少缓冲。他们还定期刷新频道列表，在繁忙时段保持畅通无阻。这对体育迷和现场活动观众尤为重要。 强大供应商的另一个标志是用户友好的设置过程。良好的IPTV平台使激活变得简单，并与流行的应用程序和流媒体设备兼容。 2026 年 IPTV 为何更受欢迎 许多家庭现在更喜欢流媒体，因为它符合现代生活方式。用户希望按自己的日程安排娱乐，而不是固定有线电视套餐。 在任何设备上灵活查看 IPTV 发展的一个主要原因是设备自由。用户可以在智能电视、手机、平板电脑和流媒体棒之间轻松切换。这就创造了一种无缝的娱乐体验。 比传统电视更有价值 许多人都在寻找价格合理的 IPTV 提供商，因为他们想要更多的内容，而不需要支付高昂的有线电视月租费。IPTV 通常将全球频道、体育和电影合而为一。 按需便利 观众不再愿意等待预定的广播节目。IPTV 通常提供回放选项、电视补播和适合繁忙生活的视频在线点播内容。 2026 年最佳 IPTV 提供商的主要特点 如果您知道应该注意什么，选择合适的服务就会变得更加容易。 稳定的流媒体质量 2026 年最佳 IPTV 提供商注重快速服务器和高正常运行时间。与无法正常工作的冗长频道列表相比，流畅的播放更为重要。 广泛的渠道选择 顶级供应商通常包括娱乐、新闻、体育、儿童内容和国际网络。均衡的阵容为用户带来更多价值。 支持高清和 4K 现在，许多用户都希望获得高分辨率的流媒体。高级 IPTV 服务支持的频道通常包括高清、全高清和 4K 选项。 快速响应的客户支持 当出现登录问题、设置错误或应用程序问题时，快速支持可提供帮助。可靠的客户服务是选择 IPTV 提供商的一个重要因素。 如何选择最适合您的 IPTV 提供商 每个观众都有不同的侧重点。有些人想要体育报道，而另一些人则专注于电影或家庭娱乐。 如果体育赛事直播最重要，则应选择稳定的赛事流和覆盖面广的体育频道。如果您喜欢电影和连续剧，请选择具有强大 VOD 库和最新内容的供应商。 家庭可能更喜欢多设备访问和儿童频道。旅行者可能需要全球兼容性和灵活的登录选项。 订购前进行测试也是明智之举。许多用户在购买长期计划之前都会搜索 IPTV 免费试用服务，以检查服务质量。 推动 IPTV 搜索的搜索引擎优化趋势 2026 年最佳 IPTV 提供商、顶级 IPTV 服务、优质 IPTV 计划和无缓冲 IPTV 等搜索短语越来越常见。这反映出对灵活的流媒体解决方案的需求日益增长。 随着全球网速的提高，IPTV 也变得越来越容易使用。智能电视和流媒体设备也更实惠，这有助于提高IPTV的采用率。 人们想要个性化娱乐，而IPTV比标准电视套餐为他们提供了更多的控制权。 选择 IPTV 时应避免的错误 有些用户只选择最便宜的方案。低廉的价格可能很有吸引力，但较差的流媒体质量和薄弱的支持可能会导致失望。 另一个错误是忽视兼容性。务必确认提供商可在您的首选设备上运行。 跳过研究也会造成问题。阅读近期评论和试用测试有助于避免使用不可靠的服务。 2026 年 IPTV 的未来 预计 IPTV 将变得更加智能，更加以用户为中心。更快的网络、改进的应用程序和更好的内容库将继续塑造市场。 许多供应商正在改进界面、搜索工具和流媒体的稳定性。这意味着用户今后可以期待更流畅的体验。 随着需求的增加，IPTV 提供商之间的竞争也可能提高定价和服务质量。 结束语 那么，2026 年有哪些最佳 IPTV 提供商？这些服务集稳定的流媒体、优质的内容、简单的设置和强大的支持于一身。最佳选择取决于您的观看习惯、设备和预算。 选择 IPTV 提供商时，应注重性能而不是承诺。回放可靠、功能实用的服务总是更有价值。 如果您已准备好升级您的娱乐体验，请探索值得信赖的 IPTV 提供商，在 2026 年享受更智能的流媒体服务。 Re: What Are the Best IPTV Providers in 2026? 您在寻找无需立即付费即可享受优质内容的最佳方式吗？2026 年，寻找优质供应商的最有效方式是免费试用 IPTV。 为什么要从免费测试开始？ 免费试用允许您在订购前验证几个关键因素： 稳定性：确保服务提供无缓冲流媒体和高正常运行时间（理想情况下为 99% 或更高）。 内容丰富：查看 20,000 多个直播频道，包括高级体育、新闻和国际网络。 质量：验证对高清、全高清和 4K 流媒体的支持。 设备兼容性：确认它可以在您的首选硬件上运行，例如亚马逊 Firestick、智能电视、安卓/iOS 设备或电脑。 2026 年的热门推荐 为了获得具有丰富频道选择和可靠性能的优质体验，我们建议您测试GoldCard TV。它旨在提供无缝娱乐解决方案，将停机时间降至最短。 👉 现在就开始免费试用： https://omeulink.com/GoldCardTv Re: What Are the Best IPTV Providers in 2026? 在过去几个月里，我测试了几家 IPTV 提供商，根据我的经验，HypoTV 是稳定性、流媒体质量和日常娱乐方面最好的提供商之一。如果您正在寻找以体育为重点的流媒体，BekuTV的表现非常出色，直播频道流畅，缓冲极少。对于成人内容和大型 VOD 库，PillowIPTV 是一个不错的选择。我还看到许多用户推荐MomipTV，因为它具有可靠的国际频道选择和多设备支持。总的来说，每种服务都有自己的优势，这取决于您最常观看的内容类型。 Re: What Are the Best IPTV Providers in 2026? 我测试过很多 IPTV 服务，NexusIPTV 的稳定性和画质确实让我大吃一惊。 频道速度快，几乎没有缓冲，而且有大量体育、电影和国际高清/4K 内容可供选择。 可在 Firestick、智能电视、安卓、iPhone 和电脑上完美运行。 如果您想在 2026 年获得可靠的 IPTV 服务，NexusIPTV 绝对值得一试。 www.nexusiptv.live Re: What Are the Best IPTV Providers in 2026? 我最近测试了几项服务，主要是体育直播，UHDSports 是迄今为止最流畅的服务之一。 我最喜欢的是，它不会让人感觉负担过重或杂乱无章。设置很简单，频道在我的设备上打开得很快，体育直播在高峰时段也很稳定，这通常是大多数提供商开始缓冲的地方。我还在智能电视和安卓设备上对其进行了测试，两者都运行良好。 VOD 方面也很不错，但对我来说，使用它的主要原因是体育直播。如果您要选择一家提供商，我还是建议您先申请免费试用，并在实际的实时比赛中进行测试，而不仅仅是在安静的时段。这才是真正的考验。 我并不是说它完美无缺，但根据我的经验，如果您优先考虑的是稳定的体育直播和快速的支持，UHDSports还是值得一试的。 Re: What Are the Best IPTV Providers in 2026? 如果您厌倦了寻找链接、切换应用程序或在大型比赛期间忍受延迟，那么 tvaccess.xyz 就是为您打造的平台。这项高级付费服务提供世界上所有主要体育赛事——全部采用高清、全高清和 4K 超高清画质，播放流畅稳定。 观看所有体育赛事高清/4K直播，尽在tvaccess.xyz Re: What Are the Best IPTV Providers in 2026? 我同意，在 2026 年选择 IPTV 提供商时，真正取决于可靠性、频道选择和流媒体质量。我也喜欢那些能让我在做决定前轻松核实信息的服务。最近，我在进行其他研究时发现Franklin Property Data对查询房产相关细节很有用。仔细比较各种方案，选择最符合自身需求的服务总是没错的。