企业官网建设流程全解析

做RK3568平台这几年，我接手过不少“点亮一块LVDS屏”的项目，听起来简单，实际上一头扎进去全是沟。尤其是当主控没有原生LVDS接口、屏又是LVDS接口的时候，中间那颗桥接芯片就成了整个显示链路里最容易被低估、也最容易翻车的一环。今天要聊的GM8775C，就是这类需求里非常典型的一颗国产MIPI转LVDS桥接芯片。我会基于自己在RK3568上实际点屏的调试经历，把方案选型、硬件设计、设备树配置、时钟换算和踩坑排查从头到尾捋一遍，给准备在这个方向上动手的朋友一份能直接抄作业的参考。

先交代一下背景。我最近调试的是一块用RK3568做主控的工控板，需要驱动一块21.5寸、1920x1080分辨率的LVDS工业屏。RK3568这块芯片的显示接口相当丰富，MIPI DSI、eDP、RGB都有，但唯独没有原生LVDS控制器。这意味着要么选一块本身就带LVDS接口的屏，要么加一颗桥接芯片做信号转换。市面上屏的选型往往受成本和供货限制，很多项目最后定下来的屏就是LVDS接口，所以MIPI转LVDS这条路几乎是绕不开的。GM8775C就是在这种需求下被很多方案商选中的常用芯片，价格不高、外围电路简单、适配起来也不折腾，但前提是你得把它内部的工作原理和RK3568这边的时序关系搞清楚，否则屏就是点不亮，或者亮了也是花屏、闪烁，各种莫名其妙。

1. 方案选型：为什么RK3568配LVDS屏偏偏绕不开桥接芯片

1.1 RK3568的显示接口家底与LVDS的尴尬

在做方案选型前，先得把手头这颗RK3568的显示接口能力摸清楚。RK3568作为一颗定位中高端的通用型SoC，显示子系统的资源相当够用，内置了两个MIPI DSI控制器、一个eDP控制器、一个RGB并口，还支持DP显示输出。每个MIPI DSI最高支持4-lane，速率可以跑到1.5Gbps左右（具体看封装和PCB设计），应付1080P60完全没有问题，2K屏也能勉强拉起来。eDP接口适合笔电屏或者高分屏，RGB接口则更多用在低分辨率的彩屏或者需要并口驱动的场景。

但问题在于，很多工业屏、医疗屏、以及一些特殊定制屏，接口协议还是LVDS。LVDS在工控行业里的存量太大了，从7寸到21.5寸，从单通道6bit到双通道8bit，几乎每个尺寸段都有成熟稳定的LVDS面板可选。偏偏RK3568这颗芯片没有LVDS控制器，你说气不气人。这就产生了一个很典型的刚需：把RK3568输出的MIPI DSI信号，转换成LVDS信号去驱动这类面板。

这时候有两条路摆在面前。第一，换一颗带原生LVDS接口的主控芯片，但这个选项放到真实项目里基本不现实，主控换了意味着整个硬件平台、软件生态、成本结构全部重来，除非项目还在预研阶段，否则没人会这么干。第二，就是加桥接芯片，从RK3568的MIPI DSI口取信号，转成LVDS之后送给屏。由于MIPI DSI本身信号速率高，抗干扰能力强，在设计合理的条件下信号完整性也容易保证，所以我个人的习惯是优先选择这条路，这也是目前行业里最主流的做法。

1.2 GM8775C与几类替代方案的取舍

既然要加桥接芯片，那选哪颗芯片就很有讲究了。目前市面上MIPI转LVDS的方案大概可以分成几类：第一类是FPGA自己做协议转换，灵活度高，但成本高、开发周期长、功耗也高，还要养一个懂FPGA的工程师，对绝大多数量产项目来说都是杀鸡用牛刀。第二类是国外大厂的专用桥接芯片，比如龙迅、谱瑞、东芝等也有类似产品，性能和稳定性没的说，但价格偏高，交期也不稳定，在缺芯那两年可把我们折腾惨了。第三类就是今天的主角GM8775C这类国产桥接芯片，功能专门为MIPI转LVDS设计，价格便宜，供货稳定，外围电路简单，一颗芯片加几个电容电阻就能搞定。

我选择GM8775C的原因也很直接。首先，它对MIPI DSI输入的支持足够标准，支持1/2/4-lane的DSI信号，兼容DCS命令模式和视频模式，这对接RK3568的DSI控制器非常顺滑。其次，它的LVDS输出支持单通道和双通道，能覆盖从WVGA到1080P甚至更高分辨率的范围，输出格式支持VESA和JEIDA标准，还支持6bit和8bit色深，兼容性很强。再者，这颗芯片在很多国产方案商的参考设计里已经有大量量产案例，社区的调试资料相对齐全，遇到问题至少能找到人问。

当然，并不意味着GM8775C在所有场景下都合适。如果你的产品需要同时支持多种分辨率和多种面板，希望固件层面动态切换，那GM8775C这类固定配置的桥接芯片会让你有点难受，因为它的配置方式主要是靠外部引脚状态加上电时序来决定的，虽然也有I2C可编程的版本，但整体灵活性不如FPGA或者可编程时钟芯片。所以在选型的时候一定要先想清楚自己的产品定位是单一面板量产还是多面板适配，这会直接影响后续的调试成本和维护成本。

2. 先读懂GM8775C再动手：内部架构与硬件设计要点

2.1 芯片工作流程与关键引脚

和大多数接口桥接芯片一样，GM8775C的内部工作流程可以分成三段：接收端、处理端、发送端。接收端负责把来自RK3568 MIPI DSI控制器的串行差分信号解串，恢复出并行的RGB数据信号和像素时钟；处理端做数据格式的整理，把MIPI DSI协议里的包格式转换成LVDS发送端需要的数据格式；发送端则是将并行RGB数据和像素时钟按照LVDS的标准，通过差分对串行化发送给面板。

这三段流程里，最容易出问题的其实不是芯片本身，而是芯片外围的引脚配置。GM8775C有非常多的硬件配置引脚，比如MIPI lane数选择、LVDS输出通道数选择、色深选择、VESA/JEIDA格式选择、LVDS定时参数选择等等。这些引脚在上电瞬间被采样，决定芯片的工作模式。一旦配置不对，屏的表现往往是能亮但花屏，或者根本不亮。

我第一次用这颗芯片的时候，就因为在原理图上少拉了一个配置引脚的上下拉电阻，导致芯片默认工作在了单通道6bit模式，而我的屏是双通道8bit，结果就是整个屏幕亮的，但显示内容像是被加密过一样，一行行错位，完全没法用。这个教训让我后来在硬件设计阶段就养成了习惯：每个配置引脚都预留上拉或者下拉电阻的位置，先不贴，调试时根据实际需求再焊接。这个操作在量产阶段看起来有点浪费板子面积，但在调试阶段真的是救命的设计。

硬件设计上还有一个非常容易踩的坑，就是GM8775C的I2C接口。部分版本的GM8775C支持通过I2C动态调整内部寄存器，如果你的屏SKU比较多，希望在软件层面切换不同分辨率或者格式，那这个I2C接口最好留出来，哪怕是预留一组测试点也好，后续调试会灵活很多。但如果你的方案已经固定了屏的型号和接口参数，完全可以不接I2C，直接用引脚配置写死，这样软件上更省事，驱动也不用额外写初始化代码。

2.2 时钟链路的换算逻辑：MIPI时钟、像素时钟与LVDS时钟

讲完硬件配置，接下来要聊的是整个调试流程里最核心的一环：时钟。很多显示问题，花屏、闪烁、点不亮，追根溯源都是时钟对不上。要把GM8775C配好，必须把下面这条时钟链路算清楚：像素时钟PCLK，MIPI DSI bit clock，以及LVDS输出时钟。

像素时钟是屏幕显示的基础时钟，它和分辨率、刷新率直接相关。一个标准的1920x1080@60Hz面板，像素时钟通常取148.5MHz，这个值是根据VESA标准里的CVT或者厂商规格书里的timing参数算出来的。有了像素时钟，才能算MIPI DSI这边的单通道数据速率。公式大致是：DSI Bit Clock = PCLK × 24（RGB888色深下每像素24bit） / Lane数。以4-lane为例，148.5MHz × 24 / 4 = 891Mbps，这就是每条MIPI lane需要承载的比特速率。这里还要考虑MIPI DSI协议本身的开销，通常在计算的时候会在这个基础上再留出10%到20%的余量，所以我实际在RK3568设备树里配置的lane-rate会取到990MHz左右，确保不卡在临界点上。

再说LVDS这边的时钟。LVDS的传输规则是：一个时钟周期内，每条数据lane传输7bit串行数据，所以一条Lane的串行速率是像素时钟的7倍。以单通道LVDS为例，4条数据lane每个时钟周期总共能传输28bit，对于24bit的RGB888数据来说还有4bit的余量可以传输控制信号（HSYNC、VSYNC、DE等），带宽是够的。因此，单通道LVDS在8bit模式下理论最高分辨率可以支持到1080P，但实际项目里1080P屏我一般推荐用双通道LVDS，一方面信号完整性的裕量更大，另一方面走线也能更从容一些。双通道LVDS相当于并行传输，每个通道承担半个屏幕的像素数据，时钟速率可以降下来一半，对PCB布线和EMI都有好处。

把这条时钟链路理解透了，再去读GM8775C的规格书就容易得多。它内部的PLL就是负责把MIPI DSI的高频bit clock转换成LVDS所需的像素时钟，只要输入侧MIPI频率在芯片支持范围内，输出侧LVDS像素时钟就等于你配置的面板时序里的clock-frequency。所以调试的第一个目标，就是保证RK3568设备树里的lane-rate和面板的clock-frequency能形成正确的时钟关系，这俩数值只要错一个，后面全都是白忙。

3. 设备树与时序：RK3568侧适配的完整写法

3.1 设备树节点搭建

硬件确定下来之后，软件侧的适配主要就在内核设备树里完成。RK3568的显示驱动基于DRM框架，MIPI DSI控制器是以&dsi0或者&dsi1节点形式存在的，&dsi0是第一个MIPI DSI控制器，一般默认接主屏。我们在设备树里要做的，是在这个DSI控制器节点下挂一个panel节点，用来描述外部LCD屏的型号、时序、背光控制方式等信息。

GM8775C本身不需要在设备树里注册成一个独立的驱动，因为它的配置全靠硬件引脚，没有可以用来通信的寄存器。我们在设备树里要描述的是它背后那块LVDS屏，GM8775C对屏幕来说就是一个透明的桥接芯片。所以设备树最关键的部分，就是panel节点的时序参数，这直接决定了RK3568的DSI控制器按什么节奏向外发数据。下面是一个典型的1920x1080@60Hz面板设备树片段，你可以直接对照自己的屏参数改：

&dsi0 { status = "okay"; rockchip,lane-rate = <990>; panel@0 { compatible = "simple-panel"; reg = <0>; backlight = <&backlight>; power-supply = <&vcc_lcd>; enable-gpios = <&gpio3 RK_PC5 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&lcd_panel_en_pin>; display-timings { native-mode = <&timing0>; timing0: timing0 { clock-frequency = <148500000>; hactive = <1920>; vactive = <1080>; hback-porch = <148>; hfront-porch = <88>; hsync-len = <44>; vback-porch = <36>; vfront-porch = <4>; vsync-len = <5>; hsync-active = <0>; vsync-active = <0>; de-active = <0>; pixelclk-active = <0>; }; }; }; };

rockchip,lane-rate这个属性容易被人忽略，它表示每条MIPI lane的时钟速率，单位是MHz，前面我们已经算过，1080P60 RGB888四通道的情况下算出891Mbps，再加10%余量取990MHz。这个值如果偏小，MIPI发送端的实际数据速率大于设定值，可能出现带宽不足导致的花屏；如果偏大，则超出GM8775C输入端的容忍范围，可能直接不亮或者显示异常。所以这个值一定要根据实际面板的时序去计算，不能照抄别人项目的数值。

面板的power-supply和enable-gpios则对应屏的供电和使能脚。这里我要多说一句，很多屏的规格书里会给出上电时序要求，比如电源稳定后多少毫秒再拉高使能脚、使能脚拉高后多少毫秒再开启背光等等。如果芯片内置的时序不能满足屏的要求，就需要在设备树里配合GPIO操作或者驱动代码里做延时控制。我遇到过一次背光先亮、面板后出画面的问题，客户反馈说屏幕闪了一下白屏才显示内容，非常影响体验，后来调整了背光和使能引脚的控制顺序才解决。

3.2 时序计算实例：以1080p 60Hz为例

这里再展开讲一下display-timings里那些porch值到底代表什么意思，以及怎样确认它们是否正确。很多人直接从屏厂SDK里抄过来用，能用就行，也不深究。但一旦遇到Problems，不懂这些参数会很难排查。

hactive和vactive是有效显示区域的像素数，1920和1080。hfront-porch是行同步信号结束到有效数据开始之间的像素数，hback-porch是有效数据结束到下一个行同步信号开始之间的像素数，hsync-len是行同步脉冲本身的宽度。v方向的概念类似，只是单位是行。这四个值加起来的和，再加上有效像素数，就是一行（或一帧）的总长度。总长度越大，刷新率越低，但消隐期越大，对面板控制器处理数据的压力越小。

以我这个1920x1080@60Hz的屏为例，一行总像素为1920 + 88 + 148 + 44 = 2200，一帧总行数为1080 + 4 + 36 + 5 = 1125，两者相乘就是总的像素时钟频率：2200 × 1125 × 60 = 148.5MHz，正好落在VESA标准里。这说明这些porch值是匹配的。如果你在调试中发现图像偏、滚动条纹或者行场不同步，多半就是porch值和屏的规格书对不上。

还有一点容易踩坑的是同步信号的极性。hsync-active、vsync-active、de-active、pixelclk-active这四个属性，如果设置反了，有些液晶屏也能正常显示，但有些屏就会出现花屏或者轻微的抖动。修改的方法很简单，把所有active值从0改为1再试一次，基本就能排除是极性问题还是其他原因。我个人的经验是，先按屏厂规格书里的值原样填，如果点不亮或者显示异常，再逐一反转测试，这是一个很快的排查路径。

4. 实操调试：通电到出图的完整流程

4.1 上电前的硬件检查清单

软件配置完成，编译烧录进入调试阶段，这往往是整个项目里最磨人的阶段。很多人在这个阶段翻车，不是软件写错，而是硬件设计上的隐患在通电后才暴露出来。所以我的习惯是，上电之前一定要花半个小时把硬件检查一遍，宁可慢一点，也不要让我辛苦调出来的软件被一个低级硬件错误浪费掉整个下午。

首先检查GM8775C的每一路电源是否正常。GM8775C一般需要多路供电，核心电压、IO电压、MIPI端口电压、LVDS端口电压各不相同，用万用表逐一确认电压值在规格范围内。然后检查配置引脚的上下拉电阻是否按照设计意图焊接正确，尤其是Lane数、色深、VESA/JEIDA格式这几个关键配置。再检查MIPI差分线是否连接到RK3568的DSI_TX端，注意不要把MIPI的TX接到RX上，这种错误在实际打板中真的出现过。最后检查LVDS输出到屏的排线是否和面板接口定义一致，差分线对有没有接反正负极。

在我调试过程中，还发现过一个现象：板子早上还能正常显示，放了一晚上第二天就黑屏。排查下来发现，是GM8775C的某个配置引脚在原理图上直接接电源，而电源轨是晚上断电后缓慢放电的，重新上电的瞬间电源上升沿不够陡，导致配置引脚采样的电平不确定，芯片随机进入了错误的模式。后来我在这个配置引脚上加了RC延时电路，确保各路电源稳定后再让配置引脚生效，问题就消失了。这个坑提醒我，桥接芯片的配置引脚采样时间是真实存在的，硬件设计时需要考虑电源时序，不能想当然。

4.2 上电调试与示波器验证

硬件检查没问题，就可以上电看现象了。我相信你真正关心的其实不是“能出图”这个结果，而是“出图过程中到底发生了什么”。所以调试时建议配一台示波器，带宽至少1GHz，带差分探头最好，用来测MIPI和LVDS的眼图和时钟波形。没有示波器的调试就有点像蒙着眼睛开车，能到终点全靠运气。

上电后第一步，看内核日志里panel节点有没有成功probe。在RK3568平台上，如果设备树配置正确，开机时dmesg里会有类似drm-dsi-0或者panel-simple相关的初始化信息。如果啥都没有，那就是设备树节点没有加载，多半是compatible写错了，或者status没设成okay。如果probe正常，再看有没有显示时序相关的报错信息，比如failed to find panel、invalid mode之类的，这些提示基本能定位问题方向。

第二步，用示波器测量MIPI DSI时钟差分对的波形。正常状态下，MIPI时钟的差分摆动应该是200mV左右，频率和rockchip,lane-rate设置的一致。我实测过，GM8775C在RK3568输出990MHz lane rate的情况下，MIPI时钟频率约等于495MHz，双沿采样。如果测不到这个波形，先检查MIPI控制器是否有数据输出，其次检查DSI接口的供电和复位引脚。测完MIPI，再测LVDS输出端的波形，看4对数据线和一对时钟线的差分信号是否正常出来，时钟频率应该等于设备树里设置的148.5MHz。

第三步，观测实际画面。如果画面正常，恭喜你，最难的一关已经过了。如果画面花屏、偏色、闪屏，那就要结合前面的时钟链路计算和硬件配置去逐个排查。这些坑我在下一节详细讲，因为这是整个调试过程中信息量最大、最值得记录的部分。

还有一个容易被忽视的调试工具是内核自带的测试模式。RK3568 DRM框架支持在启动早期输出纯色测试画面，通过fbcon或者drm测试节点设置。如果纯色画面出来是正常的，那基本说明桥接芯片和面板链路是通的，问题多半出在操作系统层面，比如色彩格式或者旋转配置。如果纯色画面都是花的，那就是从DSI控制器到面板之间的链路有问题，需要回到时序和硬件配置上排查。

5. 高频坑位与排查技巧实录

5.1 点不亮、花屏、闪屏的快速排查

显示调试的故障现象就那么几类，但背后的原因却五花八门。我根据自己折腾GM8775C和RK3568的经验，把最常遇到的问题、原因和排查手段整理成了一张表，方便你按图索骥。

5.2 竖屏改横屏的修改与避免面板旋转变形

项目需求里难免有竖屏改横屏的场景，特别是人机界面、智能终端这类产品，屏幕物理方向经常在最后阶段被产品经理改掉。设备树层面改方向的方法其实不复杂，问题是很多人改完之后画面是正的，但触控坐标全乱了，或者显示区域变形。这里讲几个关键点。

第一，物理方向改了，设备树里的display-timings并不是简单地把1920和1080对调那么简单。因为LVDS屏的物理分辨率是由面板内部电路决定的，竖屏改横屏一般意味着你要换一块物理长边和宽边互换的屏，或者面板本身支持竖放但你要在硬件上旋转90度。如果是前者，你需要把设备树里的hactive和vactive对应改成横屏时的值，同时clock-frequency也要跟着变。比如一块1080x1920的竖屏改放横屏，实际有效分辨率就变成了1920x1080，时钟频率从87MHz左右变成148.5MHz，porch参数也要整体重新计算。

第二，如果不想改设备树，也可以通过DRM层的rotation属性在软件层面旋转画面。RK3568的DRM驱动支持panel rotation，在panel节点的rotation属性里填<90>或者<270>，系统可以自动对画面做旋转输出。但这个方案有个坑：旋转是在内存层面做的，会占用额外的带宽和内存开销，高分辨率下可能会感觉界面响应变慢。而且有些GPU合成器不支持旋转，会退化为GPU回读再写入到显存，整个过程性能损失比较明显。所以能改设备树timing就尽量改硬件层方向，实在改不了再用rotation属性。

第三，别忘了触控。竖屏改横屏，触控坐标不旋转的话，点屏幕的位置和响应位置差90度，用起来非常痛苦。RK3568的触控屏驱动一般支持touchscreen-inverted-x、touchscreen-inverted-y以及交换x/y轴的配置，需要在设备树里把触控的映射关系同步调整过来。常见的一个做法是屏幕顺时针旋转90度后，触控坐标的y轴映射到横屏的x轴，x轴映射到横屏的y轴并取反。这里没有通用公式，只能根据实际膜组和触控IC的方向去试，一般试四次方向组合就能找到正确的组合。

5.3 GM8775C的寄存器配置、VESA/JEIDA格式与独门避坑

最后专门说一说GM8775C上容易被文档忽略、但实战非常关键的几个点。如果你用的是支持I2C配置的GM8775C版本，那内部的寄存器配置其实比引脚配置灵活很多。芯片上电后默认从引脚读取配置，但如果I2C主机在初始化阶段写入了新的寄存器值，芯片会以I2C的配置为准。这个特性意味着，你可以在同一块硬件上通过软件切换多种面板参数，非常适合做多SKU适配。不过要注意，I2C写入必须在芯片上电早期完成，否则芯片已经进入正常工作状态，你写入的配置不会生效，或者需要额外的复位操作才能重新加载。

那我为什么说一定要留意VESA和JEIDA格式？因为这是新手最容易忽略、但影响又非常大的一个配置。LVDS的信号格式分两种：VESA标准和JEIDA标准，两者的区别在于数据lane上RGB bit的映射顺序不同。如果芯片配置成VESA格式，数据按照R[0]到R[7]、G[0]到G[7]、B[0]到B[7]的排列顺序放在四个lane上，而JEIDA格式则是把MSB和LSB的顺序反过来。如果你的GM8775C输出格式和屏的输入格式不一致，画面会出现明显的颜色错乱，具体表现就是颜色残缺、色相不对，有时甚至像老式损坏的照片底片一样。

更麻烦的是，有些屏的规格书里根本不会明确写自己是VESA还是JEIDA，只给一个LVDS接口定义图，需要你自己去判断。这时候我一般会用两个办法：先默认用VESA格式（大部分AUO、BOE屏用这个），如果颜色不对就切换到JEIDA试试；另外一个办法是找屏厂FAE确认，或者直接找同款屏在别的平台上的量产配置参数。我自己的项目里就遇到过屏厂提供的参数和自己实测相反的情况，最后是靠FAE确认才解决，所以不要盲目相信文档，一切以屏幕实际显示效果为准。

在我个人经验里，还有一个特别容易被忽略的坑是MIPI DSI的控制模式。RK3568的DSI控制器支持命令模式和视频模式，GM8775C通常建议使用视频模式，因为桥接芯片不需要频繁刷新帧缓存，视频模式下数据流是连续实时的，对MCU占用也少。如果你在调试中发现帧率上不去或者画面偶尔撕裂，可以检查一下DSI控制器是不是被配置成了命令模式。在RK3568上，视频模式通常在设备树里是默认行为，但某些内核版本可能会因为panel的配置误触发为命令模式，这个检查起来很隐蔽，但如果遇到帧率问题值得看一眼。

另外说一个调试时的习惯，就是第一版板卡调试时，尽量在GM8775C的I2C总线上预留一组测试点，同时把配置引脚做成0欧电阻可选。这个改动成本几乎为零，但能让你在调试阶段快速切换芯片的各种工作模式，而不需要重新打板。我见过不少团队，第一版板子把所有配置引脚全部固定死，结果发现屏的LVDS格式不对的时候，只能飞线或者重新改板，白白浪费两周时间。这种经验往往是踩过坑之后才明白的，但我希望你能在动手之前就把这些灵活性考虑进去。

关于RK3568和GM8775C的搭配，我实际测试下来，整个显示链路稳定性是相当不错的。GM8775C的PLL锁定速度快，HSYNC/VSYNC信号解析比较稳健，配合RK3568的DSI控制器，在常温下连续跑72小时没有出现花屏或者掉帧的情况。但需要注意的是，这颗芯片的ESD耐受能力相比国外大厂产品还是要小心一些，特别是在干燥环境下的工控设备里，建议在LVDS输出端口加TVS管保护，同时在MIPI输入端口也做好静电防护，这个投入非常小，却能大幅降低售后故障率。

如果你的项目时间比较紧，我还有一个建议：不要一开始就追求完美画面，先让它亮起来。把分辨率降到最低可用的1366x768，把像素时钟调低，确认整个链路能通，再逐步把分辨率提上来。这个方法看起来笨，但在调试硬件问题的时候非常有效，至少能帮你快速区分到底是时序问题、带宽问题还是信号完整性问题，远比对着1920x1080的复杂时序分析半天来得快。

最后再分享一个小技巧。如果你遇到“屏能显示但明显偏暗”的情况，不要急着怀疑背光电路。先看看LVDS的输出通道数配置是否正确——我曾经把双通道LVDS面板接到了单通道模式的GM8775C上，结果整个屏幕只有一半显示内容，而且亮度明显不对。这个现象很容易被误判成背光老化或者排线接触不良。把芯片配置成双通道模式后，画面立刻正常，亮度也恢复正常了。这类问题在调试过程中非常典型，往往真正的凶手就是芯片一个不起眼的配置引脚，多备几个调试思路总没有坏处。