Liquid Crystal Display Controller (LCDC)

Overall Description

Introduction

The LCD-TFT (Liquid Crystal Display-Thin Film Transistor) display controller provide RGB, MCU, MIPI-DSI interfaces with TE signal processing module and a pixel convertor.

Feature

Feature List:

  • 支持以下interface

    • RGB interface

    • MCU interface

    • MIPI-DSI interface

  • 支持最高达854*480 60fps或者1280*720 30fps的分辨率

  • 支持DMA auto/trigger mode

  • 有一个像素转换模块，功能包括

    • 支持多种像素格式输入

    • 支持多种像素格式输出

    • 支持byte swap

  • MCU接口支持IO mode和预设cmd

  • MIPI-DSI支持

    • 1/2/3/4 data lane

    • video mode和cmd mode

Feature 对比

feature

bee4

amebad

ameba smart

7005

Interface

  1. RGB:

  2. MCU

  3. MIPI-DSI (1/2 lane): video & cmd mode

  4. 4线SPI;

  5. SDR/DDR的 QSPI (114,144) / OPI (118,188)

  6. ramless QSPI (only for 矽创)

  1. RGB

  2. MCU

  1. MIPI-DSI: video&cmd mode

  1. RGB;

  2. MCU;

  3. MIPI-DSI (1/2/3/4 lane): video & cmd mode

目标规格

  1. RGB/MIPI-DSI 1080*768 @60fps

其他接口没有预期，可根据clock算出

  1. MCU: 8bit 645*645 @30fps

16bit 912*912 @30fps

  1. RGB: 6bit 527*527 @60fps

16bit 912*912 @60fps

  1. MIPI-DSI: 800*480 @60fps

  1. RGB/MIPI-DSI:

854*480 @60fps

1280*720 @30fps

  1. MCU

IP Clock

200Mhz，可调

100MHz

NPLL/n

APB clock: 100M

AXI master bus clock: 200M panel source clock: 400M/div

I/F Clock

RGB: 最高65Mhz

MIPI-DSI: 1Ghz

MCU: 最高50M

4线SPI/QSPI/ramless QSPI: 最高50M

RGB:最高50Mhz

MCU:最高25Mhz

MIPI-DSI: ?-1Ghz

RGB/MCU: 最大50M

MIPI-DSI: 80M-1G

output format

  1. RGB: 24bit-RGB888, 16bit-RGB565

  2. MCU: 8bit-RGB565, 8bit-RGB888

  3. MIPI-DSI: HS, LP。24bit-RGB888或者16bit-RGB565内部给到DSI

  4. 4线SPI QSPI/OPI/ ramlessQSPI: RGB565, RGB888

  1. RGB: 6bit-RG565, 16bit-RGB565

  2. MCU: 8bit-RGB565, 16bit- RGB565

  1. MIPI-DSI: HS, LP。24bit-RGB888内部给到DSI

  1. RGB:

24bit-RGB888,

8bit-RGB888,

16bit-RGB565,

6bit-RGB565

  1. MCU:

8bit-RGB565,

8bit-RGB888,

16bit-RGB565,

24bit-RGB888

  1. MIPI-DSI: HS, LP。24bit-RGB888内部给到DSI

input format

ARGB8888

BGR565

RGB565

RGB888

ABGR8888

RGB565

ARGB8888

RGB888

RGB565

ARGB1555

ARGB4444

RGB666

ARGB8666

RGB888

BGR888

RGB565

BGR565

ABGR8888

ARGB8888

ARGB1555

ARGB4444

RGB666

ARGB8666

DMA

内置完整可配的RTK-DMA

内置DMA

内置DMA

内置DMA

Linklist module

HW产生特定的linklist item

-

-

HW产生特定的linklist item

FIFO

128*32bit

256*32bit

3 x 256 x 32 bits

和LCDC line buffer size 一样

像素处理

  1. swap

  2. Pixel convert

-

有PPE，有如下功能

  1. 3 layer alpha blending function

  2. color keying

  3. Programmable window position and size

  4. Programmable background-color

  5. Pixel convert

  1. swap

  2. Pixel convert

TE

带有TE module，处理来自TE pin和MIPI-DSI的TE message。可以触发中断以及auto mode。

仅MCU接口有TE pin。

不支持TE信号

带有TE module，处理来自TE pin。可以触发中断。

传输模式

  1. auto mode: 适用于RGB/MCU/MIPI-DSI/ramlessQSPI

  2. trigger mode: 通过dma single mode实现单次传输。可以cpu或者TE触发。适用于所有接口。

  3. IO mode: 适用于4线SPI，QSPI，MCU接口

  1. auto mode：适用于RGB接口

  2. trigger mode：cpu或者TE触发。适用于MCU接口

  3. IO mode：适用于MCU接口

  1. auto mode:对应video mode

  2. io mode: 对应cmd mode

  1. auto mode: 适用于RGB/MCU/MIPI-DSI

  2. trigger mode: 通过dma single mode实现单次传输。可以cpu或者TE触发。适用于所有接口。

  3. IO mode: 适用于MCU接口

Line buffer

672*32bit

-

DSI里有但是没有valid信号，不能用于underflow

DSI: 1080*24bit LCDC: 1024*32bit

帧间delay控制

所有传输模式可控

MCU接口下TE mode可控

-

可控

auto mode更换source addr

可控

-

可控

可控

其他feature

  1. MCU接口可以预设cmd，可以实现auto mode

  2. RESET信号(与GPIO无本质区别)

  3. RGB带SD/CM pin。实际无应用。

MCU接口带有vsync-out pin，无应用

MCU接口可以预设cmd，可以实现auto mode

Architecture

架构如下，主要包括DMA，像素转换，寄存器，接口等domain

../../_images/lcdc_arch.svg

Function Description

Interface

Pinmux

PinNum

MCU

RGB

MIPI-DSI

1

D23

D23

-

2

D22

D22

-

3

D21

D21

-

4

D20

D20

-

5

D19

D19

-

6

D18

D18

-

7

D17

D17

-

8

D16

D16

-

9

D15

D15

-

10

D14

D14

-

11

D13

D13

-

12

D12

D12

-

13

D11

D11

-

14

D10

D10

-

15

D9

D9

-

16

D8

D8

-

17

D7

D7

-

18

D6

D6

-

19

D5

D5

-

20

D4

D4

-

21

D3

D3

-

22

D2

D2

-

23

D1

D1

-

24

D0

D0

-

25

TE/ VSYNC

TE

TE

26

RS

VSYNC

-

27

RD

HSYNC

-

28

WR

DCLK

-

29

CS

DE

-

30

RESET

RESET

RESET

31

CLKP

32

CLKN

33

DQ0P

34

DQ0N

35

DQ1P

36

DQ1N

RESET用GPIO实现即可。

DPI接口的cm/sd，实际应用中没有相关IC、屏幕，忽略。另外，DPI协议RGB接口是没有TE pin的，但部分RGB屏也有TE信号接口，询问厂商说一般是为了通过这个测试帧率，RGB接口的TE信号也加上好了。

MIPI-DSI spec是没有TE pin的，而是通过tear effect message来实现。但是DSI的PHY没有从外围设备到主机处理器的固有中断能力，因此主机处理器应依赖轮询，或者应将总线所有权授予外围设备很长一段时间，因为它不知道外围设备何时发送TE消息。所以这种方法存在限制。实际上很多MIPI屏都有TE pin，这样设备可以通过TE pin告知主机TE信号，因此TE pin是有必要的。

MCU interface

MCU i/f的具体需求

接口和时序

MCU接口定义如下：

../../_images/mcu_interface.svg
TE和Vsync

TE和Vysnc用于帧同步。参见 AmebaD。

  • TE信号由LCD输入，详见 TE module 章节。

  • Vysnc由LCDC在每次要发送一帧数据前输出，在这种模式下，LCDC控制帧的同步。在这种模式下，LCD显示操作与LCDC VSYNC输出同步，帧速率由VSYNC信号的脉冲速率决定。似乎适用于ramless MCU屏，没有见到过这种屏幕。

Format

MCU支持8bit，16bit，24bit接口。

type

source

8bit RGB888
../../_images/mcu_interface_format_8bit_rgb888.png

8bit RGB565
../../_images/mcu_interface_format_8bit_rgb565.png

16bit RGB565
../../_images/mcu_interface_format_16bit_rgb565.png

24bit RGB888
../../_images/mcu_interface_format_24bit_rgb888.png

ILI系列MCU接口支持

width

ILI

ST

乐鑫

standard spec

bee4

amebad

7005

8bit

RGB565, RGB666, RGB888

RGB565, RGB666

RGB332,RGB444, RGB565, RGB666, RGB888

RGB565，RGB888

RGB565

RGB565，RGB888

9bit

RGB565, RGB666, RGB888

RGB565, RGB666

RGB666

-

-

16bit

RGB565, RGB666, RGB888

RGB565, RGB666

RGB332,RGB444, RGB565, RGB666, RGB888

-

RGB565

RGB565

18bit

RGB565, RGB666, RGB888

RGB565, RGB666

-

-

-

24bit

RGB888

-

-

-

RGB888

bee4 认为MCU屏是介于qspi和rgb之间的尺寸/TP，而且他们认为虽然有这样的芯片，但没有厂商会把MCU屏幕做成16bit的。实际上是有的，amebad验证的时候就用过。

RGB interface

接口和时序
../../_images/rgb_interface.svg
format

Input format

Output format

6bit
../../_images/rgb_interface_format_6bit.png

8bit
../../_images/rgb_interface_format_8bit.png

16bit
../../_images/rgb_interface_format_16bit.png

24bit
../../_images/rgb_interface_format_24bit.png

厂商和标准spec的定义

width

ILI

ST

乐鑫

standard spec

Bee 4

amebad

7005

6bit

-

RGB565, RGB666

-

-

RGB565

RGB565

8bit

-

RGB888

RGB888

-

-

-

RGB888

16bit

RGB565

RGB565

RGB565

RGB565

RGB565

RGB565

RGB565

18bit

RGB666

RGB666

RGB666

-

-

-

24bit

RGB888

RGB888

RGB888

RGB888

-

RGB888

Bee4上的sd和cm pin，实际上他们也没有找到带有这些pin的相关屏幕，因此不需要这些pin。他们不支持sRGB的原因是需要3被的clock size。

MIPI-DSI

协议支持RGB888和RGB565。支持cmd mode和video mode。

clock信息 （@李晨曦）

不支持RGB666

不考虑支持RGB666，原因是

  1. 这类屏幕相对较少，需要更多色彩就用RGB888，更少就用RGB565

  2. 如果有这类屏幕，可以用RGB888 LCDC低2位接地，或者RGB565在LCD端RB低1bit接地来workaround。

  3. RGB666每个像素需要的内存不是整数byte，实际内存依然会占用3byte，那么理论上，用RGB888 workaround是没有任何区别。

PAD clock

pad clock即output clock，最高为50M (@黄威)。

IP Clock

最终决定访问寄存器的 APB clock为100M，AXI master访问bus的clock为200M，给到外部显示用的的vo clock为400M的分频@周应栋。从以下几个角度考虑可行性：

  1. 能否覆盖常见的分辨率的fps要求。

  2. 考虑对bus/psram的performance要求。200M clock应该够了@张国峰@郑杰。

  3. 400M的vo clock，可以满足@黄威提的timing要求 @周应栋。

由于pad clock最高50M，因此最低也要8分频。

对于问题2，以800*480，输入为ARGB888格式，刷新率60，则TP=800*480*4*60=92,160,000 B/s。如果是1280*720，乘以2.4倍即可。须综合整个应用来考虑bus performance。

对于问题1，从下面几个角度考虑

  1. 从interface端考虑

    分辨率太多，考虑以下常见分辨率（不考虑vbp之类的）。以400Mhz算，得到最接近60Hz但不超过70hz的（刷新率，divider)。86盒常见分辨率为320*320, 480*480（最常见），720*720。低于50 fps的数据已被标记。考虑到vbp等参数，实际上fps应当比计算值低一点。考虑到pad clock的限制，分频系数最小为8。

    由于mcu接口不必care fps，而只有mcu接口有2clock/pixel的情况，因此只需要考虑1clock/pixel和3clock/pixel的情况。

    常见分辨率

    1 clock/pixel （fps, div）

    3 clock/pixel（fps, div）

    320*240 (4:3)

    (60, 87)

    (60, 29)

    320*320 (1:1)

    (60, 65)

    (59, 22)

    480*272 (16:9)

    (60, 51)

    (60, 17)

    480*320 (3:2)

    (59, 44)

    (62, 14)

    480*360 (4:3)

    (59, 39)

    (59, 13)

    480*480 (1:1)

    (60, 29)

    (58, 10)

    640*360 (16:9)

    (60, 29)

    (58, 10)

    640*480 (4:3)

    (59, 22)

    (54, 8)

    800*480 (5:3)

    (61, 17)

    (44, 8)

    720*720 (1:1)

    (59, 13)

    (32, 8)

    854*480 (16:9)

    (61, 16)

    (41, 8)

    1024*768 (4:3)

    (63, 8)

    (21, 8)

    1280*720 (16:9)

    (54, 8)

    (18, 8)

  2. 考虑精确fps的情况

BT对此的做法是，采用单独的PLL，可以调频到需要频率的整数倍。比如它将PLL调整到23.04*8=184.32Mhz，保证fps=60。

BT表示最后证明是伪需求，因此不考虑这种需求。

DMA

Bee4采用完整的DMA，mode包括这些。

DMA mode

应用

single block

带ram的屏幕，只在需要的时候传一帧

multi-block (contiguous)

无应用

multi-block (auto reload)

auto mode，不停从一块buffer取数据

multi-block ( linklist)

采用了hw linklist module（因为ram紧缺，另外hw也更易用，不需要中断里重新配置）

  1. 裁剪图片，比如显示规格为400*400，图片大小为500*500，可以用linklist裁剪

  2. 从不同地方加载部分图片（实际没有用）

  3. ram紧缺，只能有两个1/10 frame buffer，左右各取5次形成一个完整帧。

  4. 更换source address，这是auto mode下改address的唯一方式。下一版会修正。

hw linklist的功能如下。一帧内，可以选择在两个地方按照一定的间隔取数据，

../../_images/dma_hw_linklist.png

smart lcdc带有功能4, 第1点和第2点可以用PPE实现，PSRAM足够大不存在第3点问题。因此DMA不需要linklist item功能。

DMA可以从PSRAM和SRAM搬运数据到LCDC

是否考虑直接从flash取数据？

传输模式

DMA Auto mode

auto mode是刷完一帧后自动开启刷第二帧的模式，一般是针对需要一直刷屏的应用。

DMA auto mode适用于RGB，MCU，VO I/F。

lvgl如果使用双缓冲区方案，需要提供vsync中断以及可以改变source address。

../../_images/dma_auto_mode.png

RTK DMAC做不到auto mode下更新。Bee4增加了一个Linklist module来实现这一点。

Smart LCDC已经有这个功能了。修改 address后 trigger reload bit。

DMA TE trigger mode

和DMA atuo mode类似，唯一的区别是，不再是自动传输下一帧，而是当TE信号来时，触发下一帧传输。

DMA CPU Trigger mode

Trigger mode下，每次通过cpu写寄存器控制启动DMA传输。

MCU IO mode

MCU IO mode即通过cpu直接往Tx FIFO写数据的方式来传输数据。

MCU I/F下预设cmd

对于MCU I/F（包括DMA auto/trigger mode），它发送数据前，需要发送写屏的位置和窗口得大小，以及write memory的命令（有的还有addr），然后才能发送数据，且每次发完，要重新发送write memory的命令。

/* Set cursor */

/* Write memory */
mcu_write_reg(MCU_CMD_WMEM);

写一屏像素数据

mcu_write_reg(MCU_CMD_WMEM);

写一屏像素数据

因此预设cmd，即每次启动传输先发送预设的cmd，然后再发数据。

因此参考BT，增加4个寄存器，可以存32个cmd。

line buffer/FIFO

当前规格：MIPI DSI内部按照1080*4byte的line开，lcdc按照1024*4byte的开。另外，要求提高lcdc dma总线仲裁的优先级。

line buffer size需要DD评估计算，如果大于上述规格，请提出。

RGB interface直接驱动RGB屏幕，需要RGB interface发出稳定的数据流。考虑到frame buffer较大，一般存放在DRAM中，如果总线较为繁忙，LCDC DMA master可能不能及时获取AXI bus控制权，导致数据流短时中断，破坏RGB接口原有时序。

为了缓解underflow，需要一个line buffer预先存好一行的像素数据。典型的支援屏幕的大小为854*480。line buffer的大小为854*32bit-256*32bit=598*32bit。注意，只能缓解underflow，如果LCDC无法获取bus的时间过久，依然会underflow。

Bee4采用line buffer的另外一个原因是，最开始启动传输的时候，如果interface和dma同时启动传输，dma会更慢一点，这样interface那里会出问题。因此在增加一个可控的threshold，启动传输后，只有大于此阈值才会开始往interface那里传数据。

TE module

TE信号可以是以下两个来源，需要评估能否支持。结论是2不需要支持。

  1. TE pin的信号，仅支持V-blanking mode

  2. MIPI-DSI data lane0返回的tearing effect trigger message

收到TE信号后，TE module需要置位相关flag，并触发中断。如果启动了TE mode传输，还要trigger下一帧的DMA传输。

Bee4的dw mipi dsi host，有一个tear request bit，从spec的描述看，应该是置位后，dsi host发BTA将bus控制器交给display，display在它该发Tear effect trigger的发送Tear effect trigger给host并交还bus控制权， host解析后，assert TE signal给lcdc。

需要找DHC询问如何获取TE message。DHC说没有这个功能，要做的的话需要添加，工作量未知。因此评估是否可以没有这个信号是否可以:

首先MIPI-DSI spec没有规定要有TE pin。其次BT认为没有这个信号可以，因为一般LCD还有TE pin，而且video mode不需要TE信号。但是对于大部分主流屏幕是否有TE pin，以及中大型屏幕是否都是video mode，他们不敢打包票。

mipi-dsi分为video mode和cmd mode，spec中有说明一般来说，cmd mode内部有frame buffer，可以通过命令来更改屏幕显示等操作。video mode内部没有frame buffer，或者只有partial frame buffer，依赖于host持续不断的输入像素数据来进行显示，此时不需要TE信号，但spec不对此做限制。因此存在两个问题

  1. 是否主流中大型mipi屏，内部没有frame buffer，只支持video mode

  2. 是否主流中大型屏幕，会有TE pin代替TE信号

分辨率

sitronix

接口

分类

320*480

ST7796U(RGB666)带RAM

st7713(RGB888)不带RAM

MCU, RGB, MIPI

MIPI

AIOT

AIOT

400*400

ST77922带RAM

MCU, QSPI, RGB, MIPI

可穿戴

400*480

ST7797不带ram

MIPI

可穿戴

480*960

st7701s 不带ram

RGB, MIPI

AIOT

720*1680

ST7123不带ram

MIPI

TDDI

560*640

ST77922带ram

MCU, QSPI, RGB, MIPI

TDDI

分析晨曦那边屏幕

屏幕IC

TE pin

GRAM

接口

分辨率

Data Lane

DSI-CLK( MHz)

RGB timing

JD9365DA

无

无

MIPI

800*1280

1/2/3/4

40-?

1, 850mpbs

2, 1.7gbps

3, 2gbps

4, 2gbps

ILI9881C

有

无

MIPI

800*1280

2/3/4

40-250

2, 850mps

3, 650mbps

4, 550mbps

HX8394D

有

RGB MSB 1bit GRAM

SPI, MIPI

720*1280

1/2/3/4

40-?

4, 2.2gbps

ILI9806E

有

有

MCU, SPI, RGB,MIPI

480*854

1/2

40-250

1, 850mbps

2, 500mbps

clock < 35M

R63353

有

无

MIPI

1080*1920

1/2/3/4

100-500

200-1000mbps

st7701s

有

无

RGB,MIPI

480*800

1/2

40-400

1, 800mbps

2, 550mbps

clock < 30M

天山屏厂 23-27，typ 25

从矽创官网和晨曦提供的driver IC看，是否带ram支持的接口类型有关，与size无关。如果仅支持MIPI或者RGB，则不带ram，如果同时支持MCU，则带ram。TE pin则是，带有RAM的一定有，不带RAM的可能有。

综上，从现有的资料看，可以不需要MIPI的TE message。

Underflow 时设置Hold clock option

增加一个 hold clock option, 可以设置 timeout, 用于发生 underflow 的情况。

Timeout = 0, 即目前的情况

Timeout != 0, 即 hold clock. 在该期间, 会停clk， 目的是等 dma fifo 准备好 data, 让 LCDC 有数据可读 并 发送到 屏侧。

  • 超时时间设置：

    可以设置为 128 us

  • 超时占用bit 数目：

    例如按照50M clk, 则 1us就是50 个 clk，可以看成6bits 。对于128us 超时， 我们要求6+7=13个bits 就可以了

    如果将64个clk看成一个单位， 留7bits 控制也可以

  • 超时后仍没有data, 发 err data

帧间delay

部分LCD对帧间的时序也有要求，因此增加一个帧间的delay。适用于所有DMA传输。另外一个原因是，TE mode下也需要这样一个帧间delay，来防止屏幕撕裂现象。

Line number/像素坐标

增加表示当前刷到第几行的寄存器。LVGL或许可以通过这个值提前刷屏以增加绘图帧率。需要提供line中断。

Bee4可以获取当前像素点的坐标。smart LCDC也可以，所以无需改动。

中断

增加TE中断，除此之外原有的中断可以满足要求。

考虑如果要做linklist module，需要dd考虑增加相关中断。

像素转换器

format支持

对于一些UI，比如lvgl8.0版本，仅支持ARGB8888，RGB565, RGB565_SWAP三种格式，因此格式的转换是必须的。相比smart LCDC，参考bee4 display controller，新增了以下支持。其他保持像素格式和smart保持一致即可。

Input format

Output format

RGB888

BGR888

RGB565

BGR565

ABGR8888

ARGB8888

ARGB1555

ARGB4444

RGB666

ARGB8666

RGB888

BGR888(新增)

RGB565(新增)

BGR565(新增)

像素转换的原则是

  1. 如果有A值，A值直接丢弃

  2. 如果是从高位深向低位深转换，直接丢弃高位深的低位，如下图的RGB888转RGB565。

  1. 如果是从低位深向高位深转换，高位深的低位用高位填充，如下图的RGB565转RGB888.

swap支持

ram中的像素数据存放顺序和LCD要求的发送顺序可能存在差异，因此需要swap功能。

type

source

destination

8bit swap

[3, 2, 1, 0]

[2, 3, 0, 1]

16bit swap

[3, 2, 1, 0]

[1, 0, 2, 3]

8bit+16bit swap

[3, 2, 1, 0]

[0, 1, 2, 3]

其中bit swap是必须支持的。其他两种不好做则不做。

比如对于MCU 8bit-RGB565接口，如下图所示，第一个pixel分两个clock传输，第一个byte是红色5bit和绿色高3bit，第二个byte是绿色低3bit和蓝色bit，有时候这两个byte也可能交换顺序，这种交换无法用format变换实现，只能用byte swap实现。

../../_images/mcu_interface_format_8bit_rgb565.png

滑动效果

需求描述

在新的一帧完整地显示到屏幕时，显示一个滑动的效果（屏幕上同时既显示部分新一帧数据，又显示部分旧帧数据）。

滑动方向应支持：从左向右，从右向左，从上至下，从下至上。

不同滑动方向的显示效果，用如下示意图描述：

../../_images/slide_effect_left_to_right.svg
../../_images/slide_effect_right_to_left.svg
../../_images/slide_effect_up_to_down.svg
../../_images/slide_effect_down_to_up.svg

基于目前LCDC 功能实现滑动效果方案

显示原理：

从Current Frame 到Target Frame，包括展示滑动效果的中间帧，这些Frames 均需要CPU（分时）完整地绘制出来，假设以前面小节示意图为例，需要CPU绘制5帧完整的图片数据。

当 LCDC 正在发送某一帧（Frame_A）的像素数据至显示模块时， 需要 CPU 在当前帧推送结束之前，及时将下一待显示帧（Frame_B）绘制好，并将Frame_B 的buffer 地址写给唯一的 LCDC_DMAImageAddr 寄存器，用于配置LCDC DMA 下一帧的Memory Address。

../../_images/current_lcdc_sliding_from_left_to_right.svg

该方案要求：

  1. CPU 绘制的帧数较多。除 Current Frame 与Target Frame之外，还需要绘制中间帧。

  2. 对CPU 绘制帧的速率有要求。例如：本来LCDC刷新率是60Hz，但对于CPU画的时间不够，CPU需要等下一次VSYNC，这样看起来的刷新率就变成30Hz了。因为每次要等两个vsync，就会觉得帧率降低了。

基于新增LCDC功能实现滑动效果方案

显示原理：

与上一种方案相比，本方案只需CPU 绘制完整2帧数据：Current Frame 与Target Frame。 位于这两帧之间的全部中间帧， 均由LCDC 基于已绘制的两帧画面信息，按照用户预先配置给LCDC的规则拼接出中间帧画面，并推送至屏幕侧。

这种方案会需要两个buffer: buffer0, buffer1，用于配置LCDC DMA frame时 Current Frame 与Target Frame 在内存中的 buffer baseaddr（有关配置信息详见后续使用流程章节介绍）。

在滑动过程中，滑动的方向需要由用户指定；拼接帧画面中原始两帧各自显示比例由用户自定义的offset 参数控制（有关 offset 在不同滑动方向的含义及单位接下来会详述）； LCDC 按此配置信息进行重组中间帧的像素数据。

帧画面拼接原理

对于横屏横用，竖屏竖用的使用情况，按常规习惯的叫法设定滑动方向即可；

对于横屏竖用的情况，用户在指定滑动方向时需要考虑到方向转置的情况，如物理横屏下的水平/垂直滑动分别映射到按竖屏使用的垂直/水平滑动方向

每一帧的像素数据在内存空间中的存放格式是：

从Row0 开始逐行存储，每一行按照 Column0, Column1, … ColumnW (W为屏幕每行的像素数目) 的顺序存储；

Next, Row1 行， Row2 行…

水平滑动：

屏幕每一行的像素数据均由Current Frame 与Target Frame 的对应行在内存中的部分像素数据共同组成（见下方示意图）；

屏幕左侧画面的像素数据统一来自同一帧的内存buffer, 右侧画面则统一来自另一帧的内存buffer。

  • 屏幕左右两侧画面显示

    左右侧画面是Current Frame or Target Frame 的部分画面，取决于水平滑动方向：

    • 从左向右：左侧是Target， 右侧是 Current

    • 从右向左：左侧是Current， 右侧是 Target

  • Offset （单位： 像素点个数）：

    • 对于屏幕左侧画面：

      offset 指LCDC DMA 数据时，从存储该侧画面的 Memory buffer读取指定行的像素数据时，从行首buffer 地址中跳过的像素点个数，即从 Column_offset 开始搬运像素数据，搬运长度为 ((LCD_W - offset)*bpp/8) Bytes.

      其中 LCD_W 为屏幕每行的像素数目。见如下示意图

    • 对于屏幕右侧画面：

      offset 指LCDC DMA 数据时，从存储该侧画面的 Memory buffer读取指定行的像素数据时，从对应行首buffer地址开始DMA，搬运长度为 (offset * bpp/8) Bytes.

      其中 LCD_W 为屏幕每行的像素数目。

../../_images/pixel_data_composed_curframe_and_targetframe_in_row_sliding_from_left_to_right.svg
../../_images/pixel_data_composed_curframe_and_targetframe_in_row_sliding_from_right_to_left.svg

Note

Image width 和 Horizontal offset都需要是4的倍数。

垂直滑动：

屏幕每一列的像素数据均由Current Frame 与Target Frame 的对应列的部分数据共同组成。（见下方示意图）；

屏幕上侧画面的像素数据统一自同一帧的内存buffer, 下侧画面来则统一来自来另一帧的内存buffer。

  • 屏幕上下两侧画面显示

    上下侧画面是Current Frame or Target Frame 的部分画面，取决于垂直滑动方向：

    • 从上向下：上侧是Target， 下侧是 Current

    • 从下向上：上侧是Current， 下侧是 Target

  • Offset （单位：行数）：

    • 对于屏幕上侧画面：offset 指LCDC DMA 数据时，从存储该侧画面的 Memory buffer基地址开始，需要跳过的行数，即从 Row_offset 开始搬运数据，搬运行数为( LCD_H - offset ). 其中 LCD_H 屏幕有效显示行数。

    • 对于屏幕下侧画面：offset 指LCDC DMA 数据时从存储该侧画面的 Memory buffer基地址开始DMA，搬运行数为offset。

../../_images/pixel_data_composed_curframe_and_targetframe_in_column_sliding_from_up_to_down.svg
../../_images/pixel_data_composed_curframe_and_targetframe_in_column_sliding_from_down_to_up.svg

使用流程（for: New Feature）

  1. 在两块各自连续的内存中绘制Current Frame 与Target Frame的像素数据。

  2. 提供并配置滑动需要的LCDC参数：屏幕每行像素个数（ LCD_W ）, 屏幕有效行数（ LCD_H ）与滑动方向

  3. 显示 Current Frame

    将 Current Frame内存的buf 基地址配置到LCDC的 buffer0寄存器中。

    此时 offset 应设置为0， 表示LCDC DMA frame 时，完全从 Current Frame 所在 buffer fetch

  4. 显示中间帧

    根据滑动效果展示的情况，正确设置 offset

    将屏幕左侧/上侧的图像数据存放于 buffer0; 右侧/下侧的图像数据存放buffer1中

    • 对于从左向右 offset 变化示意图如下: 应保证 offset_a > offset_b > offset_c

      即 offset 的变化趋势：由 max 向 min 变化

      ../../_images/process_after_adding_new_feature_when_sliding_from_left_to_right.svg

    • 对于从右向左: 应保证 offset_a < offset_b < offset_c

      即 offset 的变化趋势：由 min 向 max 变化

      ../../_images/process_after_adding_new_feature_when_sliding_from_right_to_left.svg

    • 对于从上向下: 应保证 offset_a > offset_b > offset_c

      即 offset 的变化趋势：由 max 向 min 变化

      ../../_images/process_after_adding_new_feature_when_sliding_from_up_to_down.svg

    • 对于从下向上: 应保证 offset_a < offset_b < offset_c

      即 offset 的变化趋势：由 min 向max 变化

      ../../_images/process_after_adding_new_feature_when_sliding_from_down_to_up.svg

  5. 显示 Target Frame

    将 Target Frame内存的buf 基地址配置到LCDC的 buffer0寄存器中。

    此时 offset 应设置为0， 表示LCDC DMA frame 时，完全从 Target Frame 所在 buffer fetch