Files
ESP32S3_vt/HARDWARE.md
T
sloray cc6b82d7ec
构建客户端 / 检查(类型 + 单元测试) (push) Canceled after 0s
构建客户端 / Linux x64(deb + AppImage) (push) Canceled after 0s
构建客户端 / Windows x64(NSIS 安装包) (push) Canceled after 0s
构建客户端 / macOS 通用(.app + .dmg) (push) Canceled after 0s
feat: 链路控制、延迟校准与长测工具,补全文档
- 固件:新增 link_control / stream_control,覆盖运行中 Wi-Fi 断线恢复、取帧节拍、
  温控与质量/帧率减载;UDP 发送增加有界重试预算与帧期限,PSRAM JPEG 直发减少拷贝。
- 协议:重组器严格校验分片布局,统计未收齐、超时与完全缺失的帧,处理帧号回绕与设备重启。
- 桌面端:视频改 latest-value 通道并前置帧时间标记,拒绝积压和慢解码的过期画面;新增
  延迟标记页与 --latency-report 校准,完善录制、服务端与退出流程。
- 文档与脚本:新增硬件、开发、延迟、功耗、实时性、稳定性文档和改动记录,重写根 README;
  新增构建、性能、延迟与串口长测脚本,以及长测客户端脚本。
- 构建:固定 esp-1.97.0.0 工具链,分区表随构建复制,更新 sdkconfig 与忽略规则。
2026-10-19 00:19:07 +08:00

4.6 KiB
Raw Permalink Blame History

图传板硬件说明

对应 Freenove ESP32-S3-WROOM CAM、ESP32-S3-WROOM-1-N16R8 与 OV5640。构建和烧录入口见 README.md。

摄像头引脚

配置以 src/camera.rs 的 pins 模块为准。DATA 按 D0–D7(传感器 Y2–Y9)排列。

信号 GPIO
RESET 0
XCLK 15
PCLK 13
VSYNC 6
HREF 7
SIOD / SDA 4
SIOC / SCL 5
D0–D7 11, 9, 8, 10, 12, 18, 17, 16
PWDN 未连接(-1)

当前 XCLK 为 20 MHz。不要直接套用 AI-Thinker、XIAO 等其他板卡的相机引脚表。

本模组需避开的资源包括 Flash / PSRAM 总线(GPIO 26–37)、USB(19 / 20)、串口(43 / 44)及模组内部引脚,以原理图为最终依据。占用 Flash / PSRAM 引脚可能造成传输期间 CPU 挂死、串口静默。

内存与任务配置

参数位于根目录 sdkconfig.defaults:

参数 当前值 用途
CONFIG_SPIRAM_MODE_OCT y 8 MB Octal PSRAM
CONFIG_SPIRAM_SPEED_80M y PSRAM 时钟
CONFIG_CAMERA_PSRAM_DMA n DMA 经内部 RAM 中转后复制到 PSRAM
CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP n Wi-Fi / lwIP 缓冲保留在内部 RAM
CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_240 y CPU 240 MHz
CONFIG_CAMERA_CORE1 y 显式选择 CPU1,与 Wi-Fi 分开(只禁用 CORE0 不足以改变 choice 默认值)
CONFIG_FREERTOS_HZ 1000 发送拥塞时以 1 ms tick 让出调度
CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM 64 发送缓冲数量,使用内部 RAM
CONFIG_ESP_WIFI_TX_BA_WIN 32 保留 AMPDU 发送聚合

相机使用 3 个 PSRAM 帧缓冲及 GRAB_LATEST,优先取得较新的画面。JPEG 编码由传感器完成,S3 主要负责采集和发送。

原测试板启用 PSRAM DMA 后曾出现 NO-EOI:JPEG 结束标记位于驱动末尾 DMA 搜索窗口之外,随后停止交付帧。因此默认关闭该配置;更换驱动后应单独验证持续采集。

Flash 与分区

默认 16 MB、DIO、40 MHz,分区来自 partitions.csv:

分区 偏移 大小
NVS 0x9000 0x6000
PHY init 0xF000 0x1000
Factory app 以 partitions.csv 为准,坏板重编时可能调整 0x120000(1152 KiB)

分区表位于 0x8000,S3 Bootloader 从 0x0 开始。App 写入分区表声明的偏移,不能直接套用 0x10000。修改分区或 Flash 模式后需重新构建,成套更新 Bootloader、分区表和 App。

健康硬件可以评估恢复 0x10000 App 偏移或更快 Flash 配置,但需重新验证。

损坏 Flash 模组的兼容处理

早期测试模组在绝对地址 0xFADE7 存在写入异常,bit 5–7 无法正确写入。这是特定模组的故障。当前 App 偏移来自该板的开发过程,不能保证新镜像仍避开坏字节。

2026-10-18 的整段回读还发现 0x10863 的 bit 6 异常读回为 1:期望 0x2e,读回 0x6e,该轮 App 只有这一处字节不同,尚未单独擦写复核是否为永久故障。该模组的 App 偏移需至少为 0x20000,并继续检查 0xFADE7;烧录工具的校验失败必须先排除,不能当作网络或相机故障。

scripts/flash.sh 保留的流程为:编译、导出 App、搜索 64 KiB 对齐的可写偏移、修改分区、重新构建和验证,再写入三段镜像。重新构建可能移动镜像内容,因此第二次验证不可省略。

脚本依赖 macOS 串口名、Unix termios、本地 ESP-IDF Python 目录及旧版工具参数,不适合作为通用烧录入口。坏板需核对工具版本及坏地址字节;普通板卡使用 README 流程。更换故障模组比长期依赖镜像位置更可靠。

本地相机组件

components/esp32-camera/ 包含上游 2.1.7 及本地兼容补丁,components/cam_wrapper/ 提供 Rust FFI 封装。

本地增加 esp_camera_fb_get_latest / cam_take_latest:等待第一张有效帧后,以有限次数零等待取出更新帧,并归还替换的缓冲。cam_take(0) 表示单次非阻塞尝试,不在空队列、坏 JPEG 或 DMA 复位哨兵上继续等待。升级驱动时需保留或移植这些补丁,并运行缓冲所有权测试;不能用“先检查有帧、再调用可能阻塞 4 秒的 get”替代。

S3 的 ll_cam.c 中有 CAM_IO_MUX_REG() 本地补丁,用于 SCCB / I2C 引脚连接。升级驱动后需检查补丁并验证传感器探测和采集。

components/esp32-camera/target/ 是按芯片划分的源代码,清理缓存时不能删除,也不能忽略所有层级的 target/。