USB通信：从插上线那一刻起，你的设备究竟经历了什么？
你把一个USB麦克风插进电脑——指示灯亮了，系统弹出“新硬件已识别”，几秒后录音软件就能用了。整个过程快得让人忽略背后发生了什么。但如果你正调试一款自研的USB设备，却卡在“设备未识别”、或者枚举成功后数据传不出去、又或者音频断续像卡碟……这时候你会发现：USB不是一根线加两个插头，而是一整套精密协作的状态机、协议栈与硬件时序系统。
它不声不响地完成了物理连接检测、供电协商、地址分配、能力自报、驱动匹配、端点启用、数据流调度……这一连串动作，全在100毫秒内自动完成。而一旦其中任意一环出错，比如描述符里一个字节填错了、复位信号没拉够10ms、控制端点响应超时了——整条链就断了，且错误现象往往模糊：主机日志只写“device descriptor read/64, error -71”，你得自己反推是哪一步崩了。
所以今天，我们不讲教科书式的分层模型，也不堆砌USB-IF文档里的术语定义。我们回到开发板前、示波器旁、逻辑分析仪上，以工程师真实排障视角，重走一遍USB通信的完整生命周期：从D+线被上拉电阻轻轻拽高那一瞬开始，到第一包PCM音频数据稳稳落进应用缓冲区为止。
插上去的那一刻：物理握手如何启动一场协议对话？
USB的“即插即用”，起点不是软件，而是两条差分线上的电压变化。
当设备插入主机，如果它是全速设备（FS），内部会在D+线上接一个1.5kΩ上拉电阻；如果是低速设备（LS），则上拉D−。这个微小的电阻，让主机PHY立刻感知到“有东西来了”——不是靠中断，而是靠持续监测D+/D−是否出现SE0状态（即D+和D−同时为低电平）。SE0的出现与消失，就是USB世界的“敲门声”。
但敲门不等于能进门。主机收到信号后，会立即发出一个强制复位（Reset）：保持SE0至少10ms。这是USB协议里最硬性的时序要求之一。很多初学者用MCU模拟USB设备时，第一关就栽在这儿——延时不精确、或复位期间意外释放了D+上拉，导致主机判定设备“无响应”，直接放弃枚举。
复位结束后，设备进入默认地址（Address 0）状态，此时它唯一能响应的，只有发往地址0、端点0的控制请求。注意：这个“地址0”是临时身份，就像酒店前台给客人暂发的访客牌，不能用来干别的事。主机接下来要做的，就是给它正式发一张带房间号的房卡——SET_ADDRESS请求。
这里有个关键设计哲学：所有设备出厂都是“匿名状态”，地址由主机统一分配，彻底避免冲突。你永远看不到两个USB设备抢同一个地址，因为主机在发SET_ADDRESS前，会先确保总线上没有其他设备正在用那个号。这也是为什么热插拔能如此可靠——新设备进来，老设备还在跑，互不干扰。
枚举：一场严谨的“设备面试”，靠描述符说话
地址有了，接下来就是“面试环节”：主机要搞清楚你是什么、能干什么、需要多少资源。这个过程叫枚举（Enumeration），本质是一组按严格顺序执行的控制传输。
它不是随便读几个字节，而是一条强依赖链：
- 主机先发
GET_DESCRIPTOR(DEVICE)→ 你必须返回2-byte的bLength <
