学习笔记 · Obsidian
从 C 到 CoreS3 的学习路线
这次学习的起点
已确认：有软件开发经验，C 和嵌入式从基础学习。按所提供路线，以 CoreS3 为目标板；具体硬件型号、系统环境和烧录状态留待实机确认。
第一轮采用“C 练习约 60%，ESP-IDF 与板卡实验约 40%”作为可调整的学习配比。每次先读一个概念，做一个实验，再用自己的话解释结果，不用等学完 C 才接触板卡。
第一项综合作品是 CoreS3 设备状态面板：读取板载传感器、显示数值、联网向自己的 Java 服务上报，并明确显示断线或读取失败。第一轮只做显示和观测，不接入真实机器的运动控制。
知识怎样连起来
flowchart LR
A[类型、指针、struct] --> B[缓冲区与驱动 API]
B --> C[GPIO / I2C / SPI]
C --> D[BSP 与屏幕、传感器]
B --> E[Task 与 Queue]
D --> E
E --> F[Wi-Fi 与 HTTPS]
F --> G[MQTT 与设备状态]
G --> H[Java 服务与故障恢复]这里的箭头表示学习依赖。MQTT 不是 Wi-Fi 的前置技术；BLE 也是可以独立开展的分支。
六个阶段及完成证据
| 阶段 | 学什么 | 做出什么 | 过关依据 |
|---|---|---|---|
| 1 | 类型、函数、数组、指针、位运算 | 本机模拟设备采样 | 能解释每个指针指向哪里；空输入、边界值按预期处理 |
| 2 | 编译、链接、烧录、日志、最少的任务知识 | ESP-IDF Hello World 与周期日志 | 构建版本、目标芯片、串口日志可对应；重启后仍可复现 |
| 3 | BSP、LCD、触摸、I2C | 本地设备状态面板 | 触摸有效；读取错误能显示；明确总线和驱动的所有者 |
| 4 | Task、Queue、Mutex、定时 | 采样与显示解耦 | 模拟处理变慢时队列行为可解释；网络异常不拖死显示 |
| 5 | Wi-Fi、HTTPS、MQTT、NVS | 上报、配置和命令回执 | 断线恢复、重复命令、非法参数有确定结果 |
| 6 | OTA、诊断、设备身份 | 可恢复的设备原型 | 失败版本可回退；权限隔离与故障演练有记录 |
第一目标拆成三个可见结果：先串口输出，再点亮屏幕，最后联网。摄像头、音频和 BLE 在前三个结果稳定之后扩展。
前四次学习建议
| 次序 | 阅读与练习 | 建议投入 | 留下的证据 |
|---|---|---|---|
| 第 1 次 | 第 01 课，运行并解释采样程序 | 45–60 分钟 | 自己修改一个边界值及其输出 |
| 第 2 次 | 第 02 课，画出数组和指针关系 | 45–60 分钟 | 能说明为什么函数还需要长度参数 |
| 第 3 次 | 第 03 课，操作标志位与拆分头文件 | 45–60 分钟 | 置位、清位、测试位的结果 |
| 第 4 次 | 第 05、06 课，核对型号并准备 Hello World | 60–90 分钟 | 板卡型号、版本、编译与串口结果 |
时间只是安排建议，没有替你设置日期、提醒或截止时间。遇到板卡环境问题，可以继续做本机 C 实验。
对原路线的调整
- C++ 按读库需求插入。ESP-IDF 可用 C；M5Unified 等库会需要 C++ 基础。
- FreeRTOS 的
Task、阻塞和延时在第一次 ESP-IDF 实验就接触；复杂同步等后续再展开。 - GPIO、I2C、SPI 先学；I2S 和 DMA 到音视频阶段结合缓冲区学习，避免孤立背概念。
- 第一个联网实验用 HTTPS 请求便于观察请求与响应；再引入 MQTT 的异步消息与状态设计。这是教学安排，不是协议要求。
- NVS 在保存采样周期时就引入，OTA 放在已有稳定版本和恢复路径之后。
怎样算自己学会
读过资料、助手编译过样例、本人能独立修改并解释、实机故障测试通过，是四种不同证据。完成勾选只依据后两种；到 Progress 记录。本文是学习建议，不是已经验收的项目方案。