企业官网建设流程全解析

1. 项目概述：当开发板“看见”你的鼠标

最近在捣鼓DFRobot的FireBeetle ESP32开发板，总想着让它干点不一样的事儿。它性能不错，有蓝牙有Wi-Fi，但大部分时间我们用它连传感器、做物联网网关，或者跑个小服务器。我就在想，能不能让它变得更“互动”一些？比如，让它实时感知并显示我电脑鼠标的移动轨迹，把这种虚拟的、屏幕上的动作，通过一个实实在在的硬件设备“画”出来。这个想法听起来有点跨界——把电脑外设的输入信号，通过无线方式传输到一块嵌入式开发板上，并用板载的屏幕或LED阵列进行可视化。

这不仅仅是做个“鼠标信号转发器”。其核心价值在于，它构建了一个跨设备的实时人机交互原型。你可以想象这些应用场景：在做演示时，你的鼠标指针位置能同步到一个独立的显示设备上，让观众看得更清楚；或者，为一些特殊的无障碍交互设备提供基础的输入信号捕捉与反馈机制；再或者，单纯作为一个极客桌面的酷炫摆件，实时显示你的操作活跃度。背后的技术点主要涉及三大块：在电脑端捕获鼠标坐标数据、通过无线通信协议（如蓝牙或Wi-Fi）将数据稳定地发送到FireBeetle、以及在FireBeetle上对接收到的数据进行解析并驱动显示设备。整个过程需要处理好数据格式、通信延迟和显示刷新率的协调，确保轨迹显示跟手、不卡顿。

2. 核心思路与方案选型

要实现“FireBeetle显示鼠标移动”，我们需要打通从电脑桌面到开发板屏幕的整个数据链路。这里有几个关键的设计决策点，每一个选择都直接影响到最终的体验和实现的复杂度。

2.1 信号捕获端：电脑上的“间谍”程序

首先，我们需要在电脑上写一个小程序，它的唯一任务就是持续获取鼠标光标在屏幕上的当前位置（X, Y坐标）。这里有几种主流的技术路径：

方案一：操作系统原生API这是最直接、效率最高的方法。在Windows上，可以使用GetCursorPos函数；在macOS上，有CGEventSource相关接口；在Linux上，可以通过XQueryPointer（X11系统）或libinput库来获取。这种方式的优点是延迟极低，几乎可以实时获取光标位置，且不依赖第三方库。缺点是代码需要针对不同操作系统分别编写，跨平台性差。

方案二：使用高级GUI框架利用像Python的PyAutoGUI、pynput，或者Java的Robot类等库。这些库通常封装了底层系统调用，提供了跨平台的统一接口。例如，pynput库可以非常方便地监听鼠标事件和获取位置。优点是开发速度快，代码简洁，适合快速原型验证。缺点是可能会引入一些额外的性能开销，并且需要安装对应的语言环境。

方案三：读取设备输入流（高级/底层）在Linux系统下，鼠标作为一个输入设备，其事件会体现在/dev/input/下的某个设备文件中（如eventX）。通过直接读取这个设备文件，可以解析出原始的鼠标移动事件。这种方法最底层，延迟也最小，但实现起来最复杂，需要理解Linux输入子系统的事件格式。

我的选择与理由：对于这个原型项目，我选择了方案二，具体使用Python的pynput库。原因很简单：快速验证。我们的首要目标是打通整个流程，而不是追求极致的性能。pynput跨平台（Win/macOS/Linux），几行代码就能实现鼠标监听，让我们能把精力集中在更关键的通信和显示逻辑上。等核心流程跑通后，如果对延迟有更高要求，再考虑用方案一进行针对性优化。

2.2 通信桥梁：如何把数据送到FireBeetle？

获取到坐标后，我们需要将其发送到FireBeetle ESP32。ESP32同时支持Wi-Fi和蓝牙，因此我们有两种主要的无线通信方式。

方案一：Wi-Fi通信（TCP/UDP， WebSocket）

• TCP Socket：在电脑和FireBeetle之间建立稳定的TCP连接，数据流可靠有序。适合需要可靠传输的场景，但握手和维护连接有一定开销。
• UDP Socket：无连接协议，只管发送数据包，不管是否到达。延迟比TCP低，但可能丢包。对于鼠标坐标这种连续、高频但允许偶尔丢失的数据，UDP有时是更好的选择。
• WebSocket：基于HTTP升级协议的全双工通信。特别适合需要从浏览器（JavaScript）直接与开发板通信的场景。如果我们的电脑端程序是Web应用，这是不二之选。

方案二：蓝牙通信（经典蓝牙/BLE）

• 经典蓝牙SPP：模拟串口通信，在电脑和ESP32之间建立一个虚拟的COM端口。编程模型最简单，就像读写串口一样。延迟较低，连接也相对稳定。
• 低功耗蓝牙：更节能，但传统上被认为吞吐量较低、连接建立过程稍复杂。不过对于传输简单的坐标数据（每秒几十个包），BLE完全足够，并且是现代设备的首选。

方案三：混合与备选

• MQTT：基于发布/订阅模式的消息协议。电脑作为发布者，FireBeetle作为订阅者，通过一个MQTT代理服务器（Broker）中转消息。优点是解耦了发送和接收方，方便扩展和调试。缺点是引入了中间服务器，增加了系统复杂性和潜在延迟。
• ESP-NOW：这是乐鑫特有的协议，允许ESP32设备之间直接、快速通信，无需连接Wi-Fi网络。但前提是电脑端也需要有ESP32模块作为发射端，不适合直接用电脑主板通信。

我的选择与理由：我最终选择了Wi-Fi UDP作为首轮实现的通信方式。理由如下：

1. 低延迟优先：鼠标移动数据是连续且实时的，我们更关心最新的位置，而不是保证每一个历史坐标都送达。UDP的“尽力而为”特性正好符合，避免了TCP可能因重传机制带来的延迟抖动。
2. 实现简单：无论是电脑端的Python，还是FireBeetle端的Arduino，使用Socket编程发送/接收UDP数据包都非常简单直观。
3. 网络配置灵活：只要电脑和FireBeetle在同一个局域网内即可，无需像蓝牙那样进行繁琐的配对操作。这对于调试和演示非常方便。

当然，这个选择也有缺点，比如在Wi-Fi干扰严重的环境下可能丢包。在实际测试中，我在家庭网络环境下，每秒发送50次坐标，基本感觉不到卡顿，体验良好。如果追求极致的稳定性和低功耗，蓝牙SPP会是一个很好的备选方案。

2.3 显示终端：FireBeetle上如何“作画”？

数据到了FireBeetle，最后一步就是把它显示出来。这取决于你手头有什么显示设备。FireBeetle ESP32本身没有屏幕，但它的GPIO可以连接多种显示模块。

方案一：OLED显示屏最常见的是0.96寸或1.3寸的I2C接口OLED屏。分辨率通常是128x64或128x32。优点是功耗低、对比度高、接口简单（只需两根信号线）。非常适合显示鼠标轨迹的“点”，或者简单的矢量图。缺点是屏幕小，分辨率有限，不适合显示复杂的轨迹历史。

方案二：TFT LCD彩屏比如SPI接口的ILI9341驱动的屏幕。分辨率更高（如240x320），可以显示彩色。你可以用不同颜色表示鼠标移动的速度、轨迹的新旧，视觉效果更丰富。缺点是驱动相对复杂，刷新整个屏幕速度较慢，需要仔细优化绘图算法。

方案三：LED点阵或灯带如果你想让显示效果更炫酷，可以考虑WS2812B灯带（NeoPixel）或者8x8的LED点阵屏。你可以把二维的屏幕坐标映射到一维的灯带或二维的点阵上，用灯光来代表鼠标位置。这种方式极具创意和观赏性，但坐标映射的逻辑需要自己设计。

方案四：模拟VGA/复合视频输出（高阶）通过ESP32的I2S或DAC，配合一些电阻网络，可以生成低分辨率的VGA或复合视频信号，输出到真正的显示器上。这属于高阶玩法，可以实现非常流畅和专业的显示效果，但硬件和软件复杂度都大大增加。

我的选择与理由：为了平衡易用性、效果和成本，我选择了方案一：0.96寸I2C OLED（SSD1306驱动）。原因：

• 普及度高：几乎每个玩ESP32的开发者手里都有一块，材料容易获取。
• 库支持完善：Arduino IDE中有非常成熟的Adafruit_SSD1306和Adafruit_GFX库，绘图API丰富。
• 足够演示：128x64的分辨率足以清晰显示一个“点”的移动轨迹。我们可以通过算法保留最近几十个点的位置，形成一条“尾巴”，效果已经很直观。

在软件层面，我们不会在FireBeetle上复现整个电脑桌面，而是将其视为一块“画布”。我们收到一个坐标(x, y)，需要将其从电脑屏幕的分辨率（例如1920x1080）映射到OLED屏幕的分辨率（128x64）上，然后在这个映射后的位置画一个点。

3. 系统搭建与核心代码实现

有了清晰的方案，我们就可以开始动手了。整个系统分为两大部分：电脑端的Python数据发送程序和FireBeetle端的Arduino数据接收与显示程序。

3.1 电脑端：鼠标监听与UDP发送

首先，确保你的电脑安装了Python3和必要的库。

pip install pynput

接下来是核心的Python脚本mouse_sender.py：

import socket import time from pynput import mouse # 配置参数 UDP_IP = "192.168.1.100" # 替换为你的FireBeetle的IP地址 UDP_PORT = 8888 SCREEN_WIDTH = 1920 # 你的电脑屏幕宽度 SCREEN_HEIGHT = 1080 # 你的电脑屏幕高度 # 创建UDP socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) def on_move(x, y): """鼠标移动时的回调函数""" # 将坐标归一化到[0, 1]范围，方便接收端适配不同分辨率的屏幕 normalized_x = x / SCREEN_WIDTH normalized_y = y / SCREEN_HEIGHT # 构造数据包，这里用逗号分隔两个浮点数 message = f"{normalized_x:.4f},{normalized_y:.4f}" # 通过UDP发送 try: sock.sendto(message.encode(), (UDP_IP, UDP_PORT)) except Exception as e: print(f"发送失败: {e}") # 可选：控制发送频率，避免数据量过大 # time.sleep(0.02) # 每秒约50次 # 设置监听器 with mouse.Listener(on_move=on_move) as listener: print("开始监听鼠标移动，按ESC键退出...") listener.join() # 退出时关闭socket sock.close()

代码关键点解析：

1. 坐标归一化：我们没有发送原始的像素坐标（如(500, 300)），而是发送了归一化后的比例值（如(0.2604, 0.2778)）。这是至关重要的一步！因为你的电脑屏幕分辨率（如1920x1080）和FireBeetle的显示分辨率（如128x64）完全不同。发送比例值，让FireBeetle端可以根据自己的屏幕大小重新计算实际坐标：display_x = normalized_x * DISPLAY_WIDTH。这样，无论电脑屏幕多大，轨迹都能正确适配到小屏幕上。
2. 数据格式：我们选择了最简单的字符串格式，用逗号分隔X和Y。也可以选择发送二进制数据（如两个float类型的字节流），效率更高，但字符串格式在调试时更直观，可以通过网络调试工具直接查看。
3. 发送频率：pynput的on_move回调非常灵敏，鼠标稍有移动就会触发，频率可能高达每秒数百次。我们通过time.sleep()来限制发送频率，避免网络拥堵和FireBeetle处理不过来。20ms的间隔（50Hz）对于视觉追踪来说已经非常流畅了。

实操心得：在Windows上，如果直接运行脚本，可能会因为权限问题无法捕获全局鼠标事件。建议以管理员身份运行命令行或IDE。另外，首次运行可能会被防火墙拦截，记得允许Python通过防火墙。

3.2 FireBeetle端：UDP接收与OLED显示

在Arduino IDE中，为FireBeetle ESP32安装必要的库：WiFi、WiFiUdp（内置）、Adafruit_SSD1306和Adafruit_GFX。

首先，进行硬件连接。将OLED屏的VCC、GND、SCL、SDA分别连接到FireBeetle的3.3V、GND、D22（SCL）、D21（SDA）。注意，I2C引脚位置可能因FireBeetle具体型号而异，请查阅你的板子原理图。

接下来是完整的Arduino草图firebeetle_mouse_display.ino：

#include <WiFi.h> #include <WiFiUdp.h> #include <Wire.h> #include <Adafruit_GFX.h> #include <Adafruit_SSD1306.h> // 网络配置 const char* ssid = "你的Wi-Fi名称"; const char* password = "你的Wi-Fi密码"; // UDP配置 WiFiUDP Udp; unsigned int localUdpPort = 8888; // 监听端口，需与发送端一致 char incomingPacket[255]; // 缓冲区 // OLED配置 #define SCREEN_WIDTH 128 #define SCREEN_HEIGHT 64 #define OLED_RESET -1 Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET); // 轨迹历史记录（用于画“尾巴”） #define HISTORY_SIZE 20 float historyX[HISTORY_SIZE]; float historyY[HISTORY_SIZE]; int historyIndex = 0; void setup() { Serial.begin(115200); // 初始化OLED if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) { Serial.println(F("SSD1306分配失败")); for(;;); // 死循环 } display.clearDisplay(); display.setTextSize(1); display.setTextColor(SSD1306_WHITE); display.setCursor(0,0); display.println("等待WiFi..."); display.display(); // 连接Wi-Fi WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println(); Serial.print("已连接，IP地址: "); Serial.println(WiFi.localIP()); display.clearDisplay(); display.setCursor(0,0); display.print("IP: "); display.println(WiFi.localIP()); display.display(); delay(2000); // 启动UDP监听 Udp.begin(localUdpPort); Serial.printf("UDP监听端口: %d\n", localUdpPort); // 初始化历史轨迹数组 for(int i=0; i<HISTORY_SIZE; i++){ historyX[i] = -1; // 用-1表示无效点 historyY[i] = -1; } display.clearDisplay(); display.display(); } void loop() { int packetSize = Udp.parsePacket(); if (packetSize) { // 收到UDP数据包 int len = Udp.read(incomingPacket, 255); if (len > 0) { incomingPacket[len] = 0; // 确保字符串结束 } // 解析数据，格式应为 "0.1234,0.5678" char* token = strtok(incomingPacket, ","); if (token != NULL) { float normX = atof(token); // 归一化的X坐标 token = strtok(NULL, ","); if (token != NULL) { float normY = atof(token); // 归一化的Y坐标 // 将归一化坐标映射到OLED屏幕坐标 int screenX = (int)(normX * SCREEN_WIDTH); int screenY = (int)(normY * SCREEN_HEIGHT); // 确保坐标在屏幕范围内（防止越界） screenX = constrain(screenX, 0, SCREEN_WIDTH-1); screenY = constrain(screenY, 0, SCREEN_HEIGHT-1); // 更新轨迹历史 historyX[historyIndex] = screenX; historyY[historyIndex] = screenY; historyIndex = (historyIndex + 1) % HISTORY_SIZE; // 在OLED上绘制 drawOnDisplay(screenX, screenY); } } } // 可以添加一个小的延迟以稳定系统，但非必须 // delay(1); } void drawOnDisplay(int x, int y) { display.clearDisplay(); // 1. 绘制历史轨迹（“尾巴”），用较小的点 for(int i=0; i<HISTORY_SIZE; i++){ int idx = (historyIndex + i) % HISTORY_SIZE; if(historyX[idx] >= 0 && historyY[idx] >= 0){ // 只绘制有效点 // 越旧的点，画得越小（可选效果） display.drawPixel(historyX[idx], historyY[idx], SSD1306_WHITE); // 或者用小圆圈表示历史点 // display.drawCircle(historyX[idx], historyY[idx], 1, SSD1306_WHITE); } } // 2. 绘制当前鼠标位置（用大一点或不同的图形突出显示） display.fillCircle(x, y, 2, SSD1306_WHITE); // 画一个实心圆代表当前位置 // 3. （可选）在角落显示坐标信息 display.setCursor(0, SCREEN_HEIGHT-8); display.printf("X:%3d Y:%3d", x, y); display.display(); }

代码关键点解析：

1. 坐标映射与约束：screenX = (int)(normX * SCREEN_WIDTH);这行代码完成了从归一化坐标到实际屏幕坐标的转换。constrain()函数确保计算出的坐标不会超出屏幕边界，这是一个重要的健壮性处理。
2. 轨迹历史：我们使用两个数组historyX和historyY来存储最近HISTORY_SIZE（这里设为20）个有效坐标点。historyIndex像一个循环指针，总是覆盖最旧的数据。在drawOnDisplay函数中，我们先绘制所有历史点（形成轨迹尾巴），再绘制当前点（高亮显示），这样视觉效果就有了连贯性。
3. 显示优化：display.clearDisplay()和display.display()是必须成对出现的。清屏后所有绘图指令都在缓冲区，最后调用display.display()才会真正更新到OLED屏幕上。频繁的全屏清空和重绘（尤其是在loop中）可能会造成闪烁。更高级的优化是“局部更新”或“双缓冲”，但对于这个简单的演示，当前方式已足够。
4. 数据处理：使用strtok来解析逗号分隔的字符串。这里假设数据格式完全正确，实际应用中应该增加更多的错误检查，比如检查是否成功解析出两个浮点数。

注意事项：务必修改代码中的ssid、password以及电脑端脚本中的UDP_IP（改为FireBeetle的实际IP）。FireBeetle启动后，串口监视器会打印出它的IP地址。OLED的I2C地址通常是0x3C，如果无法初始化，可以尝试0x3D，或者用I2C扫描程序确认。

4. 系统联调与效果优化

将两端代码分别部署好之后，就可以开始联调了。启动顺序建议是：先给FireBeetle上电，让它连接Wi-Fi并启动UDP服务，在串口监视器中确认其IP地址。然后修改电脑端Python脚本中的UDP_IP，再运行Python脚本。

如果一切正常，你应该能看到OLED屏上出现一个白点，随着你电脑鼠标的移动而移动，并且后面会拖着一条由历史点构成的“尾巴”。

4.1 延迟与流畅度调优

最初的版本可能会感觉有些延迟或者跳帧。我们可以从以下几个方面进行优化：

1. 降低数据发送频率与精简数据包在电脑端的on_move回调函数中，增加一个时间戳判断，确保发送间隔稳定。同时，可以精简数据包内容。我们之前发送的是像“0.1234,0.5678”的字符串，每个包大约15字节。可以改为发送两个字节的整数。例如，将归一化坐标映射到0-65535的范围（uint16_t），然后打包成4个字节的二进制数据发送。这能显著减少网络负载。

修改后的电脑端发送逻辑（片段）：

import struct last_send_time = time.time() SEND_INTERVAL = 0.016 # 约60Hz def on_move(x, y): global last_send_time current_time = time.time() if current_time - last_send_time < SEND_INTERVAL: return # 未到发送时间，直接返回 normalized_x = x / SCREEN_WIDTH normalized_y = y / SCREEN_HEIGHT # 将浮点数映射到 0-65535 的整数 int_x = int(normalized_x * 65535) int_y = int(normalized_y * 65535) # 使用 struct 打包成二进制数据 (2个 unsigned short, 即 4 bytes) data = struct.pack('HH', int_x, int_y) # 'H' 代表 unsigned short sock.sendto(data, (UDP_IP, UDP_PORT)) last_send_time = current_time

FireBeetle端相应的解析逻辑（片段）：

if (packetSize == 4) { // 我们期望4字节的数据包 Udp.read(incomingPacket, 4); // 直接读取4字节 uint16_t rawX, rawY; // 注意网络字节序转换，ntohs 将网络字节序转换为主机字节序 rawX = (incomingPacket[0] << 8) | incomingPacket[1]; rawY = (incomingPacket[2] << 8) | incomingPacket[3]; float normX = rawX / 65535.0; float normY = rawY / 65535.0; // ... 后续映射和绘制代码 }

2. FireBeetle端优化绘图display.clearDisplay()和display.display()是非常耗时的操作。我们可以尝试以下策略：

• 局部刷新：只清除和重绘轨迹发生变化的那一小块区域，而不是整个屏幕。这需要更复杂的脏矩形跟踪逻辑。
• 降低全局刷新率：不一定每次收到数据都立即刷新屏幕。可以设置一个固定的屏幕刷新率（比如30Hz），用一个定时器来控制display.display()的调用。在两次刷新之间，只更新显示缓冲区。
• 简化图形：用drawPixel画点比drawCircle或fillCircle快得多。如果不需要圆点，用像素点能极大提升速度。

3. 网络环境确保电脑和FireBeetle连接到同一个路由器，并且信号良好。避免在Wi-Fi信道拥挤的环境下使用。如果可能，将FireBeetle设置为连接路由器的5GHz频段（如果支持），干扰更少。

4.2 功能扩展与创意玩法

基础功能实现后，你可以在此基础上玩出很多花样：

1. 压力与速度可视化在电脑端，除了坐标，还可以计算鼠标移动的瞬时速度（根据两次移动的坐标差和时间差）。将速度值映射为OLED上显示点的大小或亮度。移动越快，点越大或越亮，这样就能直观地“看到”你的操作激烈程度。

2. 手势识别与触发在FireBeetle端缓存一小段连续的坐标序列，可以尝试实现简单的手势识别。比如，识别一个快速的“画圈”动作，然后让FireBeetle控制一个舵机转动，或者点亮一个特定的LED。这就把简单的显示变成了一个交互触发器。

3. 多屏/镜像显示让一个FireBeetle同时接收数据并显示很简单。你可以修改代码，让电脑端以广播（Broadcast）或多播（Multicast）的方式发送UDP数据。这样，同一个局域网内的多个FireBeetle只要监听同一个端口，就能同步显示相同的鼠标轨迹，实现多屏镜像效果，非常适合展厅演示。

4. 更换显示设备如前所述，将OLED屏换成WS2812B灯带会非常酷。你需要将二维的屏幕坐标映射到一维的灯带索引上。一种简单的映射是：将屏幕在Y轴上分成若干段，每段对应灯带的一部分，然后根据X坐标决定该段内哪个灯点亮。通过HSV色彩空间，你还可以根据坐标或速度来改变灯的颜色，创造出流光溢彩的效果。

5. 常见问题与故障排除

在实际操作中，你可能会遇到以下问题：

1. FireBeetle连接不上Wi-Fi

• 现象：串口一直打印“.”，无法获取IP。
• 排查：
  • 检查ssid和password是否正确，注意大小写。
  • 检查路由器是否设置了MAC地址过滤。
  • 尝试让FireBeetle离路由器近一些。
  • 在代码中加入WiFi.setSleep(false);，禁用Wi-Fi休眠模式，有时能提高连接稳定性。

2. 收不到数据，OLED无反应

• 现象：FireBeetle已联网，IP显示正确，但鼠标移动时OLED没变化。
• 排查：
  • 确认IP与端口：确保电脑端脚本中的UDP_IP填的是FireBeetle的正确IP，且端口8888一致。
  • 关闭防火墙：临时关闭电脑的防火墙，或者为Python程序添加入站规则，允许其通过UDP通信。
  • 网络工具监听：在电脑上使用网络调试工具（如NetAssist、SocketTool）创建一个UDP客户端，连接FireBeetle的IP和端口，手动发送一条数据0.5,0.5，看FireBeetle串口是否有打印，OLED中心是否出现一个点。这可以隔离是发送端还是接收端的问题。
  • 检查数据格式：确保发送的数据格式与接收端解析逻辑完全匹配（逗号分隔，无多余空格）。

3. 显示延迟高、卡顿

• 现象：鼠标移动后，OLED上的点要过一会儿才跟上，移动不连贯。
• 排查与解决：
  • 降低发送频率：增加电脑端SEND_INTERVAL的值，比如从0.02改为0.05（20Hz）。过高的频率可能导致网络缓冲区塞满或FireBeetle处理不过来。
  • 优化FireBeetle绘图：如前所述，改用drawPixel，并考虑降低屏幕刷新率。
  • 检查Wi-Fi信号强度：信号弱会导致数据包重传，增加延迟。

4. 轨迹显示错位或只在边缘

• 现象：鼠标在屏幕中间移动，但OLED上的点只在最左边或最右边显示。
• 原因与解决：这几乎肯定是坐标映射错误。
  • 检查归一化：确认电脑端发送的是归一化后的比例（0到1之间），而不是原始像素坐标。如果发送了1920这样的值，FireBeetle端normX * 128会得到一个巨大的数，被constrain函数限制在127，所以点永远停在最右边。
  • 检查约束函数：确保constrain函数参数正确，第二个参数是SCREEN_WIDTH-1，因为像素索引是从0开始的。

5. OLED初始化失败

• 现象：代码卡在SSD1306分配失败的循环中。
• 排查：
  • 检查接线：确认VCC、GND、SCL、SDA连接正确且牢固。SCL和SDA是否接反了？
  • 检查I2C地址：SSD1306的地址可能是0x3C或0x3D。尝试修改display.begin()语句中的地址。
  • 使用I2C扫描：上传一个简单的I2C扫描程序，查看总线上发现了哪个地址。

这个项目从构思到实现，最深的体会是**“简单协议和充分解耦”的重要性**。一开始我总想设计一个完美的、包含各种状态信息的复杂协议，后来发现，对于这种实时流式数据，一个最简单的、只包含核心信息的协议（比如归一化坐标）反而最健壮、延迟最低。把坐标映射、轨迹绘制、效果渲染这些逻辑都放在FireBeetle端，电脑端只做最纯粹的“传感器数据采集与发送”，使得两端可以独立开发和优化。下次如果再做一个类似的项目，比如用手柄摇杆控制点什么，我会毫不犹豫地再次采用这种“UDP发送归一化数据”的模式，它真的非常高效和灵活。