公板接口选型与调试实战：USB/HDMI/网口/WiFi/CVBS全解析-平芜编程栈

1. 拿到公板先别急着焊线：接口选型的底层逻辑

手里的公板正面密密麻麻排了一排接口：USB、HDMI、网口、WiFi天线座，还有一颗CVBS莲花座。这类板子我一年能见几十块，客户问的第一句话基本都一样：“这么多口，我到底用哪个？”要回答这个问题，不能只看接口本身，得先搞清楚板子背后是什么方案、核心芯片的资源和成本分摊，以及你的产品最终要部署在什么环境里。

所谓的“一套公板五种接口”，本质上是方案商为了提高通用性，把常用外设接口全引出来了。同样的主控，既可以用作网络摄像头，也可以做广告机、工业HMI、车载终端、门禁主机，每种场景对应的音视频和数据上行方式完全不同。所以公板存在的意义，就是让你在产品定义阶段把接口选对，省掉后面重新画板、重新过认证的时间和钱。

做接口选型时，我习惯先问四个问题：

数据往哪走：是本地传输，还是云端？带宽需求多大？
供电条件：现场有没有稳定的220V或者POE，还是只能靠电池？
物理距离：设备到显示端、到交换机的距离是几米、几十米还是上百米？
环境复杂度：是否有强电磁干扰、高温、振动，或者需要防雷？

这四个问题的答案，基本就把接口锁死了一大半。比如说，如果你做的是分布式工业采集终端，现场到上位机距离超过50米，那CVBS和USB基本可以排除，HDMI也不合适，网口或者光纤才是正经方案；如果你是做便携式测试仪器，内部板对屏距离不到20厘米，那MIPI、LVDS或者HDMI里选一个就行，网口和WiFi只是作为扩展数据通道存在。

还有一个很容易被忽略的问题：公板的接口不是独立存在的，它们往往共享主控的同一组控制器。比如同一颗SoC上，USB3.0和PCIe可能是复用引脚，HDMI和LVDS/RGB可能共享显示控制器；接了HDMI以后，某些分辨率下要占掉额外的内存带宽，导致WiFi吞吐下降。这种资源竞争在纸面上看不出来，必须实际跑起来才能暴露。所以我的习惯是：选型阶段先画一张“接口占用和资源冲突表”，把主动能、复用关系、带宽占用列清楚，再去做裁切。

2. 五种接口逐个拆解：特性、应用场景与典型坑

2.1 USB：从枚举、供电到Type-C角色切换

USB是公板上最“万金油”的接口，既能传数据，又能供电，还能做调试、升级、外接存储和4G模组。但正因为太通用，它的坑反而最多。USB 2.0的理论速率是480Mbps，USB 3.0是5Gbps，注意这是总线速率，实际有效吞吐要打七八折。做视频传输时，USB 2.0跑1080P的UVC摄像头勉强能扛，但跑4K就很容易丢帧，这时你需要的不是换软件，而是换USB 3.0或者走CSI/MIPI接口。

很多人卡在USB最基础的问题上：设备插上没反应，Windows右下角弹“无法识别的USB设备”。第一件事不是重装驱动，而是先看设备管理器里的硬件ID。比如 VID_0403&PID_6001 是FTDI的FT232R，VID_0403&PID_6015 是FT231X，VID_1A86 是CH340，VID_10C4 是CP210x。拿到VID/PID之后去查芯片手册，确认到底是驱动没装、线材问题，还是设备枚举失败。

网上搜“ft231x usb uart驱动”“ft232r usb uart驱动安装”“ztek力特usb转232驱动”的人特别多，说明大量工程现场还在用USB转串口来调试设备。这类方案的优点是不需要主板上单独预留UART调试口，插一根USB线就能进串口终端；缺点是遇到劣质线材或芯片供电不稳时，会出现“识别正常但一打开串口就乱码”“插拔几次后系统蓝屏”“在Linux下ttyUSB设备名随机漂移”等问题。我一般建议，量产产品里如果有固定调试串口需求，就不要依赖USB转串口线，直接在板上引出排针，成本低且稳定得多。

USB调试还有一个很实用但容易被忽略的方向：抓包。硬件上可以用USB分析仪（常见的是基于FPGA或者专用芯片的盒子），软件上Windows可以用USBlyzer或者Wireshark配合USBPcap。抓包的核心目的是回答三个问题：设备有没有完成枚举、端点描述符对不对、批量传输的包有没有超时重传。很多“设备偶尔掉线”的玄学问题，最后都是抓包抓到主机发了RESET但设备没有ACK，定位到是设备端固件处理异常或者供电不足。

再提一个很具体的高频搜索问题：Type-C接口的CC引脚有一个5.1k下拉电阻，那怎么把设备切到主机模式？简单说，Type-C设备管脚里CC1/CC2上的电阻就决定了角色：Device端在CC引脚到地之间接5.1k下拉，Host端则接上拉电阻（典型56k、22k、10k）。如果公板把Type-C座引到了带DRP（双角色端口）功能的控制器，那固件里还需要配置“Try.SNK”或“Try.SRC”策略。调试时如果发现插了U盘没反应，先量一下CC引脚电平，再确认主控是否切到了Host模式，很多“明明接了5.1k下拉却转不了主机”的问题，其实是DRP策略里没有允许角色切换。

2.2 HDMI：19脚HPD、DDC与RE整改经验

HDMI是公板做音视频输出的主力接口。标准HDMI Type-A一共19个引脚，很多工程师第一眼看到引脚定义会懵，但核心就三类信号：TMDS差分数据（4对，引脚1~10）、DDC通道（引脚15 SCL、16 SDA）、以及热插拔检测HPD（引脚19）。其中19脚HPD特别关键，它是显示器和主机之间的“握手信号”：显示器检测到HDMI线插入后，通过19脚拉高通知主机“我在这”，主机才开始读EDID、配置输出。遇到HDMI无信号问题，第一步不是怀疑驱动，而是拿示波器打19脚电平：如果一直是低，说明HPD没拉起来，要么线坏，要么EDID通道上的上拉和ESD保护器件把信号拉挂了。

HDMI的电路设计有两条铁律：第一，TMDS差分对的阻抗要控制在100Ω±10%，Layout上要等长、包地、远离电源和时钟。第二，连接器入口必须有ESD保护器件和共模电感，否则不止雷击和静电容易打坏芯片，RE（辐射发射）测试大概率也会超标。网上搜“hdmi re测试整改”能搜出一堆案例，基本都指向这几个原因：连接器接地不可靠、差分线过孔太多导致阻抗突变、TMDS线没有包地、5V电源去耦不充分。我做过一次整改实验，把HDMI连接器下方的地平面挖空，然后把金属外壳直接多点接地，RE整体降了大概6dB，效果立竿见影。

再聊一个和音频相关的常见问题：HDMI怎么输出音频？它的音频不是靠单独线传，而是以数据包的方式打包在TMDS信号的“数据岛”里。也就是说，音频和视频在同一根HDMI线里走，只是时分复用。公板调试时如果HDMI画面正常但没声音，要先看主控的音频通路是否配置成了HDMI输出，再看显示器或电视是否选择了对应输入源。如果用的还是老的转接方案，比如从I2S先转成SPDIF再包进HDMI，那还要检查采样率是否匹配，很多电视只认48kHz，44.1kHz会直接没声音或者破音。

2.3 网口：从千兆定义到点对点调试

网口是公板里“最皮实”的接口，也是做设备联网的首选。百兆以太网只用了8根线中的4根（1、2、3、6），千兆则必须用满全部4对差分线。千兆网口的针脚定义里有三对是双向的（BI_D3+/BI_D3-、BI_D4+/BI_D4-），只有1、2是一对发送，3、6是一对接收。所以焊接网口座子时，随便少焊两根线可能百兆还能通，千兆就死活协商不起来。

网口调试有不少成熟的工具链。命令行下最常用的是 ethtool，可以查link状态、协商速率、网卡参数。吞吐测试用 iperf3，比随便复制文件靠谱得多。设备端抓包用 tcpdump 或者 Wireshark，分析TCP重传和丢包。网上常看到的“网口调试助手”（比如SocketTool、NetAssist）主要是用来调试TCP/UDP应用层的，适合快速验证上位机和设备之间的协议通断。我用它做HMI调试时很顺手，尤其是和组态屏（比如MCGS触摸屏）联调网口收发驱动，点几下就能确认数据帧有没有送达。

选工业场景时，很多人会把CAN和网口放一起对比。最简单的差异：CAN是总线型拓扑，一挂几十个节点，抗干扰强、实时性高，但速率一般最高1Mbps左右；网口是星型或树型拓扑，速率高、扩展容易，但现场布线要考虑交换机、线缆、接头质量和距离限制。如果只是做“设备到云端”的数据上传，网口比CAN合适得多；如果是产线内部总线和实时控制，CAN仍然更顺手。

还有一个容易被忽略的场景是服务器或者工作站上的网口聚合，也就是把多个物理网卡绑成一个逻辑网口，增加带宽或者做链路冗余。在国产操作系统环境下，比如很多服务器运维场景里，网口聚合需要先看驱动是否支持bonding/teaming，再决定用负载均衡还是主备模式。公板调试时不一定要配置聚合，但你得知道这个思路，因为客户可能要求“双网口互为备份”，这比堆一堆USB转网口要可靠得多。

2.4 WiFi：连接不稳定时到底该抓哪些log

WiFi接口在公板上承担的是“去线缆化”的任务。它最大的价值是让设备可以在不方便布线的地方部署，比如移动终端、智能家居、会议室设备。但要命的是，无线通信的排查难度比有线高一个数量级。网上关于“wifi或热点连接不上”“wifi或热点断连”“wifi上网慢应该抓什么类型的log”的搜索量常年排在前列，就是因为问题太常见，而且原因五花八门。

我排查WiFi问题的固定流程是：先看设备端三层日志，再看系统事件日志，最后才动网络抓包。以Linux设备为例，连接不上时，第一步看 wpa_supplicant 的日志（默认在系统日志里），里面会明确记录扫描结果、认证阶段、四次握手状态。如果wpa_supplicant里一直卡在“4-way handshake timeout”，大概率是密码错误或者AP端开启了PMF但设备端不兼容。如果连到了AP但拿不到IP，那就是DHCP交互问题，重点看dhclient或者NetworkManager日志，也可以直接 tcpdump port 67 or port 68。如果是连上之后频繁断连，要重点看内核的cfg80211和驱动日志，确认是不是信号强度（RSSI）在临界值附近反复横跳，或者AP开启了多频段漫游导致设备在2.4G和5G之间频繁切换。

很多人一碰到WiFi上网慢就想“是不是有人蹭网”，但在工程场景里，第一个要查的永远是信号和质量指标。用 iw dev wlan0 link 可以看当前连接的RSSI和协商速率，用 iw dev wlan0 scan 可以看周围AP的信道占用。如果RSSI低于-70dBm，协商速率掉到几十Mbps，那问题大概率不是带宽被抢，而是距离或者遮挡太严重。这时候调整天线方向、加AP数量、换信道，比破解什么密码有用得多。网上那些“wifi密码破译”“wifi密码本”“wifi密码工具字典”的词条，在我看来的实际工程价值很低，因为主流无线协议早就把暴力破解这条路堵得很严了，把自家AP的加密等级、信号覆盖和漫游策略调好，才是真正能落地的事。

另外有一个特别容易被坑的场景：很多WiFi模块在没有外接天线或者天线匹配不良时，能搜到信号但速率极低。公板上的WiFi天线座，阻抗通常是50Ω，天线的匹配网络（π型网络）和PCB走线如果不对，驻波比会很难看。调试时不要只看能不能ping通，用 wavemon 或者 iw 看RSSI和TX/RX bitrate，如果被压在6Mbps或者1Mbps，先怀疑天线，再怀疑驱动，最后才怀疑环境干扰。

2.5 CVBS：老而不死的模拟视频接口

CVBS全称是Composite Video Blanking and Sync，复合视频广播信号。它在数字时代显得很“古老”，但依然活跃在安防、车载、医疗内窥镜、部分传统工控设备上。原因很简单：它便宜、传输距离远、现场兼容性好。一根同轴线就能传标准清晰度视频，PAL制式大概720×576分辨率，NTSC制式720×480，带宽需求低，几十上百米的线缆衰减问题也比HDMI好处理得多。

CVBS的调试要点在于制式统一和地环路。公板上如果同时引出CVBS和数字视频输出，需要确认主控的视频编码器是否设置了正确的制式。调试时画面出现滚动条、闪动、颜色不对，要么是制式不匹配（PAL/NTSC混淆），要么是信号地有电位差。我在一个车载项目里遇到过CVBS画面有明显网纹干扰，最后发现是设备外壳接地和电源地的单点连接没处理好，形成了一条环路。把CVBS连接器的屏蔽层和系统地在靠近连接器位置直接汇接后，画面立刻干净了。

CVBS的“选”很多时候是被迫的：项目要求兼容老式监视器、客户现场已经铺好了同轴线、或者产品需要做视频环出。但在新项目里，如果只是为了“有个视频接口”，我一般不建议首选CVBS，因为720P/1080P是主流，HDMI和网口能给的画质上限更高。CVBS适合的场景，本质上是“数字改造实在太贵”的传统替换市场。

3. 一张表搞懂选型：从场景到接口的决策参考

3.1 五种接口能力对比总表

把五种接口放在同一个维度下比较，选型会直观很多。参数不是绝对的，不同主控实现会有差异，但作为初筛足够用。

接口	典型速率/画质	传输距离	供电能力	适合场景	成本量级
USB	USB2.0 480Mbps / USB3.0 5Gbps	建议5m内	支持，USB2.0一般500mA，USB3.0一般900mA	外设扩展、调试、U盘升级、4G模组	低
HDMI	1080P@60 / 4K@30~60	建议5m内，线材好可更远	仅5V握手，不承担主供电	显示输出、音视频一体、广告机	中
网口	百兆/千兆/2.5G	铜缆100m	可通过PoE供电（802.3af/at）	数据上云、远程维护、设备联动	低
WiFi	协商速率几十Mbps到数Gbps	室内几十米，视环境而定	本身不供电，设备需电池或适配器	移动/免布线部署、多设备无线接入	中
CVBS	PAL约720×576 / NTSC约720×480	同轴线可达几十米甚至百米	无	替换老式模拟设备、低成本画面输出	极低

这张表最值得看的两行是“供电能力”和“传输距离”。网口在这两项上往往是综合最优的：100米长度内供电+通信一起解决，性价比极高。USB的短板是距离，HDMI的短板也是距离，WiFi的短板是稳定性和带宽共享，CVBS的短板是画质天花板低。如果项目里“距离超过20米、需要供电、还要传数据”，那答案基本就是网口。

3.2 套用具体场景的选型决策路径

做一个室内广告机：核心输出是HDMI，管理通道用网口，外场维护人员用USB升级固件，WiFi是可选项。主控资源不足时先砍WiFi，广告机通常有线部署，无线只是位置调整时的备用。
做一个工业数据采集器：现场采集走CAN或者串口，上行用网口，远程运维用4G模组（多半是USB或PCIe接口），调试口用板载排针，不占用USB资源。
做一个低端模拟摄像头：前端输出CVBS，后端汇聚走同轴线到DVR或编码器。这个场景里HDMI和USB反而用不上，选型要克制。
做一个便携式近场显示终端：屏幕和主控之间用MIPI或LVDS，如果只有HDMI输出则加转接芯片，数据上行用WiFi，供电用USB Type-C。这种移动形态下，网口基本不会出现在最终产品里。

选型时还有一个容易漏掉的点：公板的某个接口在规格书里写了支持，但实际量产型号可能被硬件裁掉了。拿到板子先对着丝印和原理图核对一遍，别等layout做完了才发现HDMI座子旁边根本没有5V和HPD走线。

4. 实操复现：一块典型公板的五口调试过程

4.1 初始环境确认与工具准备

我拿手里的这块Linux公板举例，主控是国内常见的视频处理平台，SDK自带buildroot。上电前先确认三件事：电源适配器规格（通常12V/2A以上）、串口调试线的电平（板子大概率是UART 3.3V TTL，不能用RS232电平直接怼）、以及HDMI/CVBS显示设备是否就绪。调试系统启动用串口，接法很简单：USB转TTL模块的TX接板子RX，RX接板子TX，GND共地，波特率一般115200。

上电后在串口终端里看到uboot启动日志，基本就能确认系统在跑。然后我习惯先把所有接口的驱动确认一遍，命令大致是：

dmesg | grep -E "usb|hdmi|eth|wlan|cvbs" lsusb ethtool eth0 iw dev

看到对应设备节点都出现了，再往下做功能验证。这个步骤看似基础，但能抢救大量“以为硬件坏了实际是驱动没编进去”的时间。

4.2 USB接口调试：枚举、驱动与抓包

把U盘插到USB-A口，串口里立刻看dmesg：

usb 1-1: new high-speed USB device number 2 using s5p-ehci usb-storage 1-1:1.0: USB Mass Storage device detected sd 0:0:0:0: [sda] 15138816 512-byte logical blocks

这表示枚举成功。如果只出现“new high-speed USB device”而没有后续厂商/产品信息，多半是设备端描述符返回异常，或者USB线太长导致信号完整性不够。这时用短的高质量线再去试一次，如果问题消失，就是线材问题。

USB抓包的场景是排查“板子和加密狗、读卡器之类外设偶发通信失败”。Windows下用Wireshark加USBPcap能看到URB（USB Request Block）的完整过程，重点看SET_ADDRESS、GET_DESCRIPTOR、SET_CONFIGURATION这几步是否都成功。Linux下可以在板端直接抓，比如插上设备后用 usbmon：

modprobe usbmon cat /sys/kernel/debug/usb/usbmon/1u

或者用 wireshark-gtk 打开 usbmon 接口。我曾经用这个方法抓到一个“加密狗每隔几分钟断一次”的问题，最后定位到是主机端开启了USB自动挂起，设备长时间无数据就直接进了suspend状态。在系统里禁用 autosuspend、或者设置 /sys/bus/usb/devices/1-1/power/control 为 on，问题即刻消失。这个坑在嵌入式Linux上非常普遍，排查顺序值得记住：先枚举，再抓包，再看电源管理。

4.3 HDMI输出验证与HPD排查

HDMI调试我按“信号链路三步走”。第一步，插上显示器后先看HPD：串口里执行 cat /sys/class/drm/card0-HDMI-A-1/status，正常情况下从 disconnected 变为 connected。如果一直是 disconnected，用示波器测连接器19脚的电平，正常插上显示器后应该是高电平（5V或3.3V）。HPD拉不起来时，查DDC通道的ESD器件有没有漏电，查主板5V_LCD到HDMI座第18脚是否短路或者断路，这是最常见的原因。

第二步，确认EDID读取成功。Linux下可以用：

cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode

如果读不到EDID，显示器设了“快速启动”或者兼容性差，偶尔也会导致I2C通信失败；但更常见的是DDC走线太长、线上电容太大把I2C时钟拉塌了。EDID读成功后再看分辨率列表，确认主控是否支持客户显示器的原生分辨率。

第三步，谈一谈RE整改。HDMI在布线不好时，TMDS的时钟和Data信号会产生明显辐射超标。整改的优先级是：连接器金属外壳可靠接地 → 增加共模电感 → 调整TMDS对地的串阻/端接电阻 → 尝试展频（SSC）。如果你在调5V、HPD、EDID都正常但电视依然闪屏，可以用差分布线和信号完整性视角重新审视HDMI座附近，很多闪屏都是差分对等长没控制好造成的。

4.4 网口吞吐测试与直连调试点对点

先给网口配一个静态IP，直连电脑网口：

ifconfig eth0 192.168.1.123 netmask 255.255.255.0 up ethtool eth0

ethtool 输出里重点看Speed: 1000Mb/s，以及Link detected: yes。如果Speed只有100Mb/s，而且确认对端电脑是千兆网卡，那大概率是8根线里有一对没接好，或者网卡自动协商策略限制。

吞吐测试用iperf3，棒法分两端：电脑端开服务器，板端跑客户端；反过来再测一次，确认上下行都正常。台式机和控制器的MAX次数就对调，我遇到很多“网口能通但很慢”的案例，跑到iperf3之后发现下行只有100Mbps，上行正常，最后定位到是某对差分线一端接触不良，RX方向重传率高，TX方向没问题。这种问题只靠ping完全发现不了。

有时候公板没有装iperf3，可以临时放到文件系统里，或者用内置的speedtest工具。但实时测试一定要放在两个方向上分别压测，而不是只ping几千个包就算完。对于“网口调试助手”类的工具，适合应用层调试，不适合带宽测试，别混用。工业HMI、PLC、组态屏联调时用TCP调试助手确实方便，验证指令一发一收很直观；但要评估整条链路的承载能力，还是要上协议压力工具。

4.5 WiFi现场信号记录与配置检查

WiFi调试时，我习惯把现场指标记录下来：信号强度RSSI、信噪比、协商速率、信道。在Linux下最常用的命令：

iw dev wlan0 link iw dev wlan0 scan | grep -E "SSID|freq|signal"

配完wpa_supplicant之后，可以看它的日志确认认证流程。日志里如果出现“CTRL-EVENT-SUBNET-STATUS-UPDATE”，说明DHCP已经拿到地址。如果设备端一切正常但就是连不上热点，要检查热点本身是不是“需要操作，没有Internet，打开浏览器并连接”的Portal认证模式。这个模式对物联网终端极其不友好——设备能完成WiFi连接、能拿到IP，但访问外网时会一直被重定向到认证页面。要么让客户把设备MAC加入白名单，要么用支持企业级认证的方式接入。

还有一个很常见的体验类问题：笔记本连上了热点，也可以上网，但任务栏不显示WiFi连接符号。这通常不是WiFi坏了，而是系统网络图标状态与驱动上报不一致。在Windows里重置WLAN服务或者删除无线配置再重连能解决，Linux里则可能是NetworkManager和WPA Supplicant的DBus状态没同步，重启NetworkManager即可。这类问题不影响设备本身，但现场排查经常被当成“断网”，耽误不少时间。

4.6 CVBS通路检测与画面干扰处理

CVBS调试最简单，但也最容易因为“太简单”而忽略细节。先确认接口电平，标准CVBS是1Vpp（含同步头），用示波器在莲花头中心针能看得很清楚。如果输出波形幅度只有几百毫伏，画面会偏暗甚至无图；这种问题多见于主控的DAC后端缺少75Ω端接电阻，或者串了太高的滤波电阻。

接到显示器上以后，如果画面出现黑白滚动条，先改主控输出制式，把PAL改成NTSC再试一次，很多老监视器对不同制式很挑剔。如果画面有斜向干扰纹，通常是电源纹波耦合进视频信号，在CVBS输出端加磁珠和电容，并把信号地单点接入大地，基本能解决。CVBS这种接口的最大优点是调试成本极低，只要示波器和一台老电视就能验证，十分适合现场紧急排查。

5. 常见问题速查表与实战处理经验

5.1 按接口分类的排查速查表

接口	现象	常见原因	快速验证方法
USB	插入设备无反应	枚举异常、供电不足、线材损坏	lsusb/dmesg，换短粗线材对比测试
USB	识别异常，VID/PID显示ffffff	控制器被复位或供电不稳	示波器量VBUS和D+/D-，检查电源纹波
HDMI	无画面，HPD不拉高	线材、EDID通道、ESD器件损坏	测量19脚电平，更换线材
HDMI	有画面无声音	音频通路配置或显示设备输入源问题	确认主控音频输出策略，换HDMI口测试
网口	百兆通千兆不通	有一对差分线断开或接触不良	用测线仪测8根线，ethtool看速率
网口	直连丢包率高	网线质量差、接地环路、交换机端口问题	iperf3双向压测，换线换口对比
WiFi	频繁断连	RSSI过低、频道拥挤、漫游切换	iw dev wlan0 link 记录RSSI和信道变化
WiFi	能连上但拿不到IP	DHCP异常、Portal认证	抓包看DHCP交互，确认网关是否下发地址
CVBS	花屏/颜色不正	制式不匹配、地环路干扰	切换制式，示波器看输出波形和幅度
CVBS	有网纹和斜杠	电源纹波大、地环路	加磁珠和电容，单点接地

5.2 实战中反复踩过的坑和解决办法

做公板接口调试这几年，我印象最深的一类问题，是“单接口测都没问题，把五个接口全挂上就出幺蛾子”。比如USB存储读写的同时，HDMI输出出现轻微横纹；或者千兆网口满速传输时，WiFi速率明显下降。这类问题的根子在于主控的电源和内存带宽争抢，不是任何单一接口的电路坏。解决办法是，在产品设计阶段就把工作负载的峰值需求预估进去，并在锅炉软件里做好低功耗调度和内存分配策略，避免所有外设同时跑满。

USB转串口的驱动问题也很典型。很多人在Windows下用FT231X或者FT232R，装了官方驱动还是报驱动错误，最后发现是插在了USB3.0口上，而芯片老版本驱动对USB3.0控制器兼容性差。这种时候把设备换到USB2.0口，或者更新驱动到最新版本，问题立解。现场调试时多备一根做过标记的“确认没问题”的线，能省掉大量“问号怀疑人生”的时间。

HDMI的EMC整改，我建议所有做硬件的人都自己过一次RE预测试，哪怕只是用近场探头粗略扫一遍。整改经验告诉我：大多数HDMI的RE超标，不是芯片问题，而是连接器附近的地和信号回流路径没处理好。HDMI连接器下方必须有完整地平面，安装孔要可靠连到机壳地，TMDS差分对在Top层走线时下方不能被割裂。做到这些，后面的正式认证会顺很多。

还有关于WiFi天线，我吃过一次比较大的亏。一块公板在办公室调试时，WiFi速率一切正常，到了客户现场就卡成狗。后来发现客户现场墙体厚、点位密，8dBm的板载天线根本打不透，而同型号设备在样板间里只隔了一堵普通石膏墙，表现当然好。WiFi选型一定要结合部署点位和建筑结构，不能只看实验室测试数据。

最后再分享一个习惯：无论选哪种接口，我都会在公板上做一次“全接口老化测试”，把USB读写、HDMI播放、网口跑吞吐、WiFi视频流、CVBS输出同时开启，连续跑48小时。很多“日常用没问题、一上线就故障”的问题，最后都是在老化测试阶段暴露出来的。接口选型不是拍脑袋，更不是看哪根线粗就选哪个，而是把需求、环境、成本和验证手段全部过一遍后，留下的那个最合理的答案。