幽灵Bug调试实录：当 Rockchip DSI 接口只有背光，没有图像 幽灵Bug调试实录：当 Rockchip DSI 接口只有背光，没有图像在嵌入式 Linux 开发中，没有什么比“点屏”更能带来即时满足感了。相反，也没有什么比“背光已亮，屏幕一片漆黑”更令人沮c丧。这个经典的故障现象意味着：电源通了、复位信号对了、I2C 通信（如果有的话）可能也通了，背光驱动也工作了。所有低速外设全部正常，唯独高速的 MIPI DSI 视频数据流“人间蒸发”了。本文将详细复盘一次针对 Rockchip (RK) 平台的 DSI 接口调试，我们遇到了一个极其隐蔽且反直觉的 Bug：同一款屏幕，在 dsi1 接口上完美点亮，但在 dsi0 接口上却“黑屏”。0x01: 问题的“幽灵”形态我们的开发平台搭载了一颗 Rockchip SoC，它拥有两个独立的 MIPI DSI 接口（dsi0, dsi1），并分别由两个独立的视频处理器（Video Processor，vp2 和 vp3）来驱动。这是一个典型的双屏异显硬件架构。我们的目标是：dsi0 接口 (由 vp2 驱动) -\> 连接 ST7797 屏幕dsi1 接口 (由 vp3 驱动) -\> 连接 另一块 ST7797 屏幕然而，在调试中，我们却遇到了以下奇怪的“排列组合”现象：视频处理器 (VP)DSI 接口屏幕型号 (规格)结果vp2dsi05.5寸屏 (4-Lane, 131MHz)✅ 成功vp3dsi1ST7797 (1-Lane, 10.8MHz)✅ 成功vp2dsi0ST7797 (1-Lane, 10.8MHz)❌ 失败 (黑屏)这个测试矩阵提供了决定性的线索：dsi0 硬件没坏：既然它能点亮 4-Lane、131MHz 的 5.5 寸屏，证明 vp2 处理器、dsi0 控制器和 mipi_dcphy0 物理层本身都是好的。ST7797 屏幕配置没错：既然它能在 dsi1 上被 vp3 完美点亮，证明它的 DTS 配置（panel-init-sequence 和 display-timings）是完全正确的。结论：Bug 既不在 dsi0 硬件本身，也不在 ST7797 的配置本身。Bug 出现在 vp2 处理器驱动 1-Lane 低频 DSI 信号 这个特定的 组合 上。0x02: 深入 DSI 架构：VOP, Clock 与 Bit Rate要理解为什么会这样，我们必须简单了解一下数据流：[VOP (vp2)] -\> [DSI Controller (dsi0)] -\> [DSI PHY (mipi_dcphy0)] -\> [屏幕]VOP (Video Output Processor)：负责从内存中抓取图像数据，并按照 display-timings 生成像素时钟（clock-frequency）和视频流。DSI PHY (物理层)：负责将 VOP 过来的像素数据（并行）转换成高速串行差分信号（DSI Bit Stream）。这里的关键是 DSI PHY 的比特率 (Bit Rate)，它由像素时钟、色深和通道数共同决定：DSI PHY Bit Rate (每通道) ≈ (clock_frequency * bits_per_pixel) / num_lanes我们来计算一下我们案例中的 DSI 比特率（假设色深为 RGB888，即 24 bits）：dsi0 成功案例 (5.5寸屏)clock_frequency = 131.4 MHznum_lanes = 4Bit Rate ≈ (131.4M * 24) / 4 = 788 Mbps (每通道)vp2 在此速率下工作 正常。dsi1 成功案例 (ST7797)clock_frequency = 10.8 MHznum_lanes = 1Bit Rate ≈ (10.8M * 24) / 1 = 259 Mbpsvp3 在此速率下工作 正常。dsi0 失败案例 (ST7797)clock_frequency = 10.8 MHznum_lanes = 1Bit Rate ≈ (10.8M * 24) / 1 = 259 Mbpsvp2 在此速率下工作 失败。假设被证实：vp2 处理器（或其关联的 mipi_dcphy0）在 259 Mbps 这样的低 DSI 比特率下无法正常工作，它很可能存在一个最低速率门限。而 vp3 则没有这个限制。0x03: 柳暗花明：来自 SDK 的“官方线索”在我们深入研究 vp2 的寄存器之前，我们在 SDK 的其他项目中发现了另一款 1-Lane 屏幕的 DTS。这个文件提供了一个“石破天惊”的线索：/* SDK 中另一款 1-Lane 屏幕的 DTS */ fragment@1 { target = <&route_dsi0>; __overlay__ { status = "okay"; /* 注意！它把 dsi0 的数据源连接到了 vp3！ */ connect = <&vp3_out_dsi0>; }; }; fragment@2 { target = <&dsi0_in_vp3>; __overlay__ { status = "okay"; }; };这几乎是一个“官方承认”：Rockchip 的工程师也知道 vp2 驱动 1-Lane DSI 时存在 Bug，他们的官方“绕过方案”（Workaround）就是让 dsi0 也去使用 vp3 作为数据源。但这无法满足我们“双屏同显”的需求——vp3 已经被 dsi1 占用了。我们无路可退，必须修复 vp2。0x04: 绝妙的思路：提高时钟，“欺骗” VOP既然 vp2 无法工作在 10.8MHz 的低像素时钟下，我们能否在不改变屏幕刷新率（FPS）和分辨率的前提下，强行提高 clock_frequency？答案是肯定的。clock-frequency 是由 display-timings 中的所有参数（包括分辨率和消隐期）共同决定的：Clock = (hactive + hsync + hbp + hfp) * (vactive + vsync + vbp + vfp) * FPS我们可以保持 hactive (400), vactive (400) 和 FPS (60Hz) 不变，通过大幅增加消隐期（Blanking）（即 hsync, hbp, hfp 这些值），来“撑大” HTOTAL，从而拉高 clock-frequency。这就好比一条必须高速运转的传送带（vp2 的时钟限制）。为了保证每分钟只运送 60 个包裹（60Hz 刷新率），我们不能让传送带变慢，但我们可以在每个包裹之间留出巨大的空隙（增加消隐期）。1. 修改前的时序 (DSI0 - ST7797)clock-frequency = <10820160> (10.8 MHz)hactive = <400>vactive = <400>hsync-len = <2>, hback-porch = <20>, hfront-porch = <20>vsync-len = <2>, vback-porch = <4>, vfront-porch = <2>时钟验证：HTOTAL = 400 + 2 + 20 + 20 = 442VTOTAL = 400 + 2 + 4 + 2 = 408Clock = 442 * 408 * 60Hz = 10,820,160 (约 10.8MHz)DSI Bit Rate ≈ 259 Mbps。vp2 罢工。2. 修改后的时序 (DSI0 - ST7797)我们的目标是将时钟提高一倍，到 21.6MHz 左右，DSI 比特率也随之翻倍到 518 Mbps，这应该足以让 vp2 满意。保持 VTOTAL = 408 不变。目标 HTOTAL_new ≈ HTOTAL_old * 2 = 442 * 2 = 884。我们将增加的 884 - 442 = 442 个点钟周期，全部分配给水平消隐期（hbp 和 hfp），并微调 hsync。最终修改的 DTS display-timings 节点如下： disp0_timings0: display-timings { native-mode = <&dsi0_timing0>; dsi0_timing0: timing0 { - clock-frequency = <10820160>; + clock-frequency = <21640320>; /* 目标时钟翻倍 */ hactive = <400>; vactive = <400>; - hsync-len = <2>; - hback-porch = <20>; - hfront-porch = <20>; + hsync-len = <10>; /* 随意给一个合理的值 */ + hback-porch = <237>; /* 大幅增加 hbp */ + hfront-porch = <237>; /* 大幅增加 hfp */ vsync-len = <2>; vback-porch = <4>; vfront-porch = <2>; hsync-active = <0>; vsync-active = <0>; de-active = <0>; pixelclk-active = <0>; }; };时钟验证：HTOTAL_new = 400 + 10 + 237 + 237 = 884VTOTAL_new = 400 + 2 + 4 + 2 = 408Clock_new = 884 * 408 * 60Hz = 21,640,320 (约 21.6MHz)DSI Bit Rate ≈ 518 Mbps。刷入修改后的固件，dsi0 上的 ST7797 屏幕被成功点亮！ vp2 对这个速率非常满意。0x05: 总结与启示这次调试是一次完美的“逻辑推理”胜利。我们从一个看似诡异的“幽灵”Bug 出发，通过严谨的“排列组合”测试，成功地将问题定位到 SoC 的一个特定 IP（vp2）在一个特定工作模式（1-Lane 低比特率）下的 Bug。最终，我们没有修改一行内核驱动代码，而是利用了 display-timings 这一“阳谋”，在不影响屏幕实际显示（400x400@60Hz）的前提下，“欺骗” vp2 工作在它所喜欢的高频区域，完美绕过了这个 Bug。关键启示：“背光亮、黑屏”= 高速链路问题：这几乎是 DSI/LVDS 调试的黄金法则。请聚焦 PHY、时钟和数据路由。交叉验证是王道：dsi0/dsi1 vs 屏A/屏B 的 2x2 测试矩阵，是快速定位问题的最强武器。深挖 SDK：SDK 中其他“看似不相关”的配置文件，往往隐藏着厂商（如 Rockchip）留下的“官方提示”和“绕过方案”。display-timings 不只是时序，更是控制旋钮：不要把它当成一组固定的参数。它是你与 VOP 和 DSI PHY 沟通的“语言”，通过它可以微调硬件的物理层行为。

Draeyes 兽装可动眼系列 手动控制遥控器使用说明书 Draeyes 兽装可动眼系列 手动控制遥控器使用说明书 概述

APRS：业余无线电的数字化革命 APRS：业余无线电的数字化革命什么是APRS？APRS（Automatic Packet Reporting System，自动数据包报告系统）是一种实时的数字通信协议，由Bob Bruninga (WB4APR) 在1980年代末开发。它允许业余无线电爱好者通过无线电波传输位置、天气、消息和其他数据信息，创建了一个分布式的实时信息网络。APRS的核心特性实时位置跟踪APRS最为人知的功能是GPS位置跟踪。用户可以：自动发送自己的位置信息在地图上查看其他用户的位置跟踪移动中的车辆、船只或行人消息传递支持点对点的短消息传输，即使在没有互联网连接的情况下也能保持通信。天气数据许多APRS站点配备了天气传感器，可以实时报告：温度和湿度风速和风向降雨量气压应急通信在自然灾害或紧急情况下，APRS成为重要的通信工具，可以：协调救援工作传递关键信息提供备用通信渠道APRS的工作原理数据包结构APRS使用AX.25协议传输数据包，每个数据包包含：呼号（Call Sign）位置坐标时间戳符号和注释路径信息网络拓扑APRS网络采用分层结构：移动站：发送位置和数据的移动设备固定站：提供覆盖区域的固定中继站IGate：连接RF网络和互联网的网关Digipeater：数字中继器，扩展覆盖范围技术规格频率使用北美：144.39 MHz欧洲：144.80 MHz亚洲：144.64 MHz澳洲：145.175 MHz数据传输调制方式：1200 baud AFSK（音频移频键控）协议：AX.25发送间隔：根据移动速度自动调整（通常1-30分钟）所需设备基本配置无线电收发器VHF/UHF业余无线电台支持数据传输模式TNC（Terminal Node Controller）硬件TNC或软件TNC负责数字信号的编解码GPS接收器提供精确的位置信息现代设备通常内置GPS天线系统VHF/UHF天线根据使用场景选择合适类型现代解决方案随着技术发展，出现了集成度更高的设备：手持APRS电台：集成GPS和TNC功能移动APRS单元：专为车载使用设计智能手机应用：通过音频接口连接电台软件生态桌面软件APRSISCE/32：功能强大的Windows APRS客户端Xastir：跨平台的开源APRS软件APRSIS32：流行的Windows APRS应用移动应用APRSdroid：Android平台的APRS客户端PocketPacket：iOS平台的APRS应用在线服务APRS.fi：全球APRS活动的网页查看器aprs.org：官方APRS网站和资源实际应用案例户外活动徒步旅行队伍的位置跟踪自行车比赛的实时监控航海活动的安全保障应急响应地震、洪水等自然灾害的救援协调山区搜救行动的通信支持公共活动的安全保障科学研究野生动物追踪气象数据收集环境监测APRS的优势技术优势自动化：无需人工干预即可传输数据实时性：信息传输延迟低可靠性：多路径传输提高成功率开放性：协议公开，支持自主开发社区优势全球网络：覆盖世界各地免费使用：无需付费服务技术支持：活跃的开发者社区持续发展：不断有新功能和改进挑战与限制技术限制带宽限制：数据传输速率较低覆盖范围：受地形和中继站分布影响频谱拥堵：热点区域可能出现信道拥塞使用门槛执照要求：需要业余无线电操作证书技术知识：需要一定的无线电技术基础设备成本：初始投资相对较高未来发展技术演进数字化升级：向更高效的数字协议迁移互联网融合：与现代通信技术更好集成物联网应用：扩展到更多IoT场景应用拓展智慧城市：参与城市信息化建设应急管理：成为应急通信体系的重要组成教育推广：在STEM教育中发挥作用如何开始使用APRS准备工作获取执照：考取业余无线电操作证书选择设备：根据需求和预算选择合适的设备学习协议：了解APRS的基本原理和操作方法加入社区：参与本地的业余无线电活动首次设置配置设备参数（呼号、位置、符号等）设置合适的发送间隔测试信号覆盖和数据传输在线查看自己的信号是否被正确接收

Raspi Zero2W USB+TF卡扩展板项目 对Raspi Zero2W进行多功能扩展，可使用emmc或tf卡二选一启动，也附带了usb扩展坞和ups功能，通过弹簧顶针和z2w上的测试点链接

ESP32 开发笔记： GPIO 参考指南 ESP32 开发笔记： GPIO 参考指南

ESP32开发板IO定义小记 因为项目需要使用iic和spi等与传感器和屏幕进行通信，找了好久找到一张比较好的引脚说明图，因此做个记录和分享。

Dell 717W热拔插电源强行启动 早些时候手上的R610刀锋机器下架了，就闲置在家里，拆了个717W的热拔插下来。大概这样分量挺足的，输出功率大，可惜就是没风扇。闲着也是闲着，看了看接口，寻思着能不能改个开关电源出来，让它强制启动。然而，以前24pin的电源只需要短接青（绿）黑两个接口就能强制启动了咋办？查了一下万能的百度，查出这样一张针脚表上面也说的很明白，将两个3.3V下拉GND即可启动反正就这三短接即可，也没去测是否直接相邻两个+3.3v和GND用跳线帽短接是否可行。最后就这鸟样、、、主输出大概这样、、、有能力的可以增加散热风扇，不然在强制启动下，哪怕没有负载，发热量也有点惊人

电压掉电监测电路如何实现检测工作？ 电路在电压掉电时处于不稳定状态，经常需要采取一些应对措施。比如音响，内部的音频功率放大电路，在被突然拔掉电源时会发出刺耳的爆破音。如果加入电压掉电监测电路，当监测到电压掉电时，输出一个信号来触发静音电路工作，就可以消除爆破音。（静音电路，可以是在音频功率放大电路与喇叭之间加入继电器，要静音时，控制继电器断开与喇叭的连接上图是这里要介绍的一个电压掉电监测电路。电路说明电压掉电监测电路，监测的是电压 VCC。当 VCC 的电压下降到一定阀值时，三极管 Q2 导通，可以将外部电压拉到 0V；否则 Q2 不导通，对外相当于开路。原理分析VCC 是要监测的电压，这里以 VCC 等于 12V 为例进行分析。1、当 VCC 上电时，通过电阻 R1、二极管 D1 对电容 C1 充电。VCC 稳定在 12V 后，经过 R1、R2 的分压，D1 的左边为 11.25V。经过 D1 后降低了一个二极管压降，即 0.7V，最终电容 C1 的电压被充到 10.55V。2、VCC 稳定在 12V 后，Q1 的 b 极也为 12V。由于 b 极比 e 极电压还高，三极管 Q1 不导通。Q1 不导通，则 Q2 的 b 极没有电压，Q2 也不导通。3、当 VCC 掉电时，需要掉到一定的阀值，Q2 才会导通，并对外输出 VCC 掉电的信号。下图画出了三个放电回路。放电回路①：当 VCC 降低到 9.85V 时，电容 C1 的电压为充满电时的 10.55V，比 Q1 的 b 极（9.85V）高 0.7V，C1 通过 Q1 的 eb 极、电阻 R3、VCC 放电，于是 Q1 被打开。放电回路②：Q1 被打开后，电容 C1 的电压通过 Q1 的 ec 极、电阻 R4、Q2 的 be 极到地。Q2 的 b 极电压为 0.7V，于是 Q2 被打开。放电回路③：Q2 被打开后，将外接的电路电压拉到地，通过这个动作告知外部电路：VCC 掉电啦！电路参数设定说明可以设定电压侦测电路的响应阀值：方法是调整 R1 与 R2 的比值。上面的例子是 VCC 掉电到 9.85V 时，电路输出掉电信号。可以设定电路输出掉电信号的持续时间：方法是调整 C1 的容值、电阻 R3 的阻值。如增大 C1、R3 和 R4 的值，可以延长 C1 放电的时间，也就延长了 Q2 持续拉低的时间，最终延长了电路输出掉电信号的持续时间。要知道，有时候持久是很重要的。。。