摘要：今天是一场“软硬结合”的战斗。上午解决了 Linux 下 Mihomo 开启 TUN 模式的路由冲突问题，下午第一次用逻辑分析仪抓到了 STM32 呼吸灯的 PWM 波形，晚上重新审视了嵌入式学习路线。拒绝做“工具人”，要做懂底层的“验证工程师”。

Part 1: Linux 网络配置之战 (Mihomo)

早起发现代理面板的 TUN 模式开关总是自动回弹，无法接管系统流量。即便在 Service 配置中已经设置了 User=root，后台依然报错。

1. 问题现象

  • 网页上的 TUN 开关无法开启，点一下就弹回去。
  • 终端查看日志 (sudo journalctl -u mihomo) 发现核心报错： 
    1
    level=error msg="Start TUN listening error: configure tun interface: add route 0: file exists"

2. 原因与解决

原因：这是典型的“幽灵路由”问题。上一次服务非正常退出后，内核路由表中残留了 utun 设备或路由规则，导致新进程无法创建接口。

解决方案（三板斧）：
虽然尝试了重启网络服务，但最彻底的解法还是 重启系统 以清空内核状态。重启后，配合正确的 Systemd 配置（Root 权限），服务瞬间启动成功。

3. 验证分流 (Split Routing)

学会了通过终端验证 TUN 模式是否真正生效，而不是只看网页显示。

  • 验证国内直连（应显示本地 IP）： 
    1
    2
    curl cip.cc
    # 结果：显示江苏 IP，走 DIRECT 规则 -> 正常
  • 验证国外代理（应显示 VPS/机场 IP）： 
    1
    2
    curl ifconfig.me
    # 结果：显示 18.194.x.x (德国法兰克福 AWS)，走 Proxy 规则 -> 成功！

结论：Linux 网络环境配置毕业，以后可以安心做开发了。

Part 2: 硬件调试 — 逻辑分析仪首秀

下午拿出了吃灰的逻辑分析仪（FX2 芯片），配合开源软件 PulseView，对 STM32F103 的 PC13 呼吸灯引脚进行了“外科手术”式的测量。

1. 遇到的坑与填坑

  • 假象：PulseView 默认加载的是 Demo Device，看到的是假的模拟正弦波。
    • 修正：切换驱动为 fx2lafw。
  • 权限拒绝：Linux 下直接运行提示 LIBUSB_ERROR_NO_DEVICE。
    • 修正：添加 udev 规则文件，允许普通用户访问 USB 设备。
  • 采样率陷阱（最关键的一步）：
    • 起初设置为 20kHz，波形只是一根极细的针，因为采样率太低导致信号丢失。
    • 修正：将采样率提升至 2MHz 后，终于看到了完美的方波。

2. 看懂 PWM 波形

通过鼠标滚轮缩放波形，直观地看到了代码逻辑在物理世界的投影：

  • 微观视角：看到的是一个个方波（0 和 1 的跳变）。
  • 宏观视角：通过缩小，看到了占空比（Duty Cycle）的疏密变化 —— 原来这就是“呼吸灯”忽明忽暗的本质。
  • 新技能：明确了 逻辑分析仪（看逻辑/时序，二值化）与 示波器（看信号质量/纹波，模拟量）的区别。

Part 3: 迷茫与方向 — 嵌入式测试之路

晚上对于“只有逻辑分析仪，没有示波器”以及“我是不是在做低端工作”产生了焦虑。咨询了 AI 伙伴关于学习路径的建议。

1. 核心认知转变

  • 误区：以为测试就是工厂流水线上“点点点”的工具人。
  • 真相：在嵌入式领域，能用逻辑分析仪排查 Bug、理解底层时序、验证寄存器配置，这叫 “硬件验证” (Hardware Validation)。
  • 价值：这是通往资深开发的超车道。不懂底层波形的软件开发，只是“调库侠”。

今日总结：
以前觉得波形是神秘的电学符号，今天发现它就是代码的影子。能够“看见”代码在跑，这种掌控感真好。