【GD32450I-EVAL】TLI clock and RGB interface timing
[Copy link]
This post was last edited by tinnu on 2020-10-6 21:44
1. Check the frame rate
The easiest way to check the current RGB screen refresh frame rate through electrical information is to check the pulse of the VS pin, because once the VS pin generates a pulse, it means the end of a frame.
With the current configuration, there are 53 frames per second, which is not even 60 frames yet.
2. Clock Source
The four red boxes are registers that can be configured. The last three are bits in RCU_PLLSAI (this register), and the first PLLPSC needs to be configured in other registers.
The five underlined ones are the five clock lines:
The prefix PLLSAI is omitted in the image annotations
At this time, it is necessary to check where the clock of PLLSRC comes from?
The relevant bits are in the RCU_PLL register:
The RCU_PLL register should be used by the PLL phase-locked loop itself, but this selection function belongs to PLL_I2S and PLL_SAI, and they are both placed here for common use.
(III) Modify the clock
If the system is to reach a speed of 200M, PLL must provide the system with a clock, so the initialization here must be performed in systemInit
The function used for initialization is:
system_clock_200m_25m_hxtal(void)
The note inside states:
PSC=25, the external crystal is also 25M, which means VCOSRC is only 1M!
Back to the current TLI configuration:
rcu_pllsai_config(192, 2, 3)
That is, the VCO is given a frequency of 192M, and the first wave of 3-frequency division belonging to R comes out,
and then the 8-frequency division belonging to div comes out:
rcu_tli_clock_div_config(RCU_PLLSAIR_DIV8);
Only 8M left!
Let's try a 2-way frequency division!
Check the VS pins and it seems that there is no major problem with the timing:
But the screen was blank. I tried 4-way division and it still didn't work.
It seems that doubling is too radical. Let’s try to modify the multiplier:
Change the clock to 219, and it just exceeds 60 frames, and there is no problem. It seems that it is okay to exceed 60Hz a little, but if you want 120Hz, this screen can't do it.
There is no difference in operation, because this is the clock shared with USB, and it can be adjusted at will if USB application is not considered.
(IV) Screen refresh flashing problem
Before SDRAM was transplanted, the screen had a flickering problem:
This is related to the refresh strategy.
The relevant function is the LittleVGL refresh function:
static void DEMO_FlushDisplay(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p)
The refresh call inside is
if (color_p == EXT_BUFFER0_ADDR)
{
tli_layer_disable(LAYER0);
tli_layer_enable(LAYER1);
tli_reload_config(TLI_FRAME_BLANK_RELOAD_EN);
}
else if (color_p == EXT_BUFFER1_ADDR)
{
tli_layer_disable(LAYER1);
tli_layer_enable(LAYER0);
tli_reload_config(TLI_FRAME_BLANK_RELOAD_EN);
}
The relevant register is the reload layer configuration register (TLI_RL)
FBR
Frame Blanking Reload Request This bit is set by software and cleared by hardware after reload.
0: Disable overloading
1: Layer configuration will be reloaded into real registers during frame blanking.
RQR
Immediate reload request This bit is set by software and cleared by hardware after the reload.
0: Disable overloading
1: Layer configuration will be reloaded into the real register after this bit is set.
This should not be refreshed immediately, but should wait for a frame to complete before refreshing:
if (color_p == EXT_BUFFER0_ADDR)
{
tli_layer_disable(LAYER0);
tli_layer_enable(LAYER1);
tli_reload_config(TLI_FRAME_BLANK_RELOAD_EN);
}
else if (color_p == EXT_BUFFER1_ADDR)
{
tli_layer_disable(LAYER1);
tli_layer_enable(LAYER0);
tli_reload_config(TLI_FRAME_BLANK_RELOAD_EN);
}
|