STM32 LTDC驱动RGB屏黑屏：SDRAM刷新与时序带宽排查实战

1. 先把黑屏这件事的范围划清楚上周一位做工业触摸终端的同行发来一段十几秒的视频板子上电背光已经亮起来屏幕是均匀的纯黑没有雪花、没有彩条、也没有闪一下再黑的过程从头到尾就是彻底的黑。他用的方案是 STM32 通过 LTDC 驱动一块 7 寸 RGB 接口屏显存放在外挂的 SDRAM 里。他试过把 LTDC 层的颜色改成红色屏幕没反应又试着把背景色改成绿色屏幕还是黑的。折腾了一整晚最后把 SDRAM 的刷新计数器随手改大了一倍屏幕居然出图了但跑几分钟又开始花。这个案例很有代表性。STM32 LTDC 驱动 RGB 屏黑屏这个现象看起来是显示问题实际根子往往落在 SDRAM 上而且是刷新和时序两件事拧在一起。LTDC 自己不产生图像它只是一个老老实实的搬运工按照像素时钟的节奏从你指定的显存地址里一行一行地读数据塞进 FIFO再推到 RGB 并口上。只要显存那边供不上数据或者供上来的数据本身是坏的屏幕就只有黑屏、花屏两种结局。全黑说明系统的搬运链路根本没跑通花屏说明跑通了但数据在途中被搞坏了。这两种现象指向的排查方向完全不同所以第一步不是急着改代码而是先把黑屏这个模糊的描述拆开。这篇文章面向的是已经能点灯、能跑通 GPIO、手里有 RGB 屏和 SDRAM 硬件但在 LTDC 上卡住的人。如果你连 SDRAM 都还没跑通建议先去把 FMC 的读写测试做扎实再回来。下面我从排查顺序讲起然后深入到 LTDC 与 SDRAM 之间的带宽和时序冲突再把关键参数的计算过程一项项摊开最后给一套我自己反复用过的递进式调试流程和一张现象对照表。文中涉及的具体数值都会说明推导过程你可以直接套到自己的配置里。1.1 三种黑屏必须先区分开很多人把屏幕不亮和黑屏混为一谈这是排查走弯路的第一个原因。我习惯把它分成三类判断方法很简单用肉眼加一个万用表就够了。第一类是完全不亮背光都没开。这种时候你把房间灯关掉从侧面斜着看屏幕如果连一点点微弱的灰白底都看不到那就是背光电路的问题跟 LTDC 一点关系都没有。RGB 屏的背光是独立的 LED 串需要单独的升压或者恒流驱动LTDC 只负责信号。这种情况去查 LTDC 是浪费时间。第二类是背光亮但纯黑也就是那位同行遇到的情况。侧面看能看到均匀的灰白底说明背光正常液晶层没有被驱动出任何图像。这一类的可能性集中在三处LTDC 没有使能、层没有使能、显存读出来全是 0。第三类是背光亮但有噪点或者横纹这类反而是好消息说明 LTDC 已经在扫描了只是数据不稳或者时序不对。区分第二类和第三类的意义在于SDRAM 刷新不足的典型表现是花屏、噪点、图像撕裂而不是纯黑。因为刷新不够时SDRAM 里的电容电荷会缓慢泄漏数据是逐位随机翻转的表现出来就是雪花点和色块闪烁。如果你看到的是干干净净的纯黑刷新计数器通常不是第一嫌疑问题更可能出在 LTDC 的使能链路或者 SDRAM 根本没初始化成功。很多人一上来就怀疑刷新改来改去反而把本来对的参数改乱了。判断小技巧把 LTDC 的背景色寄存器设成一个明显的颜色比如纯红层全部关闭。如果屏幕变成红色说明 LTDC 的时序和使能都通了问题在层和显存如果还是黑的说明 LTDC 根本没在扫描往上查时钟和使能。1.2 为什么刷新和时序要放在一起看SDRAM 是动态存储器靠电容存电荷电荷会漏所以必须周期性刷新。刷新的本质是把整行读出来再写回去这个过程会占用总线。LTDC 读显存也占用总线。两者共用同一个 FMC 控制器和同一片存储颗粒天然存在竞争。更麻烦的是时序。FMC 访问 SDRAM 时行激活、列读写、预充电这些操作之间必须满足最小间隔这些间隔由时序寄存器里的参数决定。参数配得松访问慢但稳配得紧跑得快但容易出错。而 LTDC 是实时流式读取它不像 CPU 那样可以等FIFO 一旦被读空就直接输出错误数据。所以 LTDC 对 SDRAM 的时序余量要求比 CPU 跑读写测试要苛刻得多。我见过太多这样的情况CPU 跑 SDRAM 读写测试几 MB 数据比对全对于是认为 SDRAM 稳了结果一开 LTDC 就黑屏或者花屏。原因是 CPU 测试是突发式的、有间隙的而 LTDC 是持续不断的。两者对稳定的定义根本不是一个量级。所以这两件事必须放在一起调单独调任何一个都可能得出错误结论。1.3 排查顺序从时钟树往上倒推我自己的固定顺序是电源与时钟 → SDRAM 初始化 → SDRAM 读写自检 → LTDC 时序参数 → LTDC 层配置 → 显存地址与缓存 → 刷新与带宽余量。这个顺序是从下往上每一层确认通过再走下一层绝不跳步。之所以从时钟树开始是因为 LTDC 的像素时钟、FMC 的 SDRAM 时钟、CPU 主频之间有固定的倍频分频关系。比如某主流型号的 SDRAM 时钟只能是 HCLK 的二分频或三分频而 LTDC 的像素时钟来自单独的 PLL 分频。如果你改了系统主频去做功耗优化SDRAM 时钟跟着变刷新计数器和时序参数的单位也跟着变原来算好的值全部失效。这种改了一个参数整条链都歪了的情况在实际项目里非常常见尤其是从开发板例程移植到自己板子上的时候。我一般会在调试初期把时钟配置打印出来或者用调试器直接看 RCC 相关寄存器确认三个频率HCLK、SDRAM 实际工作时钟、LTDC 像素时钟。这三个数字写在一张纸上贴在显示器边上后面所有计算都以此为准。这一步花五分钟能省掉后面几小时的怀疑人生。2. LTDC 取数和 SDRAM 刷新的底层冲突要理解为什么黑屏得先搞清楚 LTDC 到底是怎么把数据从 SDRAM 搬到屏幕上的。这个过程不像很多人想的那么智能它非常机械甚至有点笨。你把这一层想通了后面所有的参数配置就都有了依据而不是照着例程抄一堆数字然后祈祷它能跑。2.1 LTDC 是如何一行一行搬数据的LTDC 内部有两个 FIFO分别对应两层。每一行开始的时候它根据层配置里的帧缓冲地址、行长度、行间距算出这一行在显存里的起始地址和字节数然后向 FMC 发起读请求把这一行的数据搬进 FIFO。FIFO 满了就停FIFO 空了就继续搬。同时像素输出端按照像素时钟的节奏从 FIFO 里取数据推出去。关键点在FIFO 空了怎么办。如果 FIFO 被取空LTDC 不会暂停扫描它没法暂停屏幕的时序不能停它只能输出 FIFO 里的残留或者默认值。表现出来就是这一行后半段颜色不对或者整屏错乱。所以 LTDC 能否正常显示本质上取决于FMC 能不能在 FIFO 被读空之前把下一批数据送过来。这就引出一个很重要的概念LTDC 需要的是有保障的带宽而不是平均带宽。平均下来够用没用必须在每一个瞬间都够用。SDRAM 的刷新操作恰恰是那个会周期性打断带宽供给的因素。刷新期间总线被刷新命令占用LTDC 的读请求只能排队。如果排队时间超过了 FIFO 的缓冲深度对应的时长就会下溢。2.2 刷新操作打断突发传输的代价一次刷新操作要占用多长时间可以粗略估算。刷新本质上是激活一行、读出来、写回去、预充电这个过程至少包含一次行激活加一次预充电也就是 tRC 的量级。以常见的 64ms 刷新 8192 行的颗粒为例平均每 7.8 微秒就要刷新一次。如果 tRC 是 60 纳秒那么刷新占用的时间比例大约是 60ns / 7.8us不到百分之一。听起来微不足道对吧问题在于它是突发占用不是均匀分摊。刷新命令一旦发出接下来几十纳秒内总线都不可用。而 LTDC 的 FIFO 深度是有限的通常只能缓冲几十到一百多个像素的数据。假设 FIFO 深度是 64 个像素像素时钟 50MHz那么 64 个像素只够撑 1.28 微秒。刷新占用 60 纳秒看起来还有余地。但实际情况要糟得多。因为刷新往往和 CPU 的访问、DMA2D 的访问撞在一起。三个主设备同时抢总线仲裁器一排队实际阻塞时间可能是单个刷新操作的好几倍。这时候 FIFO 就见底了。我在实际项目里遇到过最极端的场景CPU 在中断里往显存刷一小块区域正好和刷新、LTDC 读数三者撞上屏幕上出现一条固定的横线位置每次都一样。查了很久才定位到是总线竞争导致的瞬时下溢。2.3 带宽账必须提前算清楚与其等到出问题再猜不如一开始就把带宽算出来。这个账不难算但很多人从来没算过直接抄了例程的参数就上分辨率一提高就出问题。先说 LTDC 这边的需求。以 1024×600 分辨率、RGB565每像素 2 字节、60Hz 刷新率为例每秒需要搬运的字节数是1024 × 600 × 2 × 60 73,728,000 字节约 73.7 MB/s。这只是有效像素的部分不考虑消隐期。实际上 LTDC 在消隐期不读数据所以真实占用就是 73.7 MB/s。再说 SDRAM 能提供多少。16 位数据总线、时钟 90MHz 的情况下理论峰值带宽是 16 ÷ 8 × 90M 180 MB/s。看起来有 2.4 倍余量很安全。但这个 180 MB/s 是理论值实际可用带宽要打折扣。第一SDRAM 的读写切换、行激活、预充电都有开销连续突发读写时效率大概在 70% 到 85% 之间第二刷新要占掉一部分第三CPU 和 DMA2D 还要用。按 75% 效率算实际可用约 135 MB/s扣掉 LTDC 的 73.7 MB/s还剩 61 MB/s 给其他主设备勉强够用。如果分辨率提到 1280×800需求变成 1280 × 800 × 2 × 60 122.9 MB/s余量就非常紧张了。这时候如果再叠加 DMA2D 做图层混合很容易崩。而很多人出问题的根因就在这里——分辨率一提高SDRAM 的时钟却没跟着提或者刷新参数没重算带宽直接不够表现为黑屏FIFO 持续下溢导致整帧无效或者严重花屏。提醒一点如果你用的是 RGB888每像素 3 字节实际存储常按 4 字节对齐带宽需求直接翻倍甚至更多。选像素格式的时候一定要把带宽算进去别只看显存占用。3. 参数计算把数字算出来再写代码这一节是全篇最硬的部分。我不打算直接给一堆数字让你抄因为每块板子的时钟、每颗颗粒的参数都不一样抄错了比不抄更糟。我给出的是每个参数的推导方法你代入自己的值就能算出正确结果。3.1 像素时钟与 FMC 时钟的配比像素时钟决定了 LTDC 往外推数据的速度它由屏幕的时序参数决定。计算公式是像素时钟 (水平总周期) × (垂直总周期) × 刷新率。水平总周期 有效宽度 HSW HBP HFP垂直总周期 有效高度 VSW VBP VFP。这些参数必须从屏幕的数据手册里拿不能猜。以一块常见的 7 寸 1024×600 屏为例手册给的 HSW20、HBP140、HFP160、VSW3、VBP20、VFP12。那么水平总周期 102420140160 1344垂直总周期 60032012 635。60Hz 下像素时钟 1344 × 635 × 60 ≈ 51.2 MHz。LTDC 的像素时钟来自 PLL 的某个分频输出。你要做的是找一个分频组合让输出尽量接近 51.2 MHz宁可略低不要略高。略高会导致刷新率超标有些屏会黑屏保护略低只是刷新率略降人眼看不出来。比如 PLL 输出 204.8 MHz四分频得 51.2 MHz正好。如果找不到整数分频可以用 5 分频得 40.96 MHz也能点亮只是刷新率降到 48Hz 左右。这里有个容易忽略的点像素时钟不能随便改成差不多就行。屏幕内部的时序控制是靠像素时钟同步的偏差太大会导致同步信号位置漂移表现为图像整体偏移、边缘有黑边严重的直接黑屏。所以这个值必须按公式算。3.2 刷新计数器到底填多少这是最容易出错的一项。FMC 的刷新计数器是一个递减计数器减到零就发一次刷新命令。要填的值由刷新周期、行数、SDRAM 时钟共同决定。公式是计数值 (刷新周期 ÷ 行数) × SDRAM 时钟频率 − 安全余量。举具体例子。颗粒手册标称 64ms 刷新 8192 行那么每行的刷新间隔是 64ms ÷ 8192 7.8125 微秒。SDRAM 时钟 90MHz周期 11.11 纳秒。7.8125 微秒 ÷ 11.11 纳秒 703.1取整 703。减去安全余量 20得 683。这个 20 是业界习惯做法用来补偿计数启动、总线仲裁带来的延迟。如果填 0 会怎样有些实现里填 0 表示禁用有些表示每个时钟都刷新。前者会导致数据缓慢丢失后者会占满总线两者都是灾难。我见过一个案例初始化结构体里刷新计数字段忘了赋值默认 0结果就是开机图像正常大约十几秒后开始出现零星白点然后越来越多最后整屏花掉。这种延迟发作的故障最难查因为第一反应总是怀疑接线或者屏坏了。反过来把计数值填得过大比如 2000也不对。刷新频率不够同样会丢数据只是丢得慢一些。所以这个数字必须老老实实算。还有一个连带影响如果你改动了系统主频SDRAM 时钟跟着变这个计数值必须重算。从 90MHz 改到 84MHz同样的 7.8125 微秒对应的计数值变成 656-20636。差值 47看起来不大但已经足够让刷新变得不够及时。这是我强调把三个频率写在纸上的原因。3.3 FMC 时序参数逐项推导SDRAM 的时序参数有好几个每个都对应颗粒手册里的一个时间指标单位要换算成 SDRAM 时钟周期数并向上取整。我用一块典型的 16 位、64Mbit 颗粒举例它的手册参数大概是tRCD18ns、tRP18ns、tRAS42ns、tRC60ns、tMRD2tCK、tXSR70ns、tWR12ns。SDRAM 时钟 90MHz周期 11.11ns。换算结果tRCD 需要 18/11.111.62向上取整为 2tRP 同样为 2tRAS 需要 42/11.113.78取 4tRC 需要 60/11.115.4取 6注意 tRC 必须大于等于 tRAStRP426正好吻合tMRD 手册直接给 2 个时钟填 2tXSR 需要 70/11.116.3取 7这里要多留一个因为退出自刷新后还有额外延迟tWR 需要 12/11.111.08取 2。这几个值填进时序寄存器之后还要注意两个隐藏项。一个是读管道延迟当 HCLK 超过某个阈值通常是 120MHz时必须设置读数据的管道延迟否则读回来的数据会错位。这个参数在寄存器手册里往往只有一行说明很容易漏掉而它的症状恰恰是写进去的和读出来的不一样让人误以为是 SDRAM 坏了。另一个是写保护时间有些颗粒在写完最后一个数据后需要额外等待才能预充电参数没设够会导致偶发写入失败。3.4 显存地址、对齐与缓存配置显存地址这一项坑主要在三个地方。第一个是地址必须落在 SDRAM 的映射区间内而且要对齐。LTDC 的帧缓冲地址寄存器对低几位有要求具体看型号常见的是要求 8 字节或者 32 字节对齐。如果你的数组定义没有加对齐属性编译器可能把它放在任意位置导致 LTDC 读到的地址偏移了几个字节表现出来就是图像整体错位或者前半行正常后半行花。第二个是行长和行间距寄存器的3。这两个寄存器填的不是直接的字节数而是字节数减一……不对是字节数加上 3。这个设计非常反直觉我第一次看手册的时候反复确认了三遍。假设一行是 1024 个像素、RGB565那么一行是 2048 字节寄存器里要填 204832051。行间距pitch同理。如果这里填错每一行的起点就全歪了屏幕会出现斜条纹或者重影。第三个也是最隐蔽的是缓存一致性。如果你的芯片带 D-Cache比如 Cortex-M7 内核的型号CPU 写显存的时候数据先进 Cache不一定会立刻写回 SDRAM。而 LTDC 是直接读 SDRAM 的物理地址它看不到 Cache 里的新数据。结果就是 CPU 明明改了显存屏幕却纹丝不动或者显示的是几帧之前的旧内容。这个问题在调试时特别迷惑因为你在调试器里看内存是对的调试器读内存也会走 Cache 或者强制同步但屏幕就是不对。解决办法有两个把 SDRAM 区域配置成非缓存或者写通模式或者在每次更新显存后手动清理 Cache。前者的性能损失可以接受后者更灵活但需要记得在每个更新点都调用。我个人的习惯是显示缓冲区统一配置成写通模式简单粗暴省得后面忘了清理。4. 实操调试从纯色到图片的递进验证前面讲的是原理和计算这一节讲怎么落地。我调试这类问题从来不追求一次点亮而是设计一条递进的验证路径每一步只引入一个新变量。这样一旦出问题责任范围非常明确。4.1 第一步绕开 SDRAM用内部 SRAM 点亮色块这是我最推荐的第一步也是最容易被跳过的一步。很多人的第一反应是我的显存必须放 SDRAM因为内部 SRAM 不够大。但验证 LTDC 本身是否工作根本不需要一整帧。小分辨率可以用内部 SRAM 试。比如先用 320×240、RGB565一帧只需要 153,600 字节大多数型号的内部 SRAM 放得下。把帧缓冲地址指向内部 SRAM填一个纯色打开层和 LTDC看屏幕有没有颜色。这一步能验证的东西很多像素时钟对不对、同步信号的极性对不对、HSW/HBP/HFP 这些参数对不对、层的使能顺序对不对。如果这一步都点不亮那问题完全在 LTDC 配置或者硬件连接上跟 SDRAM 无关别再去折腾刷新计数器了。判断极性有个笨办法但很好用如果屏幕上有图像但整体偏移、左边或右边有黑边、或者图像上下滚动就是同步极性或者消隐参数不对。如果屏幕完全没反应先查 DE 模式还是 SYNC 模式选错了没有——有些屏只认 DE 模式你按 SYNC 模式配就是不出图。4.2 第二步把显存搬到 SDRAM先验证静态显示LTDC 本身跑通之后把帧缓冲地址改到 SDRAM其他配置不动仍然是纯色显示。这一步如果黑屏问题就锁定在 SDRAM 上。这时候不要急着改 LTDC 的参数先做 SDRAM 自检。写一段代码往整片 SDRAM 写测试图案读回来比对。图案要用两种0x5555 和 0xAAAA还有 0x0000 和 0xFFFF。为什么要用两种互补的因为地址线或者数据线短路、虚焊的时候单一图案可能凑巧通过互补图案能查出来。自检通过之后再看屏幕。如果自检通过但屏幕还是黑那基本可以确定是 LTDC 的读带宽或者缓存问题。可以先把 Cache 关掉试试如果关掉就正常了那就是缓存一致性问题。4.3 第三步逐步加压到目标分辨率纯色能显示之后别急着上图片先上渐变或者棋盘格。棋盘格能暴露行间距配置错误渐变能暴露带宽不足。我的加压顺序是先固定分辨率不变把刷新率从 30Hz 提到 60Hz看是否稳定然后固定刷新率把分辨率从 640×480 提到 800×480再到 1024×600。每提一档观察几分钟看有没有偶发噪点或者横线。横线是最典型的带宽不足信号。如果横线的位置固定不变说明是某一行的读取总是被某个周期性事件打断通常是刷新或者某个定时器中断里的内存访问如果横线位置随机跳动说明是总线竞争导致的随机下溢。4.4 第四步双缓冲与 DMA2D 的配合到了产品阶段基本都会用双缓冲加 DMA2D 做界面。这两者和 LTDC 抢总线的程度比单缓冲高得多必须重新评估带宽。双缓冲的做法是准备两块帧缓冲LTDC 读 A 的时候 CPU 或 DMA2D 写 B写完后在垂直消隐期间切换 LTDC 的地址寄存器这样不会出现撕裂。切换的时机很关键不能随时切必须在消隐期切。大多数型号的 LTDC 提供了垂直消隐中断或者重载机制用那个。DMA2D 做填充和混合的时候是连续的大块读写对总线的冲击比 CPU 零散访问大得多。我的经验是给 DMA2D 的访问让出优先级或者把它的操作拆成小块中间留出空隙给 LTDC。如果 DMA2D 一次搬一整个屏幕很可能会让 LTDC 在那一段时间里持续下溢。可以开 LTDC 的下溢中断一旦触发就说明带宽被抢得太狠了这时候要么降 DMA2D 的优先级要么把它的任务拆细。5. 现场问题速查与避坑清单调试到这一步大部分情况都能定位了。下面这张表是我这些年攒下来的现象对照遇到问题时先扫一眼能省掉不少时间。5.1 常见现象与对应原因速查现象最可能的原因快速验证方法背光不亮侧面看无灰底背光电路未工作测背光升压输出背光亮全屏纯黑改背景色无效LTDC 未使能或像素时钟缺失查 LTDC 使能位与 PLL 分频背光亮全屏纯黑改背景色有效层未使能或显存地址错误查层使能位与帧缓冲地址开机正常数秒后出现白点并增多刷新计数值过小或未使能重算刷新计数器固定位置的横线周期性总线竞争导致 FIFO 下溢开下溢中断调整优先级随机跳动的横线或噪点SDRAM 时序余量不足加大各时序参数观察是否改善图像整体偏移边缘黑边消隐参数或同步极性错误对照屏幕手册逐项核对图像斜条纹或重影行长/行间距寄存器填错检查是否漏了加 3CPU 改了显存但屏幕不变Cache 未清理一致性失效关 Cache 或配置写通模式高低温下表现不同时序余量不足或刷新不够按最坏温度重新计算余量5.2 几个反直觉的坑第一个坑SDRAM 读写测试全过不代表 LTDC 能用。前面说过CPU 测试是突发有间隙的LTDC 是持续流式的。我现在的做法是SDRAM 自检通过之后还要再加一项长时间连续读测试用一个定时器不停地读同一块区域读几个小时不出错才算过关。第二个坑时序参数全都满足手册最小值仍然可能不稳。手册给的是典型条件下的最小值实际 PCB 的走线长度、阻抗、负载都会影响信号质量。尤其是 SDRAM 的时钟线如果走得不理想采样点会偏移。我的做法是在最小值的基础上普遍加一到两个周期作为余量代价是性能略降但稳定性提升明显。如果需要压性能再一点点往下减减到出问题为止然后回退一档。第三个坑刷新计数器不是越大越安全。有人为了保险把刷新频率提高到远超手册要求结果总线被刷新占满LTDC 反而没数据可读。刷新只要满足手册要求就行多加一点余量可以翻倍就过头了。第四个坑改了主频忘了改其他。系统主频一动SDRAM 时钟、刷新计数、时序参数、像素时钟全都要跟着重算。我见过有人为了省电把主频降低结果屏幕开始闪查了两天才发现是刷新计数器没跟着改。5.3 上电顺序与初始化细节SDRAM 的初始化序列对时序很敏感尤其是上电后的等待时间。手册通常要求上电后至少等待 100 微秒有些颗粒要 200 微秒再发第一条命令这段时间是让电源稳定、内部电路复位。如果等待时间不够初始化命令可能被忽略SDRAM 就处于未定义状态后续所有读写都不可靠。初始化序列一般是延时 → 预充电所有 bank → 至少 8 次自动刷新 → 加载模式寄存器 → 配置刷新计数器 → 正常读写。这中间的每一步之间都要有足够的间隔不是写完就能立刻发下一条。模式寄存器里要配置突发长度、CAS 延迟、突发类型、写模式这些参数和时序参数要匹配比如 CAS 延迟设成 3那时序里对应的读延迟也要按 3 来算。还有一个细节模式寄存器的写入要用特定的 bank 地址和命令组合写错了会被当成普通写操作SDRAM 的模式根本没变。这个在寄存器手册里写得很清楚但代码里如果用的是封装好的库函数有时候看不出来出问题时可以抓一下总线波形确认。最后提醒一句调试 LTDC 和 SDRAM 的时候示波器或者逻辑分析仪的价值远大于调试器。时序类的问题看波形十分钟能定位看代码可能要看一天。如果条件允许把像素时钟、HSYNC、VSYNC、DE 和 SDRAM 的时钟、片选、读写信号都引出来出问题时先看波形对不对再回头改代码。我个人在实际项目里的体会是这类黑屏问题九成以上不是某一个参数写错而是几个环节的余量同时被吃掉。比如时序参数按最小值配、刷新计数器按理论值算、分辨率又卡在带宽边缘单独看每一项都刚好够叠加起来就崩了。所以我的习惯是每个参数都留一档余量宁可性能打个八折也要保证现场跑几个月不出问题。毕竟客户不会关心你的带宽利用率有多高他们只关心屏幕会不会在关键时刻黑掉。