板级开发提要
这页用于收纳原先偏项目环境和板卡实践的内容，尤其是 ESP32应用笔记 和 泰山派RK3566开发板笔记 里仍然值得回看的部分。
ESP32-S3
优先依赖官方资料
- ESP32 开发的第一参考源应当是官方
ESP-IDF文档，而不是零散博客。 - 串口监视、崩溃栈解析、构建环境导出这些动作，尽量沿着
idf.py工具链走。
几个高频经验
- 中断里不要做耗时操作，尤其不要直接做 Flash 写入这类动作。
- 任务别开太多，很多
while(1)轮询型任务更适合改成定时器、事件循环或通知机制。 - FreeRTOS 队列元素不要做得太大，否则 SRAM 消耗会很快失控。
- 如果项目依赖 PSRAM，要明确哪些内存分配仍然落在内部 SRAM，不能只看表面容量。
调试与定位
idf.py monitor适合现场查看串口日志和 Panic 信息。xtensa-esp32s3-elf-objdump -S适合反汇编排查。xtensa-esp32s3-elf-addr2line适合把崩溃地址映射回源码位置。
Linux / WSL2 开发环境
- 直接在 Windows 下编译如果明显吃不满 CPU，可以优先转到 WSL2。
- 串口和 USB 调试设备可以通过
usbipd转发到 WSL。 - WSL 方案的关键点不是“能不能转发”，而是串口设备是否稳定、用户权限是否已经加入
dialout。
RK3566 / Buildroot / Qt
环境搭建的关键判断
- 如果官方 SDK 明确绑定了特定 Ubuntu 版本，优先先满足它，再谈优化体验。
- 相比双虚拟机和共享文件系统，直接用 Docker 跑指定版本构建环境通常更稳。
- 一旦出现
Clock skew detected这类时间戳问题，先怀疑挂载方式和宿主/容器时间同步，不要先怀疑编译系统本身。
Buildroot 方向
- 先搞清默认
defconfig和板级配置入口，再去加包。 - 自定义包、补丁和
Config.in变更，优先按 Buildroot 现有包的组织方式来仿写。 - 生成 patch 时路径前缀要干净，避免
./这种会干扰-p剥离层级的写法。
板卡开发真正要沉淀的内容
- 交叉编译环境怎么稳定复现。
- 板级配置、包配置、补丁链路分别落在哪。
- 出问题时先看构建系统、设备树、驱动还是显示栈。
这类笔记的整理原则
- 项目路径、私有镜像地址、一次性环境命令，不值得继续扩写成长文。
- 值得留下的是：环境选择依据、构建入口、资源限制、常见故障和排查方向。