zoukankan      html  css  js  c++  java
  • LCD显示异常分析——开机闪现花屏【转】

    转自LCD显示异常分析——开机闪现花屏

    最近在工作中,有同事遇到LCD开机瞬间会闪现雪花屏的问题,而这类问题都有个共同点,那就是都发生在带GRAM的屏上,同样的问题,在休眠唤醒时也会出现。

    其实这类问题的原理分析并不难,只是在给别人解释的时候不太好描述,因此,我特地写了这篇文章,好让大家能够更容易、更直观的理解这类花屏问题的原因,也希望能够帮助那些遇到同样问题的朋友。

    环境

    • 软件:Android
    • 硬件:带GRAM的LCD(如SPI屏,DSI CMD屏)

    现象

    image

    分析

    从上面的动态图可以看出,出现瞬间花屏的问题,主要有两个原因:

    1. 背光开启的时间过早
    2. 对GRAM的写速度(W) < 对GRAM的读速度(R)

    其实,只要任意解决其中一个问题,都不会出现开机闪现花屏的现象。开发人员第一次碰到这类问题时,往往第一反应会认为花屏就是在第一帧产生的,但实际从上面的图中我们可以看到,人眼看到的花屏其实已经是在第二帧了。

    对于第一点,其实一开始我也很疑惑,如果说开机闪现花屏是因为uboot中背光开的太早导致,这个结论我能接受。但在进入Android系统后,休眠唤醒时还会有花屏问题,这就有点说不通啊?因为Android的PowerManager框架本身能够确保在休眠的时候先关背光,后关显示;在唤醒的时候先开显示,后开背光,而且我显示驱动里面也做了刷背景色的动作,只要GRAM中的数据没有被填充完,显示驱动的流程就不会接着往下走,进而也不可能开启背光。所以一旦背光点亮,说明GRAM已经被初始化了,可为什么还能看见GRAM中的垃圾数据呢?

    这就引出了第二点:因为对GRAM 写的速度小于读的速度,哪怕W只比R小那么一丁点儿,只要它们同时从第一颗像素开始扫描,屏上显示的第一帧永远都是垃圾数据。

    解决方法

    前面已经提到过了,只要任意解决其中一个问题,闪花屏的问题就能解决。

    1. 推迟背光开启的时间

    这里的推迟动作其实是相对的,即你可以:

    1. 在初始化完GRAM后,等待1个TE信号,再开启背光
    2. 或者在给屏幕发送Sleep Out (0x11)、Display On (0x29)指令前,先通过Write Memory Start (0x2C)指令将GRAM初始化好

    亲测第一种方法简单粗暴;

    2. 提高GRAM的写速度

    即提高主控端总线上的送图速度,比如提高SPI总线的时钟频率(SPI屏),提高RS/WR的切换速率或扩充DATA总线(MCU屏),提高PHY Clock Frequency (MIPI DSI屏)。

  • 相关阅读:
    15. DML, DDL, LOGON 触发器
    5. 跟踪标记 (Trace Flag) 834, 845 对内存页行为的影响
    4. 跟踪标记 (Trace Flag) 610 对索引组织表(IOT)最小化日志
    14. 类似正则表达式的字符处理问题
    01. SELECT显示和PRINT打印超长的字符
    3. 跟踪标记 (Trace Flag) 1204, 1222 抓取死锁信息
    2. 跟踪标记 (Trace Flag) 3604, 3605 输出DBCC命令结果
    1. 跟踪标记 (Trace Flag) 1117, 1118 文件增长及空间分配方式
    0. 跟踪标记 (Trace Flag) 简介
    SpringBoot + Redis + Shiro 实现权限管理(转)
  • 原文地址:https://www.cnblogs.com/linhaostudy/p/9579829.html
Copyright © 2011-2022 走看看