企业官网建设流程全解析

1. 项目全景与选型逻辑：为什么是 ESP32-S3 + DSS1864

最近在折腾一块 18×64 的柔性 LED 点阵屏，模块型号 MS288Q，板上用的是四颗 DSS1864 恒流驱动芯片。刚拿到手的时候我以为这种屏随便翻个 GitHub 仓库就能点亮，结果搜了大半天，DSS1864 的资料少得可怜，更别说现成的 ESP32-S3 Demo。最后只能自己硬啃时序，从底层驱动开始写，把 12 个动画全部跑通了。这篇文章就把整个过程的选型逻辑、接线方式、时序模型、帧缓冲设计、动画实现思路以及我踩过的坑完整记录下来。

先说结论：这块屏不是那种很常见的 P10 或 HUB75 接口屏，它属于"半定制"的柔性点阵模块，核心价值在于轻薄、可弯曲、能塞进异形外壳里做展示或穿戴设备。而 ESP32-S3 恰好是驱动它的一个比较合适的 MCU，原因有三点。

第一，内存和帧缓冲够用。18×64 是 1152 个像素点，单色模式下整帧只要 144 字节，4bit 灰度是 576 字节，8bit 灰度也才 1152 字节。哪怕用双缓冲、留三层动画叠加缓冲，ESP32-S3 自带的 SRAM 都毫无压力，更别说很多模组还外挂了 8MB PSRAM，跑复杂图像处理都能轻松放下。STM32F103 那种 20KB RAM 的芯片虽然也能点单色，但做灰度动画会非常局促。

第二，双核结构太适合做点阵刷新了。ESP32-S3 是双核 Xtensa LX7，主频 240MHz。我习惯把 LED 刷新这类对时序敏感的任务放在 Core 0 上跑，用定时器中断驱动；把动画逻辑、Wi-Fi 更新、串口命令处理这些"重量级"工作放在 Core 1 上。这样刷新率不会因为动画逻辑复杂而掉下来，两边互不干扰。

第三，生态方便扩展。自带 Wi-Fi 和 BLE，后面想做联网时钟、手机 App 推图、局域网动画下发都很顺。头文件里加个 WiFi.h 就能干的事，比外挂 ESP8266 当透传模块省事得多。

选型逻辑讲完，再看这块屏本身。MS288Q 是 18 行 64 列的单色柔性点阵模块，像素间距大概在 3mm 左右，整屏只有约 5.4cm × 19.2cm 的显示区域，非常窄长。这个比例其实很适合做文字滚动、音量表、频谱柱状图、呼吸灯这类效果。它用的柔性基底是 FPC 软板，可以弯成弧形贴合到产品外壳内侧，这是它比传统硬板点阵屏更有意思的地方。至于 DSS1864，是一颗支持 16 通道恒流输出的 LED 驱动芯片，内部集成了移位寄存器和锁存器，多颗芯片可以级联，主控只需要 DIN、CLK、LAT、OE 四根信号线，串行推数据就能控制整屏。

2. 柔性屏接线与供电设计：动手前最容易翻车的环节

很多人拿到这种屏第一反应是赶紧接上写代码，但根据我踩过的坑，建议先把接线和供电想清楚。柔性屏和硬板屏有个本质区别——它的供电走线更长更细，压降问题会被明显放大，而且排线焊盘很脆弱，反复弯折后容易断，一旦接线接错，返工成本比硬板屏高得多。

2.1 最小接线图与引脚分配

DSS1864 这类芯片对外暴露的引脚不算多，一般就是电源、地、数据输入、时钟、锁存、输出使能。我最终选定的引脚分配如下：

这套分配是我在 WROOM-1 模组的 DevKitC 开发板上验证过的，GPIO4、5、18、23 这几个口在默认状态下不会和板载 Flash、PSRAM 的引脚冲突，可以放心用。

接线时有一个细节必须注意：DIN、CLK、LAT、OE 这四根数据线在柔性排线里最好相互隔开，不要并排走长线，信号之间容易串扰。如果项目结构允许，优先用杜邦线或软硅胶线直接焊接到模块焊盘，避免用面包板飞线，因为面包板的寄生电容在 CLK 跑到 10MHz 以上时会产生明显信号畸变。

2.2 供电策略：别被理论功耗吓到，也别过于乐观

先做一道估算题。18×64 一共 1152 颗 LED，如果按单颗 20mA 全亮算，理论上要 23A，这显然不现实。实际点阵屏都靠扫描方式工作，同一时刻只有部分行导通，再加上 DSS1864 是恒流驱动，电流是受限的。我在实测中把 OE 占空比设到典型值，整屏显示白色高亮时总电流大概在 1.8A 左右，加上 ESP32-S3 的功耗，用一台 5V/3A 的电源就稳了。

不过这里有个容易忽视的点：柔性屏的 VCC 走线是从模块一端进去，再顺着 FPC 走线分到每一行，线路本身有电阻。如果你从模块单侧供电，远离供电口那一端的 LED 亮度会明显偏暗。我的做法是"双侧供电"——把 5V 线分别焊到模块左右两端的 VCC 焊盘上，GND 也两端都接，实测亮度均匀性提升非常明显，两端的压差从 0.3V 降到了 0.05V 以内。

另外，无论用什么电源，都强烈建议在模块的 VCC 和 GND 之间并联一个 1000μF 的电解电容和一颗 0.1μF 的陶瓷电容。电解电容用来吸收电流突变造成的电压跌落，陶瓷电容滤高频纹波。这一步不加的话，动画切换瞬间容易出现亮度抖动甚至 MCU 复位，别问我怎么知道的。

2.3 电平匹配：3.3V 逻辑能不能直接推 5V 芯片

DSS1864 的数据手册标称工作电压是 5V，数字信号高电平阈值大概率是 0.7×VCC，也就是 3.5V 左右。而 ESP32-S3 的 GPIO 输出高电平只有 3.3V，理论上驱动不够。但我实际测试下来，3.3V 的信号在短距离直连时是能正常触发的，因为芯片内部输入端有施密特触发器，实际的阈值比手册标称值留有余量。

不过为了稳妥，尤其是排线较长、干扰较多的情况下，我建议在四根信号线上各串一个 1kΩ 电阻再连到模块端。这个电阻主要有两个作用：一是限制瞬间灌入电流，防止 GPIO 被意外短路损坏；二是和模块输入端的寄生电容组成 RC 低通滤波器，能压制信号边沿的振铃。串了 1kΩ 之后，CLK 频率在 10MHz 以下不影响时序，10MHz 以上建议再降一点，安全优先。

2.4 柔性屏弯曲注意事项

这节额外说一点，因为标题里带了"柔性"两个字。柔性屏在安装时弯折半径尽量大于 1cm，弯折处要避开驱动芯片和排线焊盘。反复弯折同一个位置会让铜箔疲劳断裂，表现为某几行或某几列时好时坏。我一开始为了塞进一个弧形外壳，弯折太猛，结果连续烧坏了两次排线焊接点，后来改成先用热熔胶把屏体固定成需要的弧度，再去焊接信号线，问题才彻底解决。

3. 时序模型：DSS1864 是把一帧画面一层层推上去的

接线做完，核心问题来了：DSS1864 到底怎么把 18×64 的画面刷出来？这一节我把时序模型讲透，因为后面的动画框架、灰度实现、性能优化全建立在这个模型上。

3.1 数据通路：DIN/CLK/LAT/OE 各管什么

DSS1864 的驱动方式和常见的 MAX7219 有些相似，都是串行移位 + 锁存，但细节不同。可以把一片 DSS1864 理解为一个"16 位串入并出的移位寄存器 + 16 位锁存器 + 16 路恒流输出"。主控在 CLK 上升沿把 DIN 上的数据逐位移进去，凑够一组后拉高 LAT，数据就从移位寄存器进入输出锁存，最后通过 OE 引脚控制整组输出是亮还是灭。

MS288Q 模块内部把四颗 DSS1864 级联在一起，所以主控逻辑上只需要依次把四芯片的数据全部推完，再统一给一个锁存脉冲即可。单色模式下，每次更新一帧画面，就是按行把 64 列的数据逐位移入，推完 18 行后整个画面就在锁存器里了。

这里有一点容易误解：点阵屏是扫描显示的，不是一次性把所有行都点亮。DSS1864 的恒流输出通道对应的是同一行上的 16 列，而行与行之间的切换由芯片内部或模块上的行驱动电路配合完成。所以主控代码里的显示流程大致是：

循环每一行： 往移位寄存器推入该行的 64 列数据（四颗芯片级联，一次推 64 bit） 拉高 LAT，锁存 开启对应行的扫描输出（部分模块自动切换，部分需要控制行选引脚） 等待微秒级时间（行停留时间） 关闭输出，切下一行

在 MS288Q 上，行扫描逻辑已经固化在模块内，所以我只需要关心"推一行数据 + LAT 锁存"这个动作，不需要单独控制行地址。这也是它比 HUB75 接口屏简单的地方。

3.2 单色帧缓冲的组织方式

为了让动画代码写起来顺手，我用一个扁平数组作为帧缓冲：

uint8_t frameBuf[18 * 8]; // 18 行，每行 64 列 = 8 字节

每个 bit 代表一个像素，bit 为 1 时点亮。frameBuf[row * 8 + col / 8]的col % 8位就是第 row 行第 col 列。

这样的组织方式对动画逻辑非常友好。比如要在第 5 行第 10 列画一个点，只需要：

frameBuf[5 * 8 + 10 / 8] |= (1 << (10 % 8));

而底层刷新函数只需要逐行把 8 个字节推出去，代码短且高效。单色模式下这个帧缓冲只有 144 字节，ESP32-S3 上怎么折腾都不会爆内存。

3.3 灰度怎么实现：位角调制（BCM）

单色屏大家总觉得只能做点亮的开和关，但实际上通过时间上的权重分配，完全可以让它显示多级灰度。我在这个项目里实现了 4bit 灰度（16 级）和 8bit 灰度（256 级）两档，用的方法是常见的位角调制。

BCM 的原理并不复杂。假设要显示 4bit 灰度，一帧显示周期被拆成 4 个子周期，权重分别为 1/2、1/4、1/8、1/16。每个子周期里，把当前要显示的像素按"该 bit 是否为 1"决定是否点亮。人眼的视觉暂留效应会把不同点亮时长混合成不同亮度，于是灰度就出来了。

实际实现中，我在定时器中断服务函数里维护了一个"当前 BCM 层"，每次中断重新刷新一整帧，刷新完换到下一层，循环往复。核心代码大概长这样：

volatile uint8_t bcmLayer = 0; volatile uint32_t frameCounter = 0; // 4bit 灰度帧缓冲，每个像素占 4bit uint8_t grayBuf[18 * 32]; void IRAM_ATTR onTimerTick() { uint8_t mask = 1 << bcmLayer; for (int row = 0; row < 18; row++) { for (int colByte = 0; colByte < 8; colByte++) { uint8_t data = 0; for (int bit = 0; bit < 8; bit++) { int col = colByte * 8 + bit; int val = (grayBuf[row * 32 + col / 2] >> ((col % 2) * 4)) & 0x0F; if (val & mask) data |= (1 << bit); } shiftByte(data); // 推入一字节 } latch(); } bcmLayer = (bcmLayer + 1) & 0x03; }

这里的解析效率有点低，但胜在容错性高。如果要做 8bit 灰度，那就让 BCM 层走到 7 层，每层停留时间按二进制权重分配，代码结构完全不变。

3.4 为什么不用现成的 DMD 库

找库的时候我踩了两个坑，值得单独说说。网上名声最大的 DMD3 库是针对 P10 单色户内屏设计的，它的底层协议是 HUB12 类型，数据引脚里有 A、B 行地址线，刷新时主控要主动切换行地址。而 DSS1864 的模块结构里，行扫描是自动完成的，根本没有行地址引脚，硬套 DMD3 的结果就是画面只显示其中一行，其他行全灭。

另一个库是 SmartMatrix，功能确实强大，支持各种 RGB 屏和灰度，但它面向的是 HUB75 接口的 RGB 屏，引脚数多得多，而且对 ESP32-S3 的支持并不完善。折腾两天之后我得出结论：这种半定制模块就不要强行套通用库了，手写底层驱动 200 行以内搞定，反而能彻底吃透时序，后续加动画、做灰度都随心所欲。

4. 12 个动画逐个拆解：从帧缓冲到视觉效果

动画才是这个项目真正有意思的部分。12 个动画如果每个都独立实现"取帧 + 刷新"逻辑，代码会乱成一锅粥。所以我先做了一个极简的动画调度框架，然后在这个框架里填具体效果。

4.1 动画调度框架：函数指针表 + 帧缓冲约定

每个动画只需要实现一个函数：

typedef void (*AnimFunc)(uint8_t *frame, uint32_t tick);

• frame指向 144 字节的单色帧缓冲，动画函数负责往里画图；
• tick是自系统启动以来的帧序号，每次刷新加一，动画逻辑靠它控制运动速度。

调度器每帧执行一次：

const uint8_t ANIM_COUNT = 12; AnimFunc animations[ANIM_COUNT] = { animOpeningScroll, // 1. 开幕卷轴 animMarquee, // 2. 跑马灯 animSineWave, // 3. 正弦波 animBouncingBall, // 4. 弹跳球 animBinaryClock, // 5. 二进制时钟 animCyberRain, // 6. 赛博雨 animSpectrum, // 7. 频谱跳动 animGradientGlow, // 8. 全屏渐变 animBatteryGauge, // 9. 电池电量 animTextScroll, // 10. 文字轮播 animPatternShow, // 11. 图形展示 animParticleBurst // 12. 粒子扩散 }; void animTick() { animations[currentAnim](frameBuf, tick); displayFrame(frameBuf); if (++tick % (FPS * DURATION_SECONDS) == 0) { currentAnim = (currentAnim + 1) % ANIM_COUNT; } }

这种设计的核心好处是：动画函数完全不用关心底层刷新，它们只往帧缓冲里画"此刻的画面"，底层刷新函数负责把缓冲推上屏。单个动画只要不超时、不卡内存，可以随便写。

4.2 先来四个基础动画找手感

开幕卷轴：模拟舞台幕布从左到右拉开的效果。实现思路是记录当前展开的列数progress，每一帧让progress += 2，然后把 0 到progress之间的所有列全部点亮，其余列全灭。这个动画虽然逻辑极简，但配合一定的展开速度，视觉上非常干净利落。

跑马灯：把一个 16 列的箭头图案从左往右移动。每次刷新时把整帧所有像素左移一位，如果列下标减一后小于 0，就绕到最右侧，形成一个循环移动的效果。单色屏做位图移位非常方便，直接按行对字节做左移位处理，注意把前一字节的最高位补到后一字节的最低位即可。

正弦波：用sin()函数在 18 行上画一条波动的曲线。计算方式是对于列col，行位置是center + amplitude * sin(col * 0.3 + tick * 0.1)，然后在行位置上上下下各点 2 个像素，形成一条有宽度的波浪线。移动相位tick * 0.1，波浪就动起来了。

弹跳球：在 18×64 的范围内放两个小球，每个球有位置(x, y)和速度(vx, vy)，每次刷新更新位置，碰到四边就反向。为了让球看起来圆润，我在球心位置画一个 3×3 的实心方块。两个球轨迹交叉时的叠加效果很漂亮，像分子碰撞一样。

这四个动画覆盖了点阵编程最基本的能力：行列映射、位操作、数学曲线、物理模拟，是后面复杂动画的基石。

4.3 有点意思的三个动画：二进制时钟、赛博雨、频谱跳动

二进制时钟是我个人最喜欢的一个。18 行被分成三块，每块 6 行，分别显示小时、分钟、秒。每个时间单位的十位和个位用二进制竖条表示，每个 bit 对应一行，亮的行代表 1，灭的行代表 0。64 列完全够用，我给它排成：

小时十位 | 小时个位 | 分钟十位 | 分钟个位 | 秒十位 | 秒个位

每个数字 6 列，总共 36 列，剩下的列做分隔线。每次刷新时调用getLocalTime()获取当前时间，然后把每一位数值拆成二进制，逐行写入帧缓冲。这个动画做成桌面摆件特别合适，晚上关灯看尤其有赛博感。

赛博雨就是矩阵风格的竖向雨滴。每列独立生成一个"雨头"，从顶部往下落，雨头后面的像素亮度递减。单色屏没有亮度，我就用"尾巴长度"来模拟衰减——雨头位置点亮，往上 3 行点亮，再往上 5 行灭掉，形成一个梯度。

实际实现时我用了一个二维数组保存每一列雨头的位置和速度，每帧随机改变列速度，并在末尾周期性重置雨头到顶部。要做出"雨"的感觉，关键是不同列的速度不能统一，速度差越大效果越自然。

频谱跳动是这次项目里最花哨的一个，也顺手用上了 ESP32-S3 的 I2S 接口。我从板载麦克风或外接 I2S 数字麦克风采集 16kHz、16bit 的音频数据，攒够 512 个采样点后做一次 FFT，把频域数据映射到 18 行高度上。映射规则是取 0~31 个频率桶的幅值，归一化后乘 18，得到一个柱状图。

底层帧缓冲的画法很简单：对第bucket个频率桶，从底部往上数height行全部点亮。由于 ESP32-S3 主频够高，FFT 计算放在 Core 1 上毫无压力，刷新率能稳定保持在 60fps 以上。你们如果也要做这个，建议直接用esp_dsp库里的 FFT 函数，比自己写的定点数版快得多。

4.4 剩下五个动画与切换策略

全屏渐变是测试灰度能力最好的动画。在 4bit 灰度模式下，我让所有像素的灰度值随时间变化，从 0 涨到 15 再回落到 0，形成整体呼吸效果。单色屏能做出呼吸感，靠的就是 BCM 灰度，这也是为什么我在前面花大篇幅讲灰度实现，没有灰度这个动画就是纯闪烁。

电池电量是我给便携版加的功能。用 ESP32-S3 的 ADC 读取锂电池分压后的电压，按 3.3V~4.2V 区间映射成 0~5 格电量，在屏幕上画一个常规的电池图标。这个动画提醒我该充电了，实用性很强。

文字轮播支持 8×8 点阵字模，内置几个自定义字符，通过帧缓冲逐列左移实现滚动。字模可以用取模软件生成，存成const uint8_t数组，用的时候在整数行上按位画即可。

图形展示就比较轻松了——我在代码里内置了几组几何图案，比如棋盘格、同心方框、斜纹，每隔几秒切换一张。这个动画主要用来做屏体测试，检查有没有坏点或断线。

粒子扩散是最后一个动画：在屏幕中心随机生成若干"火花"，火花随时间向四周扩散，亮度按距离衰减。单色模式只画扩散后的轨迹，灰度模式就能看到火花由亮到暗的过渡。

切换策略上，我做了两层控制：默认每 10 秒自动切到下一个动画；同时监听串口，收到1~9、0、+、-等字符时手动切换。这样调试某个动画时不用干瞪眼等 10 秒，效率高很多。

5. 实测表现与稳定性排查：刷新率、花屏、残影一个都躲不掉

所有动画跑通之后，剩下的工作就是实测性能和排查各种偶发问题。这一部分是最有"现场感"的内容，我把真实的数据和排查链路写出来，供大家少走弯路。

5.1 帧率与 CPU 占用实测

我用了esp_timer在刷新回调里做计数，统计每秒实际刷新的帧数。需要说明的是，刷新率不等于视觉流畅度，动态扫描屏只要每帧刷新频率高于 100Hz，肉眼就基本看不到闪烁了。

注意表中 8bit 灰度的 50fps 是极限值，实际我一般只用到 4bit 灰度，视觉和性能最平衡。如果你对刷新率有更高要求，可以用 SPI 外设代替 GPIO 模拟移位来推数据，把 CLK 频率从 10MHz 提到 40MHz，画面会更稳。硬件 SPI 在 ESP32-S3 上最高跑到 80MHz，但 DSS1864 的 CLK 极限未必扛得住那么高，建议从 20MHz 开始往上试。

5.2 上电花屏的排查链路：GPIO 浮空导致的首帧乱码

这是我在第一次上电时遇到的最头疼问题。现象是：程序烧录完，按复位键后屏幕随机点亮几十个像素，像个乱码雪花屏，过一两秒才恢复正常动画。

我最初以为是时序代码有 bug，反复检查也找不出问题。后来用逻辑分析仪抓 DIN 和 CLK 的波形，发现一上电，CLK 引脚上就出现一串不规则的毛刺脉冲，每一个毛刺都会把 DIN 上不确定的电平当数据移位进寄存器，于是屏幕上就出现了随机点亮。

根因是 ESP32-S3 的 GPIO 在复位期间处于高阻态，引脚电平是浮空的。柔性屏的走线又比较长，相当于一根天线，环境中各种射频干扰被耦合到 CLK 上，形成毛刺。这个问题在硬板屏上也可能存在，但柔性屏更容易受干扰。

解决办法分两步。第一步，硬件上在 ESP32-S3 的 DIN、CLK、LAT、OE 四个引脚对地各接一个 10kΩ 下拉电阻，让浮空期间引脚保持确定低电平。第二步，软件上在setup()最开始就先把这个四个引脚都配置为输出并拉低，再去初始化动画数据和定时器。从代码层面确保复位到外设初始化完成之间，不会有任何上升沿出现在 CLK 上。

改完之后，上电花屏问题彻底消失。这类问题其实非常好定位，只要记住一条原则：GPIO 在复位期间不是电平稳定的，任何对毛刺敏感的外设都需要外部确定电平。

5.3 动画切换残影的排查链路：OE 和 LAT 的时序顺序不能颠倒

第二个棘手的问题是动画切换瞬间，屏幕会出现水平方向的重影，就像上一帧内容还没完全盖上就硬切到下一帧了。我把切换间隔调短后这个现象尤其明显，一开始以为是帧缓冲没擦干净，打印出来看数据完全正常。

后来我在逻辑分析仪上同时抓 LAT 和 OE 的波形，发现一个关键细节：我的刷新代码是先更新移位寄存器的数据，再拉高 LAT 锁存，然后在下一个循环的某个位置才去操作 OE 输出。这样在 OE 保持开启的状态下，移位寄存器里的数据变化会直接反映到输出端，造成大约几十微秒的"花屏窗口"。

正确做法是：任何数据更新动作开始之前，先把 OE 拉高（禁用输出），等移位寄存器里的数据全部更新完毕并完成 LAT 锁存后，再把 OE 拉低（使能输出）。也就是说，OE 的开关必须把整个数据更新过程包起来。

修复后的刷新流程变成：

void IRAM_ATTR displayFrame(uint8_t *buf) { OE_HIGH(); // 先关显示 for (int row = 0; row < 18; row++) { for (int i = 0; i < 8; i++) { shiftByte(buf[row * 8 + i]); } LAT_HIGH(); LAT_LOW(); // 锁存当前行 } OE_LOW(); // 重新开显示 }

这个改动让残影完全消失。提醒一句：如果以后你接的是支持灰度 BCM 的屏，这个"先关 OE 再更新数据"的原则同样适用，只是 BCM 模式下每次更新数据后还要按位控制 OE 占空比，时序会更复杂一点。

5.4 柔性屏发热与长时间运行稳定性

长时间点亮一小时后，我用红外温度计测了下模块表面，主要集中在 DSS1864 驱动芯片附近，温度约 55 摄氏度。这个温度在工业级芯片的正常范围内，但如果你打算把屏封进不透气的外壳里，就要考虑散热了。

我的做法是把 OE 的 PWM 占空比限制在 50% 以内，也就是说最大亮度人为降一半。虽然视觉上稍微暗一点，但对延长柔性屏寿命有好处。柔性屏的基材聚酰亚胺虽然耐热，但长期高温老化会让胶层失效，导致像素脱落。

另外，批量点亮之前最好先跑一个"全屏白 + 全屏黑交替"的疲劳测试，连续跑二十分钟，观察有没有行或列出现常亮、常灭、半亮这三种异常。我在这块屏上就发现过一颗芯片的某个输出通道恒流值偏高，导致那一列始终比其他列亮。这种情况下只能更换驱动芯片，没有软件规避的余地。

6. 再聊一点私人经验：怎么把这类"非标准屏"玩明白

回到开头那句话，DSS1864 的资料确实少，但经历过这次从零写驱动的过程，我反而觉得这类"非标屏"特别适合练技术。通用的 P10、HUB75 屏库太多，照着接线上传就亮了，缺少对底层时序的完整理解。而像 MS288Q 这种模块，因为资料少、没有现成轮子，逼着你去读数据手册、抓波形、写底层，一通操作下来，对 LED 驱动芯片的移位寄存器、锁存器、OE 控制、BCM 灰度这些概念全都理解透了。

以后再遇到其他 LED 驱动 IC，哪怕是完全陌生的型号，拿到手册先看这几个关键点：数据输入格式是串行还是并行，时钟上升沿还是下降沿采样，锁存信号是电平触发还是脉冲触发，输出使能是高有效还是低有效。这四个问题搞清楚了，驱动代码基本就能自己写出来。

这个项目目前还在继续迭代，下一步我准备把 Wi-Fi 用起来，做一个局域网内手机网页推文字、推图案的小工具。ESP32-S3 自带 Web Server，把帧缓冲通过 WebSocket 发过来，动画逻辑放在浏览器端生成，MCU 只负责刷新，玩法又多了一大截。如果你们也在玩类似的柔性点阵，欢迎一起交流踩坑经验。