正在加载正文…
需求 我觉得呀，我一直缺一个 USB-C 口的集线器。为了能使用 USB-C，我买了好几个转接头长期插在 USB type-A 口上。所以这次我准备先开发一款 3C1A 的 USB HUB，同时通过 USB-C 数据线与电脑连接。 作为业余爱好者，折腾硬件的时候还是容易不小心接错线，上错电，为了避免把电脑一波带走，还是得考虑搞个隔离。 我预计将来大概会折腾使用 USB-C 接口索要 PD...
第二版的隔离 USB-C HUB 开发笔记。对上一版进行了修正和改进，依旧使用 ISOUSB211 作为隔离芯片，改用了 CH335F 作为 HUB。
IsolaPurr USB Hub 是一台面向桌面工作台的有源 USB 集线器和供电模块。它提供 USB-C 上行、USB-C 下行和 USB-A 下行：USB-C 上行承载主机连接，USB-C 下行承担可调供电路径，USB-A 下行则通过独立的隔离 DC/DC 供电，把数据链路和端口电源的边界落到硬件上。
当前正式硬件基线是 tps-sw。CH334P 处理 USB2.0 Hub，CH318T 负责隔离数据链路，URB2405S-3WR3 负责隔离侧供电；CH217、CH442E、TVS0500 和 TPS55288 分别承担接口保护、USB 数据切换、VBUS 保护和可调电源控制。
USB 数据经过 Hub 与隔离链路，端口电源由独立的可调路径管理。控制面同时观察输入资格、端口输出、温度和过流状态，USB 枚举结果不代表端口已经可用。
能力没有得到设备确认时，界面显示已知状态和故障原因，不提供强制开关。未确认状态留在诊断层。
本地 USB、Web Serial 和 LAN 发现都可能同时看到同一台 Hub。系统用完整 device_id 合并这些观察结果，并把端口、硬件 variant、固件版本和网络地址作为同一设备的属性管理；显示用的短名称不能参与身份判断。
更换连接方式仍指向同一份设备配置，操作者看到同一台 Hub 的 confirmed state、能力声明和维护记录。
设备可以通过 Wi-Fi/LAN、Web Serial 或 Local USB 进入控制台。Wi-Fi/LAN 适合日常局域网控制，Web Serial 适合浏览器直接连接，Local USB 由 isolapurr-devd 和 isolapurr 负责串口、代理、烧录和身份校验。三种路径对应不同的生命周期和使用环境。
三条路径最终都解析到同一个完整的 12 字符 device_id。端口、网络和本地保存记录围绕这个身份合并，短前缀只用于显示或输入便利，不能替代完整身份。USB、Wi-Fi 和 LAN 同时出现时，系统仍将它们归并为同一台 Hub。
设备控制面把端口状态和端口能力分开处理。HTTP API 可以读取端口快照，也可以提交端口电源开关和 replug 操作；Web 控制台则根据设备声明的 capability schema 判断某个动作是 supported、unsupported 还是 unknown。
没有足够的兼容性证据时，系统不能凭固件版本或界面猜测来提供危险动作。端口的 confirmed state 是设备真正返回的状态，capability 则是系统是否有依据安全地展示动作，两者分别服务于反馈和准入。
仓库同时保留 tps-sw 和 tps-fusb 两个硬件方案。前者是当前正式版本，后者是下一版设计基线：它计划使用双 FUSB302B，并由 MCU 实现 USB-PD Fixed/PPS 的策略控制，但目前仍处于网表归档和验证前阶段。
当前版本正文只描述 tps-sw 的隔离、端口控制、设备身份和三种连接路径；tps-fusb、主动协议档位配置和未完成的实物验证仍属于后续工程。