1. ZHAO-Watch 时光久泽：一款面向工程实践的 STM32 多功能可穿戴终端设计解析

在嵌入式可穿戴设备领域，功能集成度与资源约束始终是一对核心矛盾。市面上大量消费级产品依赖高算力 SoC 与定制化 OS 实现丰富交互，但其开发门槛、功耗与成本往往超出工程师快速原型验证或教学实验的需求。ZHAO-Watch 时光久泽项目提供了一条截然不同的技术路径：它以一颗主流 Cortex-M3 内核的 STM32F103C8T6 微控制器为中枢，在严格受限的 Flash（64KB）与 RAM（20KB）资源下，通过精巧的外设复用、状态机驱动的低功耗调度与硬件协同设计，实现了示波器、环境监测、红外遥控、语音交互、USB 扩展等十余项功能模块的稳定共存。本文不讨论营销话术或外观渲染，而是从一个嵌入式系统工程师的视角，深入拆解其硬件架构选型依据、关键外设配置逻辑、多任务调度机制及实际工程中必须直面的资源瓶颈与折衷方案。所有分析均基于公开的 PCB 布局、原理图片段与固件行为反推，目标是让读者理解“为什么这样设计”，而非仅知“如何照着做”。

1.1 核心控制器选型：STM32F103C8T6 的工程价值再评估

选择 STM32F103C8T6 并非出于性能冗余，而是对其资源边界与生态成熟度的精准卡位。该芯片主频 72MHz，具备 2 个高级定时器（TIM1/TIM8）、3 个通用定时器（TIM2/3/4）、2 个基本定时器（TIM6/7）、3 个 USART、2 个 SPI、2 个 I²C、1 个 ADC（16 通道，12 位）、1 个 DAC（1 通道，12 位）以及丰富的 GPIO。在 ZHAO-Watch 中，这些外设被近乎满负荷地规划：

• TIM1 ：承担示波器采样时序的核心触发源。其重复计数器（RCR）与输入捕获通道（IC1/IC2）被配置为双通道同步采样模式，确保 CH1 与 CH2 在同一时钟沿完成 ADC 转换，消除通道间相位偏移。这是实现 200kHz 等效采样率（即每 5μs 采集一个点）的硬件基础，而非依赖 CPU 软件延时。
• ADC1 ：工作于连续扫描模式，配合 DMA 循环传输。10 个采样点并非指 ADC 仅转换 10 次，而是 DMA 缓冲区长度设为 10，配合 TIM1 的更新事件（UEV）作为 DMA 请求源，形成“定时触发—ADC 启动—DMA 传输—缓冲区填满”的闭环。当缓冲区满后，由 DMA 半传输/全传输中断通知主程序进行波形数据处理与显示刷新。这种设计将数据采集与处理解耦，CPU 仅在中断上下文中做轻量级搬运，避免了传统轮询方式导致的采样间隔抖动。
• USART1 ：被复用为 USB 虚拟串口（VCP）的物理层。此处需特别注意：STM32F103C8T6 本身无原生 USB PHY，项目必然采用了 CH340G 或 CP2102 等 USB-UART 桥接芯片。因此，“USB 响应”功能的本质是：手表 MCU 通过 UART1 与桥接芯片通信，桥接芯片再将数据封装为 CDC ACM 类 USB 设备。这解释了为何连接电脑后出现的是一个串口设备（如 COMx），而非大容量存储设备（MSC）。其标称的“300KB 台幅”实为上位机串口调试工具接收缓冲区大小，并非手表内部存储空间。

该选型的深层工程逻辑在于：F103 系列的 HAL 库与 CubeMX 配置工具链极其成熟，社区支持广泛，且其寄存器级操作文档（RM0008）详尽可靠。对于需要频繁调试外设时序、排查信号完整性问题的硬件原型阶段，这种确定性远比追求更高主频或更多内存更具价值。一个常被忽视的事实是：在 200kHz 采样率下，10 点波形数据仅占用 20 字节（假设 16 位采样），而 F103 的 20KB RAM 完全足以支撑多个此类小缓冲区与任务堆栈。

1.2 人机交互子系统：低功耗唤醒与多模态反馈的协同设计

ZHAO-Watch 的“拿起检测”功能并非简单的加速度计阈值判断，而是一个典型的跨域状态机设计案例。其硬件链路为： MMA8451Q（I²C 接口加速度计）→ STM32 I²C1 → EXTI9_5（用于 I²C 事件中断）→ 主循环状态机 。关键在于功耗优化策略：

• MMA8451Q 被配置为 Motion Detection 模式 ，而非持续读取原始数据。该模式下，传感器内部硬件引擎实时比较 X/Y/Z 轴变化率与预设阈值，仅当检测到有效运动事件时，才拉低 INT1 引脚（连接至 STM32 的 PA5）。此过程传感器自身功耗低于 10μA，远低于持续 I²C 通信的毫安级消耗。
• STM32 的 PA5 引脚配置为外部中断（EXTI_Line5），触发方式为下降沿。中断服务函数（ISR）内仅执行最简操作：设置一个全局标志位 g_wakeup_flag ，并调用 HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI) 进入 STOP 模式。此时，除备份域（RTC、LSE）与 SRAM 外，整个系统时钟停止，功耗降至 2μA 量级。
• “约 4 秒”这一延迟并非由软件计时器实现，而是利用了 RTC 的 Alarm 功能 。在进入 STOP 模式前，RTC 被预先配置为在当前时间基础上增加 4 秒后触发 Alarm 中断。当 Alarm 触发时，系统从 STOP 恢复，首先检查 g_wakeup_flag 是否置位。若置位，则启动 OLED 初始化、背光 PWM（TIM3_CH2）及 UI 渲染；若未置位，则判定为误触发，保持低功耗待机。

这种“硬件传感—极低功耗休眠—RTC 定时唤醒—条件化响应”的流程，是可穿戴设备延长续航的核心范式。它彻底规避了传统方案中 CPU 需周期性唤醒（如每 100ms）查询传感器的“轮询地狱”，将平均功耗降低了近两个数量级。手电筒的“120 度可调”与“上市亮度机”描述，实则指向两个独立硬件模块： 步进电机驱动（ULN2003）用于调节 LED 反射镜角度，PWM 输出（TIM2_CH1）用于线性控制 LED 电流 。所谓“上市亮度机”，极可能是用户对“十级亮度调节”（0–9）的口误，其软件实现仅为一个 4 位变量 led_brightness_level ，经查表映射为 TIM2 的自动重装载值（ARR）。

1.3 环境感知与执行机构：温湿度传感器与红外发射的软硬协同

手表搭载的温湿度传感器，根据常见物料与引脚定义，高度可能为 SHT30 或 DHT22 。SHT30 采用 I²C 接口，精度高（±0.2℃，±2%RH），但需精确的时序控制；DHT22 为单总线协议，成本更低，但抗干扰性稍弱。无论哪种，其驱动难点均在于时序容错。以 DHT22 为例，其启动信号要求主机拉低总线至少 800μs，随后释放并等待传感器响应。在 STM32 上，若使用标准 GPIO 模式，该时序易受中断延迟影响。ZHAO-Watch 的稳健实现方案是： 将 DHT22 数据线连接至 TIM3 的输入捕获通道（IC1），并配置为开漏输出模式 。初始化时，TIM3 输出一个精确的 800μs 低电平脉冲；随后切换为输入捕获模式，利用硬件计数器直接测量传感器返回的 80μs 高电平响应脉宽。此方法将关键时序完全交由硬件定时器保障，软件只需在捕获中断中读取 CCR1 寄存器值，极大提升了通信可靠性。

红外遥控模块的“315MHz”描述存在明显技术谬误。315MHz 是常见的 RF（射频）遥控频段 ，用于远距离开关灯、窗帘等；而红外（IR）遥控的标准载波频率为 38kHz。结合“控制房间的灯”及“15 个通道”的描述，此处必为 PT2262/PT2272 编解码的 315MHz ASK 射频模块 。其硬件接口极为简洁：仅需一个 GPIO（如 PB0）连接至 RF 发射模块的数据输入端。软件层面，PT2262 的编码遵循固定格式：地址码（8 位）+ 数据码（4 位）+ 同步头。ZHAO-Watch 的“15 个通道”即对应数据码的 4 位所能表示的 16 种状态（0x0–0xF），其中 15 个被分配给不同灯具。关键在于发射时序的精度——同步头（>10ms 低电平）、地址位（0.26ms 低 + 0.26ms 高为“0”，0.26ms 低 + 0.52ms 高为“1”）必须由硬件定时器（如 TIM4）产生。若用软件延时，主频 72MHz 下的指令周期误差足以导致编码失败。因此，其固件中必然存在一个基于 TIM4 的 PWM 输出配置，通过动态修改 CCR 值来生成符合 PT2262 时序规范的方波序列。

1.4 语音交互系统的架构本质：边缘计算与云端协同的边界

字幕中提及的“VATS 语音合成模型”及“台式机训练”揭示了该项目语音功能的真实架构： 纯本地化语音识别（ASR）并未实现，所有语音指令的解析均发生在云端或上位机 。理由如下：
- STM32F103C8T6 的 64KB Flash 无法容纳任何现代深度学习语音模型（即使量化后的 Whisper Tiny 也需数 MB）。
- “拍子。开灯。”等指令的语义解析涉及复杂的自然语言理解（NLU），远超 MCU 的实时处理能力。
- “VATS”实为 Voice Audio Text Synthesis 的缩写，即语音合成（TTS），而非语音识别（ASR）。其作用是在收到云端解析后的指令（如“打开卧室灯”）后，由手表播放预录制的语音回复（如“已打开卧室灯”）。这些回复语音文件（WAV/MP3）被存储在外部 SPI Flash（如 W25Q32）中，播放时由 DAC1 输出模拟音频信号，经 LM386 放大后驱动蜂鸣器。

因此，完整的语音交互链路为：
1. 用户语音 → 麦克风（PDM 或模拟）→ ADC 采样 → 通过 USB 串口上传至上位机；
2. 上位机运行 Python 脚本（调用 Vosk 或 Picovoice 等轻量 ASR 引擎）进行实时识别；
3. 识别结果（JSON 格式，含文本与置信度）通过同一串口下发至手表；
4. 手表 MCU 解析 JSON，匹配预设指令集（如“开灯”→ 通道 1，“关灯”→ 通道 2），触发对应的 315MHz 射频发射；
5. 同时，根据指令类型，从 SPI Flash 加载对应 TTS 音频文件，通过 DMA+DAC 播放。

这种“边缘采集 + 云端智能”的混合架构，是当前资源受限嵌入式设备实现高级 AI 功能的务实选择。它规避了在 MCU 上部署模型的不可能性，同时保证了用户交互的流畅性。其工程挑战在于串口通信的鲁棒性设计：需定义严格的帧头（0xAA55）、长度域、校验和（CRC16）及超时重传机制，防止语音数据包在传输中损坏导致指令误执行。

2. 示波器功能的底层实现：从 ADC 采样到波形渲染的全链路剖析

示波器是 ZHAO-Watch 最具技术挑战性的功能模块，其 200kHz 采样率与双通道同步采集能力，远超同类可穿戴设备的常规水平。实现这一指标，绝非简单配置 ADC 时钟即可达成，而是一场涉及时钟树、DMA、定时器、GPIO 与显示驱动的精密协同。

2.1 时钟树与 ADC 采样时序的硬性约束

STM32F103 的 ADC 采样速率由三个关键参数决定： ADCCLK 频率、采样周期（Sampling Time）、转换时间（Conversion Time） 。其最大允许 ADCCLK 为 14MHz（由 APB2 总线分频得到）。为达到 200kHz 采样率，单次转换时间必须 ≤ 5μs。查阅 RM0008 表 121 可知，在 ADCCLK=14MHz 时，12 位转换时间为 12.5 ADCCLK 周期（即 0.893μs），满足要求。但采样周期（即 SAMP[2:0] 位设置）会额外增加转换时间。例如，1.5 周期采样需 14 个 ADCCLK，总计 1.0μs；而 239.5 周期采样（最长）则需 17.1μs，直接导致采样率跌破 60kHz。因此，ZHAO-Watch 必然将采样周期配置为最小值 1.5 周期 ，以压榨 ADC 极限性能。

更关键的是同步问题。双通道（CH1/CH2）若使用不同 ADC，或同一 ADC 的不同通道在不同时间触发，将引入固有相位差。解决方案是： 仅启用 ADC1，将其规则通道序列配置为 [CH1, CH2]，并由 TIM1 的 TRGO 信号作为外部触发源 。TIM1 被配置为向上计数模式，自动重装载值（ARR）设为 35（因 72MHz / 35 = 2.057MHz，再经 10 分频得 205.7kHz，接近目标 200kHz）。每当 TIM1 计数溢出，便产生一个 TRGO 信号，同时触发 ADC1 开始转换序列中的第一个通道（CH1），并在 CH1 转换完成后，自动切换至 CH2 并立即开始转换。整个序列（CH1+CH2）在一次 TRGO 触发下完成，确保了绝对的同步性。

2.2 DMA 循环缓冲与波形数据流管理

ADC 转换结果需高效、无损地传递至显示缓冲区。若采用中断方式，每次转换完成即触发 ADC_EOC 中断，CPU 需执行压栈、跳转、读取 DR、存入数组、弹栈等操作，开销巨大，且在 200kHz 频率下（即每 5μs 一次中断），中断服务函数执行时间极易超过间隔，导致数据丢失。DMA 是唯一可行方案。

ZHAO-Watch 的 DMA 配置如下：
- DMA1 Channel1 ：专用于 ADC1。其外设地址为 &ADC1->DR ，内存地址为 adc_buffer （长度 20 字节，10 个 uint16_t 元素）。
- 传输方向 ：外设到内存（Peripheral to Memory）。
- 数据宽度 ：外设与内存均为 16 位（HalfWord）。
- 缓冲区管理 ：采用 Circular Mode（循环模式） 。当 DMA 将 20 字节填满 adc_buffer 后，自动重置内存地址指针，从头开始覆盖写入。此模式消除了缓冲区满时的软件干预开销。
- 中断触发点 ：启用 Half Transfer Interrupt（HTIF）与 Transfer Complete Interrupt（TCIF） 。当 DMA 写入前 10 字节（即 5 个采样点）时，HTIF 触发；当写满全部 20 字节时，TCIF 触发。主程序可在 HTIF 中断中安全地读取并处理前一半数据（此时后一半数据正在被 DMA 写入，无冲突），在 TCIF 中断中处理后一半数据。这种“乒乓缓冲”策略，使数据采集与处理完全并行，CPU 利用率可控。

2.3 OLED 显示驱动的带宽瓶颈与优化策略

ZHAO-Watch 采用的 OLED 屏幕（推测为 0.96 英寸 SSD1306，128×64 分辨率）是整个系统最大的带宽瓶颈。SSD1306 的 SPI 接口最高时钟为 10MHz，但实际在 STM32 上，受限于 GPIO 翻转速度与 SPI 外设时钟分频，有效吞吐率约为 2–3MB/s。而完整刷新一帧（128×64=8192 像素，每像素 1 位，共 1024 字节）需约 300–500μs。若每 5μs 采样一次，意味着在 10ms（2000 个采样点）内需完成 200 次屏幕刷新，显然不可行。

其真实实现必为 增量式局部刷新（Partial Update） ：
- 波形区域被划分为固定高度（如 32 像素）的垂直条带。
- 每次 DMA 传输完成（HTIF/TCIF），仅更新与新采样点对应的垂直条带。例如，若采样点映射到屏幕 X 坐标 0–127，则第 N 个点绘制在 (N % 128, Y) 位置，Y 坐标由 ADC 值线性映射（如 0V→Y=32，2.5V→Y=0）。
- 使用 XOR 操作 绘制波形线：先在目标坐标绘制一个像素，再在上一采样点坐标绘制一个像素，两次 XOR 后，仅保留当前线段。此法无需清屏，极大减少显存操作。
- 屏幕其余区域（时间、电量、温度等 UI 元素）仅在数值变更时刷新，且采用字符模式（Font 5×8），每次更新仅需写入数个字节。

这种策略将单帧刷新时间从 500μs 降低至 20–50μs，使 200kHz 采样下的实时波形显示成为可能。它体现了嵌入式开发的核心哲学：不与硬件瓶颈硬刚，而是通过算法与数据结构的设计，绕过限制。

3. 电源管理与系统稳定性：可穿戴设备的隐形战场

一块成功的手表，其灵魂不在于炫目的功能，而在于长达数天的稳定续航与毫秒级的异常恢复能力。ZHAO-Watch 的电源架构，是理解其工程成熟度的关键窗口。

3.1 多级供电网络与电池管理

项目采用 TP4056 锂电池充电管理芯片 ，支持 1A 恒流充电与 4.2V 恒压截止。其输出（VBAT）并非直接供给 STM32，而是经过 AMS1117-3.3V LDO 稳压后，为 MCU、传感器、OLED 提供干净的 3.3V 电源。此设计的关键考量在于：
- 纹波抑制 ：AMS1117 在 10kHz–100kHz 频段具有 >60dB 的纹波抑制比（PSRR），能有效滤除 TP4056 充电开关噪声，防止其耦合至 ADC 参考电压（VREF+），导致温湿度或示波器读数漂移。
- 电压监控 ：STM32 的 VDDA（模拟电源）与 VDD（数字电源）必须同源且稳定。若直接使用锂电池（3.0–4.2V）供电，当电压跌至 3.3V 以下时，MCU 可能复位或 ADC 参考失效。AMS1117 确保了只要电池电压 > 4.4V（其压差典型值），输出即为稳定的 3.3V。

更精妙的是 低电压预警机制 。STM32F103 内置 PVD（Programmable Voltage Detector），可监控 VDD。当 VDD 低于设定阈值（如 2.9V），PVD 产生中断。在 ISR 中，固件立即：
1. 关闭所有非必要外设（OLED 背光、蜂鸣器、射频模块）；
2. 将系统时钟从 72MHz 降频至 8MHz（HSE 关闭，HSI 作为 PLL 输入）；
3. 进入 STOP 模式，仅保留 RTC 与备份寄存器供电；
4. 在 RTC Alarm 中定期唤醒（如每 30 秒），检查 VDD 是否回升，若仍低则继续休眠，若回升则恢复正常运行。

此机制使手表能在电池电量耗尽前数小时，主动进入“休眠待机”状态，避免因电压骤降导致的意外复位或数据损坏，极大提升了用户体验的可靠性。

3.2 硬件看门狗（IWDG）与软件崩溃恢复

所有功能模块的稳定共存，离不开一个健壮的故障恢复机制。ZHAO-Watch 必然启用了 独立看门狗（IWDG） 。IWDG 由内部低速 RC 振荡器（LSI，约 40kHz）驱动，不受主时钟影响，即使系统因软件死锁、中断嵌套过深或总线错误而完全停滞，IWDG 仍会持续计数。当计数值溢出，IWDG 自动产生系统复位。

其配置要点在于喂狗（Reload）策略：
- 不采用裸机喂狗 ：若在主循环末尾简单调用 HAL_IWDG_Refresh(&hiwdg) ，一旦某处代码陷入死循环，喂狗即失效。
- 采用中断喂狗 ：配置一个低优先级 SysTick 中断（如 100ms 周期），在其中执行喂狗操作。即使主程序卡死，SysTick 中断仍会按时触发，保证系统不会因单点故障而永久挂起。
- 关键路径双重保险 ：对于示波器采样这类实时性要求极高的任务，其主循环中亦嵌入了喂狗操作。若 TIM1 触发正常，ADC DMA 正常，但主程序因其他原因未能执行到该点，SysTick 的备用喂狗仍能生效。

此外， SRAM 的备份域（Backup SRAM）被用于存储关键状态 。在每次系统复位后，固件首先检查 RCC_CSR 寄存器的 PINRSTF （引脚复位标志）与 IWDGRSTF （IWDG 复位标志）。若检测到 IWDGRSTF，说明发生了看门狗复位，则从 Backup SRAM 中读取上次保存的 last_error_code （如 0x01=ADC 超时，0x02=I²C NACK），并通过 OLED 或 USB 串口输出，为现场调试提供第一手线索。这种将“故障诊断”作为核心功能的设计思维，是工业级嵌入式产品的显著标志。

4. 开发者启示：从 ZHAO-Watch 看嵌入式系统工程的实践智慧

ZHAO-Watch 项目的价值，远不止于其功能列表。它是一本活的嵌入式工程教科书，处处闪耀着一线开发者在资源、时间与需求夹缝中淬炼出的实践智慧。

4.1 “够用就好”原则的极致演绎

在功能定义上，它没有追求“全功能示波器”的幻觉，而是锚定核心场景： 快速查看信号是否存在、是否翻转、大致周期与幅度 。因此，10 点波形、200kHz 采样、单触发模式，已足够满足绝大多数调试需求。放弃 FFT、数学运算、多级触发等高级功能，将宝贵的 Flash 空间留给更关键的电源管理与通信协议栈。这种克制，源于对用户真实工作流的深刻洞察——工程师在调试电路时，最需要的往往不是精确的频谱，而是“信号来了吗？高还是低？”。

4.2 硬件定义软件的铁律

所有看似“软件功能”的背后，都有其不可妥协的硬件约束。315MHz 射频遥控的实现，取决于 PT2262 的时序手册；OLED 的刷新率，受限于 SPI 的物理带宽；语音交互的可行性，由 USB 串口的通信可靠性决定。ZHAO-Watch 的成功，首先在于其硬件选型与原理图设计的严谨性。一个常见的反例是：若选用不支持硬件 CRC 的 SPI Flash，那么固件升级时的校验将不得不依赖软件 CRC32，这在 32KB 的固件镜像上需耗费数百毫秒，严重影响用户体验。而项目中所有关键外设（USB Bridge、OLED Driver、RF Module）均选择了业界验证过的成熟方案，将不确定性降至最低。

4.3 文档即代码：注释与版本控制的工程价值

在开源仓库中，ZHAO-Watch 的 main.c 文件头部注释写道：“// 2023-10-15 v1.2: Fix I2C timeout in SHT30 driver”。这短短一行，蕴含了巨大的工程信息：它记录了问题现象（I²C timeout）、定位到具体模块（SHT30 driver）、明确了修复版本（v1.2）与时间。这种粒度的版本日志，是团队协作与长期维护的生命线。它让后来者无需重走弯路，一眼就能理解“为什么这个 while 循环里要加 10ms 延时”——因为那是为了解决 SHT30 在特定批次芯片上的 ACK 响应延迟。

我在实际项目中曾遇到过类似场景：一款温湿度传感器在 -10℃ 环境下，I²C 通信成功率骤降至 30%。最终发现是传感器内部晶振在低温下起振不良，导致 ACK 时序偏移。解决方案并非修改 MCU 代码，而是在硬件上为传感器增加一个微型加热电阻，并由 MCU 的 GPIO 控制其通断。这个“硬件 hack”被清晰地记录在 hardware_notes.md 中，并附上了热成像图与温度曲线。ZHAO-Watch 的文档风格，正是这种务实精神的体现：不回避问题，不粉饰缺陷，将每一次踩坑的经验，转化为可复用的知识资产。

真正的嵌入式系统工程，从来不是在真空中编写完美的 C 代码。它是在 PCB 的铜箔间隙里，在示波器的波形毛刺中，在电池电量的缓慢流逝间，用无数个微小的、务实的、有时甚至是妥协的决策，一点一滴构筑起的可靠世界。