嵌入式USB OTG开发实战：从协议原理到TI MCU实现详解

1. 项目概述：USB OTG在嵌入式系统中的核心价值

在嵌入式系统开发中，接口资源往往是寸土寸金的。传统USB架构严格区分了主机（Host）和设备（Device）角色，一个U盘不能直接读取另一个U盘的数据，一个单片机开发板通常也只能被动地作为设备被电脑识别。这种单向性在很多场景下成了瓶颈。USB On-The-Go（OTG）技术的出现，就是为了打破这堵墙，让一个物理接口具备“双重人格”，能在主机和设备角色间智能切换。这不仅仅是增加了一个功能，更是设计思路的转变：从“我是什么”变成了“我能根据需要成为什么”。

想象一下，你的智能手表需要通过USB接口从PC同步数据（设备模式），但偶尔也需要读取一个U盘里的固件进行升级（主机模式）。在没有OTG的时代，你可能需要设计两套不同的硬件电路和软件栈，或者通过复杂的开关电路进行切换，成本高且不可靠。OTG将这种动态角色切换的能力标准化、硬件化，通过检测连接线缆的ID引脚状态和VBUS（总线电源）电压，自动或在应用控制下决定当前的工作模式。其背后依赖两大核心协议：会话请求协议（SRP）允许B设备（默认设备角色）请求A设备（默认主机角色）开启VBUS供电，启动一次会话；主机协商协议（HNP）则在会话建立后，允许A设备和B设备在主机角色上进行交换。

在嵌入式开发中，尤其是基于MCU（微控制器单元）的项目，集成OTG功能意味着可以用一个USB接口实现以往需要两个接口才能完成的任务。例如，一个工业数据采集器，平时作为大容量存储设备（MSC）被上位机读取数据，在现场调试时又可以作为主机，连接键盘、扫码枪进行配置。这种灵活性极大地简化了产品设计，降低了BOM成本，并提升了用户体验。本文将以广泛使用的德州仪器（TI）Tiva/Stellaris系列MCU及其USB库为例，深入剖析OTG功能的实现细节，从硬件原理到软件栈初始化，再到实战编程，为你呈现一份可直接落地的嵌入式OTG开发指南。

2. OTG硬件基础与协议栈工作原理

2.1 硬件信号与角色判定机制

OTG功能的实现，始于硬件上的几个关键信号引脚，理解它们是软件正确配置的前提。

ID引脚（识别引脚）：这是OTG区别于标准USB的最显著标志。在Micro-AB或Mini-AB插座上，ID引脚内部通过电阻上拉或下拉。标准OTG线缆的插头分为A端和B端：

• A端插头（ID脚接地）：当设备插入A端，ID引脚被拉低，硬件逻辑默认此设备应尝试作为主机（A-Device）。
• B端插头（ID脚悬空/上拉）：当设备插入B端，ID引脚被内部电阻拉高，硬件逻辑默认此设备应作为设备（B-Device）。

VBUS（总线电源）：在标准USB中，主机负责提供VBUS（+5V）。在OTG中，VBUS的角色更为动态：

1. 初始状态：双方VBUS均关闭。
2. 会话请求（SRP）：当B设备（如手机）想发起通信时，它可以先后驱动数据线（D+/D-）进行数据线脉冲（Data-line Pulses）和VBUS脉冲（VBus Pulse），向A设备发出SRP请求。
3. 会话开始：A设备检测到SRP后，开启VBUS供电（典型值5V），会话开始。
4. 角色反转（HNP）：会话建立后，如果双方都支持HNP，主机（A设备）可以通过设置特定控制请求，将总线控制权暂时移交给原来的设备（B设备），实现角色互换。例如，打印机（A设备）可以让数码相机（B设备）临时成为主机，以便相机直接读取打印机内存卡中的图片进行打印。

D+/D-（数据线）：除了传输数据，在SRP阶段还被用于发送信号脉冲。

在嵌入式MCU中，USB控制器通常集成了监测这些引脚状态的硬件逻辑，并可以产生相应的中断。开发者的任务，就是正确配置这些引脚的功能（GPIO或USB专用数字功能），并编写软件来响应硬件状态的变化。

2.2 USB库中的OTG协议栈架构

一个成熟的USB库（如TI的usblib）会将复杂的OTG协议处理封装起来，向应用层提供简洁的API。其内部栈结构可以分层理解：

1. 硬件抽象层（HAL）：直接操作USB控制器的寄存器，负责ID引脚状态读取、VBUS电源控制、SRP/HNP相关信号的生成与检测。这一层通常由芯片厂商的驱动库（如TI的DriverLib）提供。
2. OTG驱动层：这是usblib中usbmode.c等文件实现的核心。它向上提供模式管理接口（如USBStackModeSet，USBOTGModeInit），向下调用HAL。它维护一个状态机，根据ID引脚状态、VBUS有无、以及SRP/HNP的交互，在IDLE（空闲）、A_HOST（A端主机）、B_PERIPHERAL（B端设备）等状态间迁移。它还会周期性地“轮询”（Poll）连接状态，并管理一个统一的中断处理入口（USB0OTGModeIntHandler），将中断分发给下层的主机栈或设备栈。
3. 主机栈（Host Stack）和设备栈（Device Stack）：这是两个相对独立的软件模块。当OTG驱动层判定当前应进入主机模式时，它会初始化并激活主机栈；反之则激活设备栈。这两个栈负责处理USB协议本身，如枚举、数据传输、类驱动等。
4. 应用层回调接口：OTG驱动层通过一个模式变更回调函数（tUSBModeCallback）通知应用程序当前的角色状态（eUSBModeHost，eUSBModeDevice，eUSBModeNone）。应用程序据此调整自己的行为，例如，在切换到主机模式时启动文件系统扫描，在切换到设备模式时准备被枚举的描述符。

注意：根据你提供的TI USB库文档片段，该库目前仅支持SRP，而不支持HNP。这意味着使用此库的设备可以实现“请求会话”（从B设备角色请求A设备供电），但无法在供电后与A设备交换主机角色。对于大多数嵌入式应用（如设备偶尔需要充当主机读取U盘），支持SRP已经足够。如果你的应用需要完整的双角色互换（如两个手机互传文件），则需要选择支持完整OTG协议（含HNP）的硬件和软件栈。

3. 嵌入式OTG开发实战：初始化流程详解

理论清晰后，我们进入实战环节。基于TI USB库的OTG功能初始化，是一个有严格顺序的过程，任何步骤错漏都可能导致模式检测失败。下面我们拆解一个完整的初始化流程。

3.1 初始化顺序与关键API解析

正确的初始化顺序是：配置物理引脚 -> 设置库模式与回调 -> 初始化设备栈 -> 初始化主机栈 -> 启动OTG模式。我们结合关键API来理解每一步。

第一步：物理引脚配置OTG功能需要正确的硬件连接。除了标准的USB DP/DM引脚，还需要处理USBEPEN（USB电源使能）和USBPFLT（电源故障）引脚，这两个引脚用于主机模式下的VBUS供电管理。

// 假设 USBEPEN 连接在 PH3, USBPFLT 连接在 PH4 SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH); // 使能GPIOH外设时钟 GPIOPinTypeUSBDigital(GPIO_PORTH_BASE, GPIO_PIN_3 | GPIO_PIN_4); // 配置为USB数字功能

这一步是硬件相关的，必须根据你的具体MCU型号和原理图来确定引脚。GPIOPinTypeUSBDigital是一个关键函数，它将普通GPIO配置为USB控制器专用的数字I/O，内部可能涉及上下拉、驱动强度等特殊设置，不能简单地用GPIOPinTypeGPIOOutput替代。

第二步：设置USB库工作模式与回调这是告知USB库我们将使用OTG模式，并注册一个用于接收模式切换通知的回调函数。

void ModeCallback(uint32_t ui32Index, tUSBMode eMode) { switch(eMode) { case eUSBModeHost: // 进入主机模式，可以开始枚举设备 UARTprintf("OTG Mode: Host.\n"); break; case eUSBModeDevice: // 进入设备模式，等待主机枚举 UARTprintf("OTG Mode: Device.\n"); break; case eUSBModeNone: // 空闲模式，线缆已断开或未连接 UARTprintf("OTG Mode: None (Idle).\n"); break; default: break; } } // 在主初始化函数中调用 USBStackModeSet(0, eUSBModeOTG, ModeCallback);

USBStackModeSet的调用必须早于任何主机或设备栈的详细初始化。参数0通常指第一个USB控制器（USB0）。eUSBModeOTG告诉库我们期望运行在OTG模式。注册的回调函数ModeCallback将在连接状态改变时被调用，这是应用程序感知角色切换的唯一标准途径。

第三步：初始化设备功能栈即使你当前期望作为主机，在OTG模式下，设备栈也必须初始化，因为控制器可能被插到B端。初始化内容取决于你希望设备扮演什么角色（如HID鼠标、CDC串口、MSC磁盘）。

// 示例：初始化为一个HID鼠标设备 extern tUSBDHIDMouseDevice g_sMouseDevice; // 需要预先定义和填充的鼠标设备结构体 USBDHIDMouseInit(0, (tUSBDHIDMouseDevice *)&g_sMouseDevice);

如果你要实现自定义设备类，则需要调用更底层的USBDCDInit()并注册自己的类回调函数。这一步只是准备好了设备模式的“软件能力”，具体是否激活由OTG驱动层决定。

第四步：初始化主机功能栈与设备栈对称，主机栈也需要预先配置，以备切换到主机模式时使用。

// 1. 配置主机模式电源管理 USBHCDPowerConfigInit(0, USBHCD_VBUS_AUTO_HIGH); // USBHCD_VBUS_AUTO_HIGH 表示自动控制VBUS为高电平有效。根据硬件设计，也可能是低有效。 // 2. 注册主机类驱动程序 // g_ppHostClassDrivers 是一个驱动指针数组，例如 {&g_sUSBHostMSCClassDriver, &g_sUSBHostHIDClassDriver} // g_ulNumHostClassDrivers 是数组长度 USBHCDRegisterDrivers(0, g_ppHostClassDrivers, g_ulNumHostClassDrivers); // 3. （可选）初始化特定类驱动的应用层接口 // 例如，如果你注册了HID鼠标主机驱动，并希望收到鼠标数据，需要打开一个实例 USBHMouseOpen(MouseCallback, g_pucBuffer, MOUSE_MEMORY_SIZE);

这里的关键是USBHCDPowerConfigInit，它配置了库内部如何控制USBEPEN引脚来开启/关闭VBUS。USBHCDRegisterDrivers则告诉主机栈：“我支持这些类型的设备，当枚举到匹配的设备时，请用对应的驱动去管理它”。

第五步：最终化OTG模式并启动这是将所有准备工作和硬件连接起来的最后一步。

#define HCD_POLL_RATE_MS 100 // 轮询间隔，单位毫秒 #define HCD_MEMORY_SIZE 1024 // 为主机栈分配的内存池大小 uint8_t g_pHCDPool[HCD_MEMORY_SIZE]; // 主机栈内存池 USBOTGModeInit(0, HCD_POLL_RATE_MS, g_pHCDPool, HCD_MEMORY_SIZE);

USBOTGModeInit函数至关重要：

• ui32PollingRate：轮询间隔。对于A端设备（默认主机），它决定了多久检查一次是否有B设备连接。对于B端设备，它决定了多久发起一次SRP（会话请求）。设置太短浪费CPU，设置太长则连接响应慢。100-500ms是常见范围。设为0则禁用轮询，此时B设备将无法主动请求会话（除非有硬件事件触发），A设备也无法检测到新设备插入。
• pvPool和ui32PoolSize：为主机栈分配的内存池。主机模式需要动态内存来管理设备、管道等数据结构，这个池子就是它的“运行内存”。大小需根据你计划连接的最大设备数和端点数量来估算，通常不少于1KB。

调用此函数后，USB控制器硬件和OTG状态机才真正开始工作，ModeCallback可能会根据当前的连接状态被首次调用。

3.2 主循环与中断处理

初始化完成后，应用程序需要在一个主循环中定期调用USBOTGMain，并确保正确连接了中断。

主循环任务：

uint32_t ui32LastTick = 0; while(1) { uint32_t ui32CurrentTick = SysTickValueGet(); // 获取系统滴答计数 uint32_t ui32ElapsedMs = ui32CurrentTick - ui32LastTick; ui32LastTick = ui32CurrentTick; USBOTGMain(ui32ElapsedMs); // 必须定期调用！ // 其他应用任务... }

USBOTGMain需要传入自上次调用以来经过的毫秒数。它利用这个时间信息来管理轮询定时、处理主机栈中的非实时任务（如设备枚举超时处理）。即使轮询间隔设为0，这个函数也必须被调用，因为它还处理其他内部状态维护。

中断处理： OTG模式需要一个统一的中断服务程序（ISR）来处理所有USB中断。

// 在启动文件或中断向量表中，将 USB0 中断的入口指向 USB0OTGModeIntHandler // 例如，在 startup_*.c 文件中： #pragma DATA_SECTION(g_pfnVectors, ".intvecs") void (* const g_pfnVectors[])(void) = { ... USB0OTGModeIntHandler, // USB0 中断 ... };

USB0OTGModeIntHandler这个函数内部会根据当前是主机模式还是设备模式，将中断分发给USB0HostIntHandler或USB0DeviceIntHandler。你不需要也不应该直接调用主机或设备的中断处理函数。确保这个OTG中断处理函数被正确注册，是OTG功能正常工作的硬件基础。

4. 模式检测、事件处理与调试技巧

4.1 模式切换的完整生命周期与事件流

理解OTG设备从插拔到工作的完整事件流，对于编写健壮的应用和调试至关重要。我们以一个支持OTG的嵌入式设备（下称“本设备”）为例，描绘两种典型场景：

场景一：本设备作为B设备（默认设备）连接至PC（标准主机）

1. 物理连接：将Micro-B公头线缆插入本设备（ID脚被拉高）。
2. 硬件检测：USB控制器检测到ID引脚为高，VBUS由PC提供（约5V）。
3. 库回调：OTG驱动层立即（或极短时间内）调用ModeCallback，传入eUSBModeDevice。
4. 设备枚举：USB设备栈开始工作，响应PC主机发出的各种描述符请求（GET_DESCRIPTOR），完成枚举过程。此时，本设备在PC上被识别为一个HID鼠标（或其他设备）。
5. 断开连接：拔下线缆，VBUS消失。
6. 库回调：OTG驱动层调用ModeCallback，传入eUSBModeNone，表示回到空闲状态。

场景二：本设备作为A设备（默认主机）连接U盘（标准设备）

1. 物理连接：将Micro-A公头线缆（或通过OTG转接头）插入本设备（ID脚被拉低）。
2. 硬件检测：USB控制器检测到ID引脚为低，但VBUS初始为0（因为本设备尚未开启供电）。
3. 轮询与供电：USBOTGMain函数根据设定的轮询间隔（如100ms）检查连接。检测到ID为低且连接稳定后，库内部通过USBEPEN引脚开启VBUS供电。
4. 库回调：VBUS稳定后，OTG驱动层调用ModeCallback，传入eUSBModeHost。
5. 主机枚举：USB主机栈开始工作，向U盘发送复位信号，然后开始枚举流程（获取描述符、分配地址、配置设备）。
6. 设备就绪：枚举成功后，U盘被识别为一个大容量存储设备（MSC），主机栈会调用之前注册的MSC类驱动回调，通知应用层有设备连接。
7. 断开或移除：U盘被拔出，主机栈检测到设备移除。
8. 库回调：主机栈处理完移除事件后，OTG驱动层可能（取决于实现）会调用ModeCallback，传入eUSBModeNone。同时，库会关闭VBUS以节省功耗。

实操心得：在ModeCallback中，除了打印日志，你应该进行重要的状态切换。例如，切换到主机模式时，才启动文件系统线程或扫描存储设备；切换到设备模式时，才使能特定的数据发送任务；切换到eUSBModeNone时，则释放相关资源、关闭文件。避免在错误模式下访问硬件资源。

4.2 常见问题排查与调试指南

OTG开发中遇到的问题往往与硬件、初始化顺序或配置相关。下面是一个快速排查清单：

调试工具推荐：

1. 逻辑分析仪：捕获DP/DM线上的USB数据包（低速/全速），直接观察枚举过程、SRP信号，是终极调试手段。
2. USB协议分析仪：专业工具，能解析高层协议，但成本高昂。
3. 串口打印：在ModeCallback和各个驱动回调函数中加入详细的串口打印信息，是最简单有效的软件调试方法。
4. LED指示灯：用不同的LED组合表示当前模式（空闲、主机、设备），便于快速判断状态。

5. 进阶应用与性能优化考量

5.1 动态资源管理与低功耗策略

在资源受限的嵌入式系统中，OTG的双模式意味着你可能需要同时为两种角色准备资源（如描述符表、类实例、数据缓冲区）。一种高效的策略是动态分配与懒加载。

• 内存池共享：为主机栈分配的内存池（g_pHCDPool）只在主机模式下被使用。在设备模式下，这部分内存可以被应用程序临时借用（需谨慎，确保切换回主机模式前归还）。
• 外设与任务管理：在ModeCallback中根据模式开关相关外设和软件任务。例如，作为MSC设备时，才挂载SD卡并启动文件系统任务；作为MSC主机时，才初始化SPI Flash驱动并启动扫描任务。这能有效节省功耗和CPU占用。
• 轮询间隔调节：在电池供电场景下，可以通过USBOTGPollRate()动态调整轮询间隔。当设备处于空闲（eUSBModeNone）且对响应速度不敏感时，将轮询间隔调大（如1000ms）以降低功耗。当检测到用户可能进行操作时（如按下某个按钮），再将轮询间隔调小（如100ms）。

5.2 构建健壮的双角色应用框架

基于回调的模式切换机制，可以设计一个清晰的状态机来管理整个应用：

typedef enum { APP_STATE_IDLE, APP_STATE_DEVICE_MSC, APP_STATE_HOST_MSC_SCANNING, APP_STATE_HOST_MSC_READY, } AppState_t; static AppState_t g_eAppState = APP_STATE_IDLE; static void *g_pvCurrentFS = NULL; // 指向当前挂载的文件系统对象 void ModeCallback(uint32_t ui32Index, tUSBMode eMode) { switch(eMode) { case eUSBModeDevice: if(g_eAppState != APP_STATE_DEVICE_MSC) { DeinitHostResources(); // 清理主机资源 g_eAppState = APP_STATE_DEVICE_MSC; InitDeviceMSCHardware(); // 初始化设备模式所需的硬件（如SD卡） // USB设备栈已在初始化时配置好，等待主机枚举即可 } break; case eUSBModeHost: if(g_eAppState == APP_STATE_IDLE || g_eAppState == APP_STATE_DEVICE_MSC) { DeinitDeviceResources(); // 清理设备资源 g_eAppState = APP_STATE_HOST_MSC_SCANNING; InitHostMSCHardware(); // 初始化主机模式所需的硬件（如SPI Flash） // 主机栈会自动开始枚举，枚举成功后会通过MSC驱动回调通知我们 } break; case eUSBModeNone: // 统一清理资源，回到初始状态 DeinitHostResources(); DeinitDeviceResources(); g_eAppState = APP_STATE_IDLE; g_pvCurrentFS = NULL; break; } } // MSC主机驱动连接回调示例 void MSCHostCallback(uint32_t ui32Event, void *pvData) { if(ui32Event == USB_EVENT_CONNECTED) { // 枚举到MSC设备 g_eAppState = APP_STATE_HOST_MSC_READY; // 挂载文件系统 if(f_mount(&g_fs, "0:", 1) == FR_OK) { g_pvCurrentFS = &g_fs; UARTprintf("MSC Device mounted.\n"); } } else if(ui32Event == USB_EVENT_DISCONNECTED) { // 设备移除 if(g_pvCurrentFS) { f_unmount("0:"); g_pvCurrentFS = NULL; } g_eAppState = APP_STATE_HOST_MSC_SCANNING; } }

这个框架确保了状态转换时资源的正确初始化和释放，避免了内存泄漏或硬件冲突，使得应用程序逻辑清晰，易于维护和扩展。