ESP32-S3 免驱 USB 摄像头实战：TinyUSB UVC 协议与 OV2640 图像传输

1. 项目缘起与整体设计思路

1.1 为什么想到用 ESP32-S3 做免驱摄像头

手头有一块 ESP32-S3 开发板和一颗 OV2640 摄像头模组，最初的想法很简单：能不能让这块小板子插到 Windows 电脑上，直接识别成一个摄像头设备，不需要装任何驱动，打开相机应用就能看到画面。这个需求听起来不复杂，但真正动手之后才发现，里面涉及的东西比想象中多得多。

传统的 USB 摄像头方案，要么用专用的 USB 摄像头芯片，要么用 Linux 开发板跑 UVC 协议栈，成本和复杂度都不低。ESP32-S3 这颗芯片有意思的地方在于，它原生支持 USB OTG，也就是说它可以直接作为 USB 设备与主机通信，而不需要额外的 USB 转串口芯片。再加上 ESP-IDF 里面集成了 TinyUSB 协议栈，而 TinyUSB 本身就支持 UVC（USB Video Class）设备类，这就为免驱摄像头方案提供了硬件和软件两方面的基础。

我选择这个方案的核心考量有三点。第一是成本，ESP32-S3 开发板加上 OV2640 模组，整体成本可以控制在一个比较低的水平，相比买一个成品 USB 摄像头，自己做的乐趣和可定制性完全不一样。第二是免驱，UVC 是 USB 官方定义的标准设备类，Windows、Linux、macOS 都自带 UVC 驱动，插上就能用，不需要额外安装任何东西。第三是可扩展，ESP32-S3 本身是一颗带 Wi-Fi 和蓝牙的 MCU，做成 USB 摄像头之后，还可以同时跑其他任务，比如图像处理、网络传输等，这是成品摄像头做不到的。

1.2 UVC 协议到底是怎么回事

UVC 全称是 USB Video Class，翻译过来就是 USB 视频设备类。你可以把它理解成 USB 协议家族里专门为视频设备定义的一套“普通话”。只要你的设备按照这套“普通话”来跟主机交流，主机就知道你是一个摄像头，该用什么驱动、该怎么读取视频流，全都自动搞定。

UVC 协议的核心在于描述符。USB 设备在枚举过程中，会向主机报告自己是什么设备、有哪些功能、支持哪些格式。对于摄像头来说，需要报告的关键信息包括：支持的分辨率、支持的像素格式（比如 MJPEG、YUY2）、帧率范围、以及视频流的传输方式（通常是等时传输或批量传输）。主机拿到这些描述符之后，就会加载对应的 UVC 驱动，然后按照协商好的参数来接收视频数据。

这里有一个容易混淆的点：UVC 设备并不是只能做摄像头。任何符合 UVC 协议的视频输入设备都可以，比如采集卡、视频采集棒等。反过来说，只要你的设备能正确响应 UVC 协议的主机请求，并且按照约定的格式推送视频数据，主机就会把它当成摄像头来用。

1.3 TinyUSB 在其中的角色

TinyUSB 是一个开源的跨平台 USB 协议栈，专为嵌入式系统设计。它的特点是代码量小、可裁剪、支持多种 USB 设备类，其中就包括 UVC。在 ESP32-S3 上，TinyUSB 作为 USB Device 协议栈运行，负责处理所有的 USB 底层通信，包括枚举、描述符响应、端点数据传输等。

如果没有 TinyUSB，我们就需要自己实现 USB 协议栈，处理各种标准请求和类请求，工作量巨大且容易出错。TinyUSB 把这些脏活累活都封装好了，我们只需要按照它的 API 来配置描述符、注册回调函数、推送视频帧数据就行。这就像盖房子，TinyUSB 已经把地基和框架搭好了，我们只需要负责装修和布置家具。

不过要注意的是，TinyUSB 的 UVC 支持并不是开箱即用的。它提供的是底层框架和示例代码，具体的描述符配置、视频格式协商、帧数据传输逻辑，还是需要我们自己来实现。这也是这个项目最有挑战性的部分。

1.4 整体方案架构

整个方案的架构可以分成三层来理解。最底层是硬件层，包括 ESP32-S3 芯片、OV2640 摄像头模组、以及它们之间的连接线路。中间层是驱动层，包括 OV2640 的 SCCB 初始化、DVP 接口配置、以及图像数据采集。最上层是 USB 协议层，包括 TinyUSB 的初始化、UVC 描述符配置、视频帧的封装和推送。

数据流向是这样的：OV2640 采集图像数据，通过 DVP 并行接口传给 ESP32-S3，ESP32-S3 把图像数据缓存在内存中，然后通过 TinyUSB 的 UVC 接口，按照 UVC 协议要求的格式，通过 USB 端点发送给 Windows 主机。Windows 主机收到数据后，UVC 驱动自动解析并交给上层应用（比如相机应用、视频会议软件）显示。

这个架构的关键在于数据缓冲和流控。OV2640 输出的图像数据速率可能很高，而 USB 的传输速率是有限的，如果缓冲策略不当，就会出现丢帧、花屏、甚至枚举失败的问题。后面我会详细讲这块的处理方法。

2. 硬件选型与连接细节

2.1 ESP32-S3 开发板的选择要点

市面上的 ESP32-S3 开发板种类很多，但并不是所有板子都适合做这个项目。选择的时候需要重点关注几个参数。

首先是PSRAM。OV2640 输出的图像数据，即使是 JPEG 格式，一帧也可能有几十 KB。如果要做双缓冲或者多缓冲，内存需求会更大。ESP32-S3 内置的 SRAM 只有 512KB 左右，跑完协议栈和应用程序之后，剩余空间可能不够用。所以强烈建议选择带8MB PSRAM的版本，这样才有足够的空间来缓存图像数据。

其次是USB 接口。ESP32-S3 有两个 USB 控制器，一个是 USB-Serial-JTAG，用于烧录和调试；另一个是 USB OTG，用于设备模式。做 UVC 摄像头需要用 USB OTG 接口，所以板子上必须引出这个接口。有些开发板只引出了 USB-Serial-JTAG，那就做不了这个项目。

第三是摄像头接口。ESP32-S3 支持 DVP 摄像头接口，但不同开发板的引脚定义可能不一样。最好选择官方或者社区支持比较好的板子，比如 ESP32-S3-EYE、ESP32-S3-Korvo 等，这些板子的摄像头接口定义比较明确，资料也齐全。

我手头用的是 ESP32-S3-DevKitC-1 搭配外接的 OV2640 模组，引脚连接需要自己飞线。如果你不想飞线，可以直接买带摄像头接口的开发板，省事很多。

2.2 OV2640 模组的关键参数

OV2640 是一颗 200 万像素的 CMOS 图像传感器，最大分辨率是 1600x1200。它支持多种输出格式，包括 YUV、RGB、JPEG 等。对于 UVC 摄像头来说，最实用的格式是JPEG，因为 JPEG 压缩后的数据量小，USB 传输压力小，而且 UVC 协议原生支持 MJPEG 格式。

OV2640 的接口是 DVP（Digital Video Port），包括数据线、行同步、场同步、像素时钟等信号。它还有一个 SCCB 接口，用于配置寄存器。SCCB 协议跟 I2C 很像，但有一些细微差别，不过 ESP32-S3 的 I2C 外设可以直接驱动 OV2640 的 SCCB 接口，问题不大。

选 OV2640 而不是 OV5640 的原因很简单：OV2640 的驱动在 ESP-IDF 里面已经有现成的支持，而且 JPEG 输出格式直接可用。OV5640 虽然像素更高，但驱动更复杂，而且 JPEG 输出的配置也更麻烦。对于免驱摄像头这个场景，OV2640 的 200 万像素已经足够用了。

2.3 引脚连接与注意事项

ESP32-S3 和 OV2640 之间的连接，主要分三组：电源、SCCB、DVP。

电源方面，OV2640 需要 3.3V 供电，注意电流要足够，最好单独走线，不要跟其他大电流设备共用。SCCB 就是 I2C，需要接 SCL 和 SDA 两根线，再加上上拉电阻。DVP 接口包括 8 根数据线（D0-D7）、像素时钟（PCLK）、行同步（HREF）、场同步（VSYNC）。另外 OV2640 还有一个复位引脚和电源使能引脚，通常接 GPIO 控制。

这里有一个坑：ESP32-S3 的 GPIO 矩阵非常灵活，但并不是所有 GPIO 都适合做高速信号。DVP 的像素时钟频率可能到 20MHz 以上，如果引脚选择不当，会出现图像抖动或者数据错误。建议参考 ESP-IDF 的摄像头示例，选择官方推荐的引脚组合。

还有一个容易忽略的点：OV2640 的 XCLK。OV2640 需要外部提供时钟信号，通常是 20MHz 或 24MHz。ESP32-S3 可以通过 LEDC 或者 I2S 的 MCLK 输出这个时钟。如果 XCLK 不稳定，摄像头可能根本无法初始化。

2.4 硬件连接检查清单

在开始写代码之前，建议先用万用表把连接检查一遍。我整理了一个检查清单，可以对照着来：

这个清单看起来简单，但实际调试的时候，很多问题都是因为硬件连接不当造成的。比如 SCCB 读不到 ID，可能是上拉电阻没接，也可能是地址搞错了。OV2640 的 SCCB 地址通常是 0x30（写）和 0x31（读），但有些模组可能不一样，需要看具体的数据手册。

3. 软件开发环境搭建

3.1 ESP-IDF 的安装与配置

ESP-IDF 是乐鑫官方的开发框架，支持 ESP32-S3 的所有功能。安装方式有几种，我推荐用VSCode 插件的方式，因为图形化界面比较友好，而且集成了串口监视器、烧录按钮等功能。

安装步骤大致是这样的：先装 VSCode，然后在扩展商店里搜索 ESP-IDF，安装官方插件。插件会引导你下载 ESP-IDF 的各个组件，包括工具链、Python 环境、OpenOCD 等。整个过程可能需要下载几个 GB 的文件，建议在网络状况好的时候进行。

安装完成之后，需要配置目标芯片为 ESP32-S3。在 VSCode 的命令面板里找到 “ESP-IDF: Set Espressif Device Target”，选择 esp32s3。然后设置串口端口，通常 Windows 上会显示为 COMx。

这里有一个常见问题：Windows 11 下 CH340 驱动可能不兼容。如果你的开发板用的是 CH340 串口芯片，可能会遇到设备管理器里显示黄色感叹号的情况。解决办法是去官网下载最新的 CH340 驱动，或者换用 CP2102 芯片的开发板。这个问题在 Windows 11 上比较常见，Windows 10 一般没这个问题。

3.2 TinyUSB 组件的引入

ESP-IDF 里面已经包含了 TinyUSB 组件，但默认可能没有启用。需要在项目的idf_component.yml或者CMakeLists.txt里面声明依赖。具体来说，在main目录下的CMakeLists.txt里面添加REQUIRES tinyusb就可以了。

不过要注意，ESP-IDF 不同版本对 TinyUSB 的支持程度不一样。建议使用ESP-IDF v5.0 或更高版本，因为这些版本对 USB OTG 和 TinyUSB 的支持比较完善。如果用的是 v4.x 版本，可能会遇到各种奇怪的编译错误或者运行时问题。

引入 TinyUSB 之后，还需要配置一些编译选项。比如在menuconfig里面，找到Component config -> TinyUSB，确保Enable TinyUSB被选中。另外还要配置 USB 的任务栈大小、端点缓冲区大小等参数，这些参数会直接影响视频流的稳定性。

3.3 项目目录结构规划

一个清晰的项目结构可以让后续开发省心很多。我建议这样组织：

project/ ├── main/ │ ├── main.c # 主程序入口 │ ├── camera.c # OV2640 驱动和初始化 │ ├── camera.h │ ├── uvc_device.c # UVC 描述符和回调 │ ├── uvc_device.h │ └── CMakeLists.txt ├── components/ │ └── (可选的自定义组件) ├── CMakeLists.txt └── sdkconfig

把摄像头驱动和 UVC 设备逻辑分开，好处是调试的时候可以单独测试某一部分。比如先确认摄像头能正常出图，再调试 UVC 枚举，这样问题定位会快很多。

3.4 编译与烧录的注意事项

编译的时候，如果遇到undefined reference to tud_...之类的错误，通常是因为 TinyUSB 的源文件没有被正确编译进去。检查CMakeLists.txt里面的REQUIRES是否包含了tinyusb，以及menuconfig里面是否启用了对应的功能。

烧录的时候，ESP32-S3 需要进入下载模式。有些开发板会自动进入，有些需要手动按住 BOOT 键再按 RESET 键。如果烧录失败，先检查串口端口是否被其他程序占用，再检查开发板是否进入了下载模式。

还有一个细节：USB OTG 接口和 USB-Serial-JTAG 接口可能是同一个物理接口。有些开发板通过跳线或者电阻来选择。如果烧录之后 USB 设备没有枚举，可能是接口模式不对，需要检查硬件配置。

4. UVC 描述符配置与核心实现

4.1 UVC 描述符的结构解析

UVC 描述符是整个项目的核心，它决定了主机如何识别和配置你的设备。一个完整的 UVC 描述符包括以下几个部分：

设备描述符：报告设备的 VID、PID、设备类等信息。对于 UVC 设备，设备类通常是 0xEF（Miscellaneous），子类是 0x02（Common Class），协议是 0x01（Interface Association）。

配置描述符：报告配置的总长度、接口数量、供电方式等。

接口关联描述符（IAD）：UVC 设备通常有两个接口，一个是视频控制接口（VC），一个是视频流接口（VS）。IAD 用来告诉主机这两个接口是关联的。

视频控制接口描述符：包括接口头描述符、输入终端描述符、输出终端描述符、相机终端描述符、处理单元描述符、扩展单元描述符等。这些描述符定义了设备的拓扑结构和支持的控制功能。

视频流接口描述符：包括接口描述符、输入端点描述符、以及一系列格式描述符。格式描述符里面又包含帧描述符，定义了支持的分辨率和帧率。

这一堆描述符看起来复杂，但其实是有规律可循的。TinyUSB 提供了一些宏和模板，可以简化描述符的编写。不过要完全理解每个字段的含义，还是需要对照 UVC 协议规范来看。

4.2 描述符配置的实操步骤

在 TinyUSB 里面，UVC 描述符通常定义在一个数组里面，然后在tud_descriptor_configuration_cb回调里面返回。具体来说，需要定义一个uint8_t const desc_configuration[]数组，里面按顺序排列各个描述符。

配置的时候，有几个关键参数需要根据实际情况调整：

视频格式：我选择的是 MJPEG，因为 OV2640 直接支持 JPEG 输出。在格式描述符里面，需要指定bFormatIndex、bNumFrameDescriptors、guidFormat等字段。MJPEG 的 GUID 是固定的，可以在 UVC 规范里面查到。

分辨率：OV2640 支持多种分辨率，我选择了 640x480 和 320x240 两种。每种分辨率对应一个帧描述符，里面需要指定wWidth、wHeight、dwDefaultFrameInterval、dwFrameInterval等字段。

端点：视频流数据通过等时端点或者批量端点传输。等时端点保证带宽但可能丢包，批量端点保证可靠但可能延迟。对于摄像头应用，通常用等时端点。端点描述符里面需要指定wMaxPacketSize、bInterval等参数。

这里有一个容易出错的地方：描述符的总长度必须正确。如果wTotalLength字段跟实际描述符数组的长度不一致，主机会枚举失败。建议用sizeof(desc_configuration)来动态计算，而不是手写一个固定值。

4.3 视频帧的封装与推送

UVC 协议规定，视频帧数据需要按照一定的格式封装后再通过 USB 端点发送。每一帧数据前面要加一个UVC 头，里面包含帧索引、时间戳、以及数据长度等信息。

TinyUSB 提供了tud_video_n_frame_xfer函数来简化这个过程。你只需要把图像数据准备好，然后调用这个函数，TinyUSB 会自动帮你加上 UVC 头并发送。不过要注意，这个函数是异步的，发送完成之后会触发回调，你需要在回调里面准备下一帧数据。

帧数据的来源是 OV2640。ESP-IDF 的摄像头驱动提供了esp_camera_fb_get函数来获取一帧图像。拿到camera_fb_t结构体之后，里面的buf指针就是 JPEG 数据，len是数据长度。把这个数据传给tud_video_n_frame_xfer就行了。

这里有一个性能优化的点：双缓冲或者多缓冲。如果只用单缓冲，那么必须等上一帧发送完成之后才能采集下一帧，帧率会受限。用双缓冲的话，可以在发送第一帧的同时采集第二帧，帧率可以明显提升。不过双缓冲需要更多的内存，所以要权衡一下。

4.4 帧率与带宽的平衡

USB 的带宽是有限的。全速 USB（USB 1.1）的理论带宽是 12Mbps，高速 USB（USB 2.0）是 480Mbps。ESP32-S3 的 USB OTG 支持全速和高速两种模式，但实际能跑多快，取决于硬件设计和软件配置。

对于 MJPEG 格式，640x480 分辨率下，一帧 JPEG 数据可能在 20KB 到 50KB 之间。如果帧率是 15fps，那么每秒的数据量大约是 300KB 到 750KB，换算成比特率就是 2.4Mbps 到 6Mbps。这个带宽在全速 USB 下是可以接受的，但如果是高速 USB，可以支持更高的帧率或者分辨率。

实际调试的时候，我发现帧率并不是越高越好。帧率太高，USB 带宽可能不够，导致丢帧或者花屏。而且 ESP32-S3 的处理能力也有限，如果同时跑 Wi-Fi 或者其他任务，帧率会进一步下降。所以建议先从 15fps 开始调，稳定之后再尝试提高。

5. 常见问题与排查技巧实录

5.1 设备枚举失败怎么办

设备枚举失败是最常见的问题，表现是插上 USB 之后，Windows 没有任何反应，或者设备管理器里面出现未知设备。

排查思路是这样的：首先确认硬件连接，特别是 USB 的 D+ 和 D- 线有没有接反。然后检查描述符配置，特别是wTotalLength和各个描述符的长度字段。如果描述符长度不对，主机会在枚举过程中直接放弃。

还有一个可能的原因是VID/PID 冲突。如果 VID/PID 跟系统里面已有的设备冲突，Windows 可能会加载错误的驱动。建议使用一个不常见的 VID/PID 组合，或者直接用乐鑫的 VID/PID。

如果枚举成功但设备管理器里面显示黄色感叹号，可能是描述符的某些字段不符合 UVC 规范。这时候可以用USB 抓包工具来分析枚举过程，看看主机在哪一步拒绝了设备。Windows 上可以用 Wireshark 配合 USBPcap 来抓包，Linux 上直接用lsusb -v就能看到详细的描述符信息。

5.2 图像花屏或卡顿的排查

图像花屏通常跟数据传输有关。可能的原因包括：USB 带宽不足、缓冲区溢出、DVP 时序不对、JPEG 数据损坏等。

先检查 USB 带宽。如果用的是等时端点，带宽是预留的，一般不会不够。但如果用的是批量端点，可能会因为主机调度问题导致数据积压。可以尝试降低分辨率或者帧率，看看问题是否改善。

再检查缓冲区。如果esp_camera_fb_get返回的帧数据长度超过了预期，可能是 OV2640 的 JPEG 质量设置太高，导致单帧数据过大。可以调整 JPEG 质量参数，降低数据量。

DVP 时序问题比较隐蔽，通常表现为图像有规律地错位或者颜色异常。这时候需要用示波器检查 PCLK、VSYNC、HREF 的时序关系，确认是否符合 OV2640 的数据手册要求。

5.3 Windows 识别但无法预览的解决

有时候设备管理器里面能看到摄像头，但打开相机应用却提示“无法预览”或者黑屏。这种情况通常是 UVC 描述符里面的格式协商有问题。

Windows 的 UVC 驱动对描述符的要求比较严格。如果格式描述符里面的bNumFrameDescriptors跟实际帧描述符的数量不一致，或者dwFrameInterval数组的格式不对，Windows 可能会拒绝使用这个格式。

解决办法是参考 Windows 自带的 UVC 摄像头描述符，对比一下字段的取值。另外，可以尝试只保留一种格式和一种分辨率，减少描述符的复杂度，先确保能预览，再逐步添加其他格式。

还有一个可能的原因是电源管理。Windows 可能会对 USB 设备进行选择性挂起，如果设备不支持远程唤醒，可能会被挂起导致无法预览。可以在设备管理器里面找到 USB 根集线器，在电源管理选项卡里面取消“允许计算机关闭此设备以节约电源”。

5.4 常见问题速查表

5.5 独家避坑经验分享

第一个坑是XCLK 频率。OV2640 默认需要 20MHz 或者 24MHz 的 XCLK，如果频率不对，摄像头可能初始化失败，或者输出图像异常。我一开始用 LEDC 输出 10MHz，结果摄像头完全没反应。后来改成 20MHz 才正常。

第二个坑是JPEG 缓冲区大小。ESP-IDF 的摄像头驱动默认的 JPEG 缓冲区可能不够大，导致高分辨率下图像被截断。需要在camera_config_t里面把fb_size设置得足够大，比如 640x480 分辨率下，建议设置 64KB 以上。

第三个坑是USB 任务优先级。TinyUSB 的任务优先级如果设置得太低，可能会被其他任务抢占，导致 USB 传输不稳定。建议把 USB 任务的优先级设置得高一些，比如 5 或者更高。

第四个坑是Windows 的 UVC 驱动缓存。有时候修改了描述符之后，Windows 还是用旧的驱动配置。这时候需要在设备管理器里面卸载设备，并且勾选“删除此设备的驱动程序软件”，然后重新插拔 USB，让 Windows 重新枚举。

6. 性能优化与扩展思路

6.1 提升帧率的几个方向

帧率上不去，通常是多个因素共同作用的结果。可以从以下几个方向来优化。

降低分辨率：这是最直接的方法。320x240 分辨率下，单帧数据量小，USB 传输压力小，帧率自然就上去了。如果应用场景对分辨率要求不高，这是一个很好的折中方案。

调整 JPEG 质量：OV2640 的 JPEG 质量参数可以调整，质量越低，压缩率越高，数据量越小。但质量太低会导致图像模糊，需要根据实际需求来平衡。

优化缓冲策略：从单缓冲改成双缓冲，可以让采集和发送并行进行，帧率可以提升接近一倍。如果内存足够，甚至可以尝试三缓冲。

提高 CPU 频率：ESP32-S3 的 CPU 频率可以跑到 240MHz，如果默认频率较低，可以尝试提高。不过要注意功耗和发热问题。

减少其他任务干扰：如果同时跑了 Wi-Fi 或者蓝牙，会占用 CPU 和内存资源，影响 USB 传输。可以尝试关闭不必要的任务，或者调整任务优先级。

6.2 从 UVC 摄像头到网络摄像头的扩展

ESP32-S3 本身支持 Wi-Fi，所以这个项目可以很容易地扩展成网络摄像头。思路是这样的：在 UVC 摄像头的基础上，增加一个 HTTP 服务器或者 RTSP 服务器，把图像数据同时推送到网络和 USB。

具体实现上，可以用 ESP-IDF 的esp_http_server组件来搭建一个简单的 HTTP 服务器，提供一个 MJPEG 流接口。浏览器访问这个接口就能看到实时画面。这样一块板子就同时具备了 USB 摄像头和网络摄像头的功能。

不过要注意，同时跑 USB 和 Wi-Fi 对资源的消耗比较大，可能需要降低分辨率或者帧率来保证稳定性。另外，Wi-Fi 的功耗也比较高，如果是电池供电的场景，需要权衡一下。

6.3 图像处理功能的加入

ESP32-S3 有一定的算力，可以跑一些轻量级的图像处理算法。比如可以做运动检测、人脸检测、颜色识别等。这些功能可以在图像数据发送到 USB 之前进行处理，把处理结果叠加到图像上，或者单独通过其他接口输出。

不过图像处理会占用 CPU 时间，可能会影响帧率。建议把图像处理放在单独的任务里面，并且根据实际需求来决定是否启用。如果只是做简单的运动检测，可以用帧差法，计算量很小。如果要做人脸检测，可能需要用专门的神经网络加速库，对内存和算力的要求会更高。

6.4 多摄像头方案的可能性

ESP32-S3 的 DVP 接口只有一组，所以原生不支持同时接两个摄像头。但可以通过一些技巧来实现多摄像头方案。比如用模拟开关来切换 DVP 信号，分时复用同一个接口。或者用多个 ESP32-S3 模块，每个模块负责一个摄像头，然后通过串口或者 SPI 来同步数据。

多摄像头方案在立体视觉、全景拍摄等场景下有用。不过实现复杂度比较高，而且数据同步是个难题。如果只是做简单的双摄像头切换，用模拟开关的方案就够用了。

6.5 实际项目中的经验总结

我在实际项目中最大的体会是：稳定性比性能更重要。一开始我追求高帧率、高分辨率，结果各种问题层出不穷。后来把帧率降到 15fps，分辨率降到 640x480，反而稳定了很多。对于大多数应用场景来说，这个配置已经足够用了。

另外，调试工具很重要。USB 抓包工具、示波器、逻辑分析仪，这些工具在排查问题的时候能省很多时间。特别是 USB 抓包，能看到主机和设备之间的完整通信过程，对于理解 UVC 协议和排查枚举问题非常有帮助。

最后，多看官方示例和文档。ESP-IDF 和 TinyUSB 都有丰富的示例代码，很多问题在示例里面已经有解决方案了。遇到问题的时候，先去翻翻示例和文档，往往能找到答案。