Proteus仿真51单片机LED点阵动态扫描与排错指南

1. 点阵点不亮，八成不是代码的锅

我在帮人看51单片机LED点阵广告牌的Proteus仿真时，遇到最多的一句话是“代码我在别的地方跑过，肯定没问题”。而实际情况是，十次里有七次问题出在原理图或者点阵模型的极性上，代码本身并没有错。LED点阵广告牌这个项目，表面上是“单片机+点阵+扫描程序”三件套，实际上它是一条比较脆弱的链路：取模数据、行列方向、驱动极性、扫描时序、Proteus模型特性，任何一环反了，屏幕上呈现的就是一片黑、一片乱或者只有一条亮线。它不像流水灯那样接错线还能看出个大概，点阵是“全对才显示，一处错全废”的典型。

这篇文章面向的是已经会用Keil写51程序、能看懂基本电路图，但第一次把LED点阵搬进Proteus里做仿真的朋友。我会从“为什么仿真里点阵和实物表现不一样”讲起，把8×8点阵在Proteus中的等效模型、行列驱动的两种常见方案（74HC595串行送列数据、74HC138译码选行）、取模参数的四个关键选项、定时器中断扫描的代码骨架，一直到从8×8扩到16×16滚动屏的缓冲区重排，完整讲一遍。每一节我都会把“为什么这么接”“不这么接会怎样”说清楚，因为点阵这个项目里，知道错误接法的后果，比知道正确接法更有用——它能让你在看到异常现象的第一秒就锁定方向。

先把结论摆前面：Proteus里的LED点阵仿真，和实物调试最大的区别在于Proteus不会烧坏东西，但也不会告诉你亮度不够、驱动能力不足、扫描太快导致视觉残留异常这些“模拟量”问题。它能验证的是逻辑层面：行列选通对不对、数据位序对不对、扫描顺序对不对。把这三件事在仿真里锁死，实物的成功率就上去了。反过来，指望仿真替你验证电流、亮度、闪烁频率，那基本是白费功夫。

1.1 共阴共阳判错，后面所有调试都是白费

点阵的第一个分歧点就是共阴还是共阳。8×8点阵内部是64个LED排成矩阵，为了减少引脚，把每一行LED的阳极（或阴极）连在一起引出一根脚，每一列LED的阴极（或阳极）连在一起引出一根脚，于是64个LED只需要16根引脚。所谓“共阳”，就是行线接的是所有LED的阳极，列线接的是阴极，此时给某一行高电平、某一列低电平，交叉点那颗LED才亮。共阴则完全反过来。

问题在于，Proteus元件库里那些叫MATRIX-8X8-RED、MATRIX-8X8-GREEN的模型，不同版本、不同后缀的极性并不统一，而元件符号上又不会明明白白写着“我是共阳”。我见过太多人拿着别人给的图照着连，结果对方用的是共阴点阵，自己库里只有共阳模型，连完就是一整片黑，然后开始怀疑代码。

判断方法其实很土但有效：在Proteus里只接两根线做单点测试。把点阵的某一行引脚接到一个逻辑电平（或用一位拨码开关模拟），某一列引脚串一个220Ω电阻接地（或接电源），运行仿真，看交叉点那颗灯亮不亮。亮，说明当前这组电平方向是对的；不亮，把行和列的电平同时取反再试。这一步花不了五分钟，但能省掉后面几个小时的瞎猜。

更稳妥的做法是查你手上那个模型的属性。在Proteus里双击点阵元件，看它的“Model”或者帮助文档里对引脚的定义描述，通常会说明行是Anode还是Cathode。如果查不到，就老老实实做上面的单点测试。

提示：单点测试时电阻不要省。Proteus对理想LED的模型处理比较宽松，不串电阻也能亮，但这会让你形成错误的接线习惯，等到了实物阶段，一颗LED直连IO口，轻则亮度异常，重则把单片机某个口烧掉。

确定了极性之后，把它写在你原理图的注释里，标成“行=阳极，列=阴极”或者反过来。这个注释在后面调扫描程序时会反复用到，因为“行输出高有效还是低有效”直接决定了你的行选通码是0x01左移还是0xFE左移。

1.2 动态扫描的时间账：1ms和20ms差在哪

LED点阵不能同时点亮64个点，只能一行一行（或一列一列）轮流点，靠人眼的视觉暂留把画面“拼”起来。这就是动态扫描。扫描的节奏算错了，屏幕要么闪，要么暗，要么拖影。

先把账算清楚。8×8点阵，如果每一行点亮1ms，8行轮一遍是8ms，刷新率就是125Hz。人眼对75Hz以上的刷新基本感觉不到闪烁，125Hz是很舒服的。如果每行点亮2ms，一轮16ms，刷新率62.5Hz，某些人盯着看会觉得边缘在抖。如果每行5ms，一轮40ms，刷新率25Hz，那就是肉眼可见的闪，像老式日光灯管快坏掉那种感觉。

但这里有个反直觉的地方：每行点亮时间越长，单行越亮，但整体闪烁越明显；每行点亮时间越短，闪烁越少，但单行亮度下降。因为每一行的占空比是1/8，不管你一行点多久，平均亮度都只有瞬时亮度的八分之一。想提亮，要么提高瞬时电流（硬件的事），要么减少扫描行数（比如用16行分两批扫描，或者用更少行的点阵）。

在Proteus仿真里，这个时间账会被进一步扭曲。Proteus的仿真引擎是事件驱动的，它并不严格按真实时间推进，尤其当你把定时器周期设得很短（比如100μs）时，仿真界面的刷新速率跟不上，你会看到屏幕亮度分布不均、某些行特别暗，甚至整屏在“跳”。这不是你的代码错了，是仿真器的时间步长和显示刷新打架。

我个人的经验是，在Proteus里做点阵仿真，定时器中断周期设在1ms到2ms之间最稳。1ms对应8行8ms一轮，125Hz；2ms对应16ms一轮，62.5Hz，仿真界面看起来也还算连续。低于500μs的中断周期，Proteus很容易出现“某些行被跳过”的假象，让你误以为扫描指针越界了。等你把周期改回1ms，问题消失，才知道是仿真器扛不住。

1.3 仿真通过不等于实物通过的三条硬边界

这一点必须提前说清楚，否则你会对仿真结果产生错误信任。Proteus能验证的，和你实物上会遇到的问题，中间隔着三条硬边界。

第一条是驱动电流。Proteus里的LED模型只需要极小的电流就能点亮，单片机IO口直接驱动8个LED的列线，在仿真里看起来毫无压力。但实物上，51单片机每个IO口的灌电流能力有限（常见型号单个口约10mA到20mA，整端口总和也有上限），一行8个LED同时点亮，每个LED分到的电流可能只有1mA多一点，亮度会明显不够。这就是为什么正经的点阵板子列驱动要用74HC595加三极管或者专用驱动芯片，行驱动要用74HC138加功率管。

第二条是扫描速度与MCU负载。仿真里你的单片机是“理想”的，中断响应零延迟。实物上，如果中断服务程序里干了太多活（比如在里面做移位运算、查表、判断），中断执行时间可能超过你设定的周期，导致扫描节奏乱掉。所以中断里只做“取数据、送数据、换行”这三件事，其他逻辑全放主循环，这是铁律。

第三条是点阵模块的内部结构。市面上常见的8×8点阵模块，有的是16脚双列直插，有的是把行列引出成排针，还有的模块内部已经集成了限流电阻或者驱动。Proteus模型是理想化的16脚器件，不带这些“附加物”。所以在仿真里通过的接线，搬到实物上要先核对模块的引脚定义表。

把这三条边界记住，你在仿真阶段就不会纠结“为什么仿真里很亮实物很暗”这种问题了——那本来就不是仿真该回答的。

2. 原理图阶段：五个一错就全盘重来的接线细节

原理图画错，后面的代码调试全是无用功。点阵广告牌的Proteus原理图说复杂不复杂，但有几个位置是高频错误点，我按踩坑频率从高到低排一下。

2.1 点阵元件型号与引脚序号的坑

Proteus元件库搜“MATRIX”能出来一堆：MATRIX-8X8-RED、MATRIX-8X8-GREEN、MATRIX-8X8-BLUE、MATRIX-8X8-MULTI，还有MATRIX-16X16系列。新手最容易犯的错是随便选一个能亮的，然后按“网上找的图”接线，结果引脚序号对不上。

关键在于，这些模型的引脚编号规则和你手上实物模块的引脚编号规则大概率不一样。实物模块通常是左边8个脚是列、右边8个脚是行，或者上排8个下排8个，编号从1到16顺时针或逆时针排。Proteus模型可能把行线放在1到8脚、列线放在9到16脚，也可能交错排列。

我的做法是：画图之前先单独放一个点阵元件，把它旋转到正方向，然后逐个引脚做单点测试，把“第几脚对应第几行/第几列”记在一张纸上或者写进原理图注释。8×8就是16个引脚，测一遍十几分钟，但这一步做完，后面所有接线都有了依据。

如果你图省事，直接照搬网上的图，那么至少要做一次交叉验证：找一行已知的数据（比如只点亮左上角一个点），看仿真里亮的是不是左上角。如果亮的是右下角，说明行或列的顺序反了；如果亮的是右上角，说明其中一维反了。这个验证花一分钟，比后面改代码里的位运算快得多。

2.2 限流电阻放行还是放列，位置决定亮度分布

限流电阻放哪里，是个看起来无所谓、实际上影响很大的选择。

放在行线上（每行一个电阻）：同一行里不管亮几个点，电流都由这一个电阻限制，所以当一行只亮1个点和亮8个点时，单个LED分到的电流差别很大，亮1个点时会特别亮，亮8个点时偏暗。这会导致显示不同内容时整体亮度不均匀。

放在列线上（每列一个电阻）：每一列的电流独立限制，一行里点亮几个点，每个点的电流基本一致，亮度均匀性更好。

所以在动态扫描行、静态送列数据的结构里，电阻放在列线上更合理。8×8点阵就是8个电阻，阻值取220Ω到470Ω之间。Proteus里电阻值对亮度的影响不明显，但实物上这个值决定了你能不能在“够亮”和“不过流”之间取得平衡。我一般从330Ω起步，如果整体偏暗再往下降，但不会低于220Ω。

还有一个细节：如果用74HC595做列驱动，电阻要放在595的输出脚和点阵列脚之间，不要放在595和电源之间。原因很直白——595输出的是电平，不是电流源，串在输出路径上才能限制流过LED的电流。

2.3 74HC595级联与74HC138译码的接线核对表

行选通常用74HC138（3-8译码器），列数据用74HC595（串入并出移位寄存器）。这两个芯片的接线错误率最高，我把关键引脚和常见错误列成表，画完图逐条对一遍。

这张表里最隐蔽的是74HC138的G2A和G2B。这两个是低电平有效的使能端，必须接地，很多人只接了G1就以为完事，结果八个输出全是高电平，点阵一行都不亮，然后开始查代码。

还有一个容易忽略的点：74HC138的输出是低电平有效。也就是说，Y0输出低电平时，对应的那一行才被选中（如果行是共阴接法）。如果你的点阵是共阳行，那138的输出不能直接接行线，中间要加一级反相器（比如74HC04）或者用三极管倒相。这一步在Proteus里如果忘了，现象就是“译码器输出正常但点阵全黑”，非常容易误判成点阵坏了。

2.4 P0口上拉、EA电平、晶振频率这些“默认值”

51单片机的几个“默认配置”，在实物上通常有现成的开发板帮你处理好了，但在Proteus里必须自己接。

P0口是开漏输出，作为普通IO使用时必须外接上拉电阻，典型是10k排阻接到VCC。Proteus里如果不接，P0口输出高电平时呈现高阻态，驱动的东西不工作。如果你把74HC595的控制线接在P0口又没加上拉，表现就是“数据送不进去，595输出乱跳”。

EA引脚（第31脚）必须接高电平，表示从内部程序存储器执行。Proteus里如果悬空，某些模型会默认从外部取指，程序根本不跑。这个坑的迷惑性在于：仿真能启动，但单片机像“死机”一样，所有IO都不动。

晶振和复位电路在Proteus里其实可以省略——Proteus的51模型有内部时钟属性，双击单片机在属性里可以直接设“Clock Frequency”。但我建议还是把晶振和两个30pF电容画上，一是养好习惯，二是晶振频率这个值必须和你代码里的定时器初值对应。代码按12MHz算的初值，属性里设成11.0592MHz，定时周期就偏了，扫描节奏会不对。Proteus里直接在属性里改频率最方便，但改完记得回头核对代码里的重装值。

2.5 元件属性里的隐藏开关

Proteus有些元件的默认属性会悄悄影响仿真结果，不打开属性对话框根本发现不了。

点阵元件通常有个“Minimum Trigger Current”或者类似的参数，某些版本的默认值偏大，导致逻辑上应该点亮的点在仿真里看着很暗甚至不亮。遇到“电平明明对但灯不亮”的情况，可以双击点阵看看这个参数，适当调小。

LED单个元件有“Forward Voltage”和“Forward Current”属性，点阵模型内部也是类似机制。这些参数一般不用动，但如果你的仿真里出现了“同一行有的点亮有的点不亮”的诡异现象，可以先怀疑是不是模型参数导致的，换一个点阵型号试试，能快速排除。

还有一个是仿真速度设置。Proteus的“Animation”或者仿真速度如果设得过高，动态扫描的画面会显得断断续续；设得过低，又慢得像幻灯片。这个没有标准值，边跑边调，找到一个“看着连续、不卡顿”的状态就行。

3. 字模数据：显示乱码的根源大多在这里

代码逻辑全对，屏幕显示出来的却是旋转了90度的鬼画符，这种情况我遇到过太多次。问题几乎都出在取模环节。取模软件把一张图转成一串十六进制数，这中间有四个维度可能出错，任何一个错了，显示结果就完全不一样。

3.1 取模软件的四个选项定生死

以常用的PCtoLCD2002这类取模工具为例，生成8×8或者16×16点阵数据时，有四个关键选项：

第一个是阴码还是阳码。阴码表示“1代表点亮”，阳码表示“0代表点亮”。这个选择必须和你的驱动电路匹配：如果你的列驱动是595输出高电平点亮LED，那就该用阴码（1=亮）；如果是输出低电平点亮，那就用阳码。选反了，显示的就是原图的反色，白底黑字变成黑底白字。

第二个是逐行式还是逐列式。逐行式是按行扫描，一行8个点组成一个字节；逐列式是按列扫描，一列8个点组成一个字节。这个必须和你的扫描方式一致。你的代码是“一次送一列的8位数据，然后切换行”，那就该用逐列式；如果是“一次送一行的8位数据，然后切换列”，就用逐行式。选反了，图像会旋转90度。

第三个是顺向还是逆向。这指的是字节内部的位序，也就是一个字节的8位对应8个点，是从左到右还是从右到左。选反了，每一行（或每一列）的图像会左右镜像。

第四个是取模走向，也就是从图形的哪个角开始取。这个和顺向/逆向配合，决定了整体的上下左右方向。

四个选项，理论上有16种组合，但真正常用的就那么两三种。我的建议是：不要靠猜，用“单点验证法”反推。

3.2 用“单点定位法”验证行列方向

具体做法是：在取模软件里画一个只有左上角一个点亮的8×8图，取模，得到一串数据（比如8个字节）。把这8个字节原封不动放进代码里显示，看仿真中点阵哪个位置亮。

• 亮在左上角：方向全对，可以开始做正经图案了。
• 亮在右上角：位序反了，把取模软件的“顺向/逆向”选项切换一下。
• 亮在左下角：取模走向的上下反了。
• 亮在右下角：位序和走向都反了。
• 亮在中间某一行的最左边：说明你的扫描方式和取模方式不匹配，逐行/逐列要换。

这个方法的好处是，一次仿真就能锁定一个维度的错误，最多试三四次就能把四个选项全定下来。定下来之后，把这套设置记在代码注释里，以后所有字模都用这套设置取，就不会再乱。

我当时做第一块点阵的时候，就是靠这个方法在半小时内把方向全对齐的。在那之前我已经瞎改了快两个小时，改代码里的移位方向、改接线顺序，越改越乱。

3.3 一张自制测试表快速比对

方向定下来之后，建议做一个“测试图案集”，包含几个固定的图案：全亮、全灭、四角各一个点、中间一个十字、一帧数字“8”。每次改完代码或者换点阵型号，先跑这几个图案，能立刻看出有没有退化。

我把这个做成了一张对照表，贴在工作区：

注意这些数据只是示例，具体值取决于你的取模设置。全亮和全灭这两组是“绝对正确”的，不受方向影响，所以最适合用来验证硬件通路。如果全亮都不亮，那问题一定在驱动电路或扫描代码，跟取模无关。

3.4 汉字取模：16×16为什么不能直接套8×8的参数

广告牌上的内容通常是汉字，一个16×16的汉字需要32个字节（每行2字节，16行）。这里有个新手常踩的坑：把8×8那套取模参数直接用在16×16上，结果汉字被拆成上下两半或者左右两半。

原因是取模软件在16×16模式下，有些版本的“逐行式”含义变了——它可能按“先取上半部分8行，再取下半部分8行”的方式组织数据，而不是“每行16个点连续取两个字节”。这两种组织方式在内存里看起来都是32字节，但排列完全不同。

判断方法是看取模软件生成的预览或者数据排布说明。如果它生成的32字节是“字节0到字节15对应左半边（或上半边），字节16到31对应另一半”，那你的代码里就要相应地拆成两块来送；如果是“每两个字节一行，共16行”，那就是标准的行优先排列。

我的习惯是，取完一个字模后，先在取模软件里用“数据回显”功能看一眼，确认32字节重新还原成的图形和原图一致，再放进代码。这个回显功能大部分取模软件都有，只是很多人不知道。

4. 扫描代码骨架：把刷新放进定时器中断

代码结构这一块，我不想给你一大段几百行的完整工程，而想讲清楚“为什么这么组织”。因为点阵扫描代码的写法有无数种，但能稳定跑起来的，结构都差不多。

4.1 显示缓冲区与扫描指针的分工

核心思想是：主循环负责“想显示什么”，中断负责“把想显示的东西刷出去”。这两件事必须解耦，否则主循环里稍微加一点耗时逻辑（比如按键扫描、串口接收），扫描节奏就会被打乱。

具体做法是定义一个显示缓冲区unsigned char dispbuf[8]（8×8点阵），主循环里往这个数组里写数据，定时器中断里从这个数组里读数据往点阵送。中断只做三件事：消影、送列数据、切行。

#include <reg52.h> sbit SER = P3^4; /* 595 串行数据 */ sbit SRCLK = P3^5; /* 595 移位时钟 */ sbit RCLK = P3^6; /* 595 锁存时钟 */ unsigned char dispbuf[8] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}; unsigned char row = 0; void send595(unsigned char dat) { unsigned char i; for (i = 0; i < 8; i++) { SER = (dat & 0x80) ? 1 : 0; dat <<= 1; SRCLK = 0; SRCLK = 1; /* 上升沿移位 */ } } void timer0_init(void) { TMOD = (TMOD & 0xF0) | 0x01; /* 定时器0，方式1 */ TH0 = 0xFC; /* 12MHz 下约 1ms */ TL0 = 0x18; ET0 = 1; EA = 1; TR0 = 1; } void scan_isr(void) interrupt 1 { TH0 = 0xFC; TL0 = 0x18; P2 = 0xFF; /* 先关闭所有行，消影 */ send595(dispbuf[row]); /* 送入当前行的列数据 */ RCLK = 0; RCLK = 1; /* 上升沿锁存，列数据生效 */ P2 = ~(1 << row); /* 打开当前行（低有效） */ row++; if (row >= 8) row = 0; }

这段代码里，row是扫描指针，dispbuf是显示缓冲区。主循环里改dispbuf的内容，屏幕立刻跟着变。中断周期1ms，8行扫一遍8ms，刷新率125Hz。

这里有个细节值得说：row和dispbuf的关系决定了扫描顺序。如果dispbuf[0]对应点阵第一行，那row从0加到7就正好从上到下扫；如果接线时行线顺序接反了，你可以选择改接线，也可以在代码里把row的方向反过来（row从7减到0）。我倾向于改代码，因为改接线容易在Proteus里点错引脚。

4.2 消影这一步为什么不能省

P2 = 0xFF;这一行看起来多余，实际上是动态扫描里最不能省的一步。

原因是这样的：当你要从第0行切换到第1行时，595里还留着第0行的列数据。如果你先打开第1行、再送第1行的数据，中间会有一个极短的时间窗口，第1行带着第0行的数据亮了那么一下。这个“串影”在仿真里可能看不出来，但在实物上、在扫描速度不够快的时候，会表现为字符边缘有淡淡的残影，整个屏幕看起来“脏”。

正确顺序永远是：关行 → 换列数据 → 开新行。先关掉当前行，此时屏幕全黑，然后从容地把新一行的列数据锁存进595，最后打开新行。这样任何瞬间都不存在“新行配旧数据”的组合。

我在早期版本里省过这一步，屏幕上出现了明显的横向拖影，当时还以为是595坏了，查了半天芯片手册。后来把消影加回去，拖影直接消失。这个教训值得每一个做点阵的人记一下。

4.3 595移位与锁存的时序顺序

74HC595的工作过程分两步：先通过SRCLK把8位数据一位一位移进内部的移位寄存器，再通过RCLK的上升沿把移位寄存器的内容整体复制到输出锁存器。这两步的顺序不能乱。

常见错误是“边移位边锁存”，也就是在循环里把RCLK也翻转。这样做的结果是，每移一位就把当前的部分数据锁存到输出，屏幕上的列数据会变成一串乱码。

正确的做法是：send595函数里只翻SRCLK，8位全部移完之后，在函数外面翻一次RCLK。上面那段代码就是这么写的。这里有个可以优化的点：如果你的行数据不需要每个周期都变，可以把锁存和移位的顺序调一下，先移位再切行，能省一点时间。但在1ms的周期里，这点时间可以忽略不计，代码可读性更重要。

4.4 亮度调节的两个方向

在Proteus里调亮度意义不大，但知道原理有助于实物调试。亮度调节有两个方向：

一个方向是调扫描周期。周期越短，刷新率越高，闪烁越少，但每一行的点亮时间占比（占空比）不变，平均亮度不变。所以调周期只影响闪烁，不影响亮度。

另一个方向是调占空比。在固定周期里，让每一行点亮的时间更长、关断的时间更短，平均亮度就上去了。实现方法是在每个扫描周期里，先开行、延时一小段、再关行，剩下的时间用来处理别的事情。但这样做会压缩留给中断处理的时间，占空比提得太高，中断会变得很紧张。

实物上还有一个方向是调限流电阻，这是最直接的。仿真里电阻值不影响显示逻辑，但实物上从330Ω降到220Ω，亮度提升很明显。代价是电流变大，要核算单片机和驱动芯片的承受能力。

5. 五类典型故障的完整排查链路

这一节是本篇的核心。我把Proteus点阵仿真里最常遇到的五类故障，按“现象、可能原因、排查顺序”写成完整的链路，你可以照着一步步走。

5.1 整屏全黑但引脚电平正常

现象：仿真跑起来，用Proteus的电压探针看单片机IO口、595输出、138输出，电平都在跳变，看起来一切正常，但点阵一个点都不亮。

排查顺序：

第一步，查点阵极性。回到1.1节的单点测试，用固定电平直接驱动一行一列，确认点阵本身能被点亮。这一步排除“点阵模型选错极性”。

第二步，查595的OE脚。OE是低电平使能，如果悬空或者接了高电平，输出是高阻态，电平探针可能显示“有变化”但实际驱动不了负载。把OE直接接地。

第三步，查138的使能脚。G1接VCC，G2A和G2B接GND，三个都对了吗？少接一个，八个输出全是高电平，行永远选不中。

第四步，查限流电阻。如果电阻值设得过大（比如10k），Proteus里可能因为电流太小而不亮。先把电阻改成100Ω试一下，亮了就说明是阻值问题。

第五步，查共地。单片机的GND、595的GND、138的GND、点阵的公共端，在Proteus里都必须连到同一个GND符号上。Proteus不会因为“名字都叫GND”就自动连起来，必须用导线或者同一个终端符号。

5.2 只亮一行或只亮一列

现象：屏幕上只有一行（或一列）在亮，而且内容会变，其他行全黑。

这个现象几乎可以锁定在行扫描信号上。排查：

先看138的输出。用探针逐个看Y0到Y7，正常情况下应该轮流出现低电平。如果只有一个输出在动，说明A、B、C三根地址线只接了一根或者接错了。138的ABC对应二进制的三位，A是最低位，C是最高位，接反了会导致扫描顺序错乱，但不会只亮一行。

如果138的八个输出都在正常轮流变低，那问题在行线和点阵的对应关系上。可能是行线只接了Y0，其他七根没连上，或者连到了点阵的同一根引脚上。

还有一种可能是扫描指针没清零。代码里row如果是个没有初始化的全局变量，或者中断里忘了if (row >= 8) row = 0;，指针会一直加下去，越界访问dispbuf，行为不可预测。C51里数组越界不会报错，只会读到内存里的随机值。

5.3 图像镜像、倒置、错位一行

现象：显示的内容能看出来是什么，但是左右反了、上下倒了，或者整体偏移了一行/一列。

这三种现象对应三个不同的原因，别混在一起查。

镜像（左右反）：位序问题。取模软件的“顺向/逆向”选项和你的595送出顺序不匹配。595是先送最高位（MSB）还是最低位，取决于你的send595函数怎么写。上面那段代码是先送MSB（dat & 0x80），如果你的取模数据是按LSB在前的顺序生成的，就会镜像。解决办法是改取模软件选项，或者在send595里改成先送LSB。

倒置（上下反）：行扫描顺序问题。row从0加到7，但点阵的第0行在物理上是最下面那行。改代码让row从7减到0，或者把行线接线顺序反过来。

错位一行：显示缓冲区和扫描指针的对应关系差了一位。比如你想显示的内容应该从dispbuf[0]开始，但实际从dispbuf[1]开始送了。检查中断里是先取数据还是先加指针。

5.4 仿真卡顿、闪烁、字符拖影

现象：仿真运行时界面很卡，或者屏幕上的字符明明灭灭，边缘有拖影。

卡顿的第一嫌疑是定时器周期太短。前面说过，Proteus的仿真引擎对高频率中断的处理能力有限，中断周期低于500μs时，仿真器可能来不及处理每一次中断，表现为“某些行被跳过”。把周期改到1ms到2ms试试。

第二个嫌疑是中断服务程序太长。如果你的中断里除了送数据还做了查表、运算、判断，执行时间可能超过定时周期，导致中断嵌套或者丢中断。把所有非必要的逻辑移到主循环。

拖影的原因前面讲过，九成是没消影。在换行之前先把行关掉，再送新数据。如果加了消影还有拖影，检查一下消影和开新行之间是不是隔得太近，中间要给595的锁存留出时间。

还有一个小概率原因：Proteus的显示刷新率和你的扫描频率“拍频”了，看起来像在闪。这种情况下把扫描频率稍微调一下（比如从1ms改成1.2ms），现象可能就消失了。这不是代码问题，是仿真器的显示机制。

5.5 仿真正常烧录后全乱

这是最让人崩溃的一类：仿真里跑得好好的，程序烧进实物，屏幕上全是乱码或者根本不亮。

原因通常有三个。第一个是晶振频率不一致。仿真里你在属性里设了12MHz，实物上焊的是11.0592MHz，定时器周期就偏了8%左右，扫描节奏变了，虽然不至于全乱，但闪烁会明显。如果实物用的是完全不同的频率（比如6MHz），那定时器初值要重算。

第二个是IO口驱动能力。仿真里595的输出直接驱动点阵没问题，实物上如果点阵模块需要较大电流，595的输出可能被拉低，导致列数据错误。解决办法是加三极管或者用专用的行驱动芯片。

第三个是复位电路和EA脚。实物上如果EA没接高、复位电容取值不对，单片机可能工作不正常。这些在仿真里都被“理想化”了。

排查这类问题，我的顺序是：先用万用表量单片机各引脚静态电平，确认电源、复位、EA正常；再用示波器（或者用IO口翻转法）确认晶振在起振；最后才是查显示相关的引脚。

6. 从8×8原型扩到16×16滚动屏

8×8只是原型验证，真正的广告牌至少要16×16才能显示一个汉字，要做滚动字幕还得更宽。从8×8扩到16×16，不是简单地把数组开大两倍，有几个地方要重新算。

6.1 行译码还是行595，成本与刷新率的重算

8×8用一片138就能选8行，16×16需要选16行。两种方案：

方案一是两片138级联，用4根地址线选16行。优点是接线简单，缺点是138的输出还是低有效，如果要驱动共阳行，中间还得加反相。

方案二是用两片595级联做行驱动，16位里有一位是低电平，其余是高电平。优点是输出极性可以灵活控制，缺点是每次换行都要移16位，中断里花的时间变长。

在Proteus仿真里，我更倾向方案二，因为595的行驱动不需要额外的反相器，接线更干净，而且仿真不关心成本。实物上要考虑595的驱动能力，通常还要加三极管。

刷新率的账要重算：16行，每行1ms，一轮16ms，刷新率62.5Hz。这个值偏低，某些人会觉得闪。可以把每行时间降到0.6ms，一轮9.6ms，刷新率104Hz。但0.6ms的中断周期在Proteus里可能开始卡，需要权衡。

6.2 显示缓冲区重排与移位函数

16×16点阵，每一行是16个点，也就是2个字节。显示缓冲区要定义成unsigned char dispbuf[32]，前16字节是第一行到第八行的左半边，后16字节是右半边？还是每两字节一行？

这取决于你的送数据方式。如果是“一次送一行的16位”，那缓冲区就是dispbuf[32]，每两个字节组成一行，送的时候先送高字节再送低字节（或者反过来，取决于595的级联顺序）。

滚动字幕的核心是一个移位函数：每隔一段时间，把整个缓冲区的数据整体左移一位（或右移一位），移出去的数据丢掉，空出来的位置补新数据。

void scroll_left(void) { unsigned char i; for (i = 0; i < 32; i++) { dispbuf[i] = (dispbuf[i] << 1) | (dispbuf[i+1] >> 7); } dispbuf[31] <<= 1; dispbuf[31] |= next_column_bit(); }

这段代码是按“每字节代表一列”的排布写的，如果是按行排布，移位逻辑要改成按行处理。移位的方向必须和你的缓冲区排布严格对应，这是滚动字幕最容易出错的地方。我建议先把缓冲区排布画在纸上，标清楚“第0字节到第31字节分别对应哪个位置”，再写移位函数。

6.3 滚动速度与视觉残留

滚动速度由两个参数决定：移位的频率和每次移位的位数。每50ms移一位，看起来是平滑滚动；每200ms移一位，看起来是一跳一跳的。人眼觉得舒服的滚动速度，大约是每秒移动20到40个点。

在代码里，移位不能放在定时器中断里做（会打乱扫描节奏），要放在主循环里，用一个计数器控制移位间隔。主循环里判断“计数到了没有”，到了就调一次scroll_left()，然后清零计数。

这里有个细节：移位和扫描是两个独立的时间尺度。扫描是毫秒级（1ms一行），移位是几十毫秒级（50ms一列）。两者不能混在一个定时器里，否则要么扫描变慢，要么滚动变快。用两个定时器，或者一个定时器加软件计数，都可以。

Proteus里看滚动效果，建议把仿真速度调到中等偏慢，这样能看清每一帧的变化。调太快的话，滚动看起来是连续的，反而不容易发现“某一列重复了”或者“某一列丢了”这种问题。

我个人在点阵仿真这块栽得最深的一次，是花了整整一个晚上排查“为什么只有第一行能亮”。电平探针显示138的八个输出都在动，595的输出也在变，代码逻辑翻来覆去看了好几遍。最后发现是行线接到了点阵的列引脚上——因为那个点阵模型的引脚编号和我参照的那张图完全不一样，我照着图连，连的是另一套编号。从那以后，我画任何点阵原理图，第一件事就是单点测试把引脚顺序记下来，写在注释里。这个习惯看起来笨，但它把“排查一个晚上”变成了“排查十五分钟”。

另外分享一个小技巧：在Proteus里调试点阵，可以先把扫描周期调慢到10ms一行，这样每一行点亮的时间足够长，你能用肉眼看清“当前是哪一行在亮、亮的内容对不对”。等逻辑全对上了，再把周期调回1ms看整体效果。很多人一上来就用1ms，屏幕闪得看不清细节，反而更难定位问题。慢下来看，比快起来猜，效率高得多。