IMXRT1170 EVK/RK055HDMIPI4M - littlevgl example not quite right!

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMXRT1170 EVK/RK055HDMIPI4M - littlevgl example not quite right!

2,649 Views
AndyCapon
Contributor II

Hi Guys,

The littlevgl demo from the sdk is not quite right here, the orientation is wrong.

 

IMG_0548.JPG

Is this example still work in progress?

 

Many thanks

 

Andy

0 Kudos
Reply
7 Replies

2,635 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I'd like to get know more information about the question in advance of answering.
1) What's version of the SDK library and the demo did you run?
2) Can you share the value of the below macros in lv_conf.h file?
#define LV_HOR_RES_MAX
#define LV_VER_RES_MAX
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,328 Views
SANDEEP2
Contributor I

Hello Team NXP,

The same screen orientation problem is with me , When I run any LVGL related sdk examples the screen is not coming in landscape.

Is this problem related to existing LVGL patch which is inbuilt with NXP?

Is there anyway to resolve this issue. Please suggest. 

 

Regards,

Sandeep 

0 Kudos
Reply

2,324 Views
AndyCapon
Contributor II

Hi Sandeep,

 

Unfortunately there is no performant way of running LVGL in landscape mode, however there are a couple of ways of doing it, one where you rotate the whole frame buffer and another where you limit the lvl frame buffer memory so it repeatedly renders areas of the screen and you then rotate those areas to the final frame buffer.

I tried both ways here and the speed is not acceptable for either of them, there is more info in these threads:

https://community.nxp.com/t5/i-MX-RT/Framebuffer-rotation-Some-advice-needed-VGLite-PXP-LCDIFV2/m-p/...

https://community.nxp.com/t5/i-MX-RT/PXP-Rotation-with-destination-offsets-not-divisible-by-BLOCK/m-...

The PXP rotate functionality is limited to 8x8 or 16x16 blocks, here is some code that will rotate arbitrary sizes to arbitrary positions:

static void blit_90(PXP_Type *base, void *pDestBuffer, uint16_t uDestBufferWidth, uint16_t uDestBufferHeight, void *pSourceBuffer, uint16_t uSourceBufferWidth, uint16_t uSourceBufferHeight, uint16_t uX, uint16_t uY, uint8_t uBytesPerPixel)
{
	// blit source 90 degrees rotated to destination

	uint16_t uRotatedX = uDestBufferWidth - uSourceBufferHeight - uY;
	uint16_t uRotatedY = uX;

	uint16_t uRemW;
	uint16_t uRemH;

	if(uSourceBufferWidth >= 16 && uSourceBufferHeight >= 16)
	{
		uRemW = uSourceBufferWidth % 16;
		uRemH = uSourceBufferHeight % 16;

		uint16_t uBlitW = uSourceBufferWidth - uRemW;
		uint16_t uBlitH = uSourceBufferHeight - uRemH;
		uint16_t uSourceHOffset = uRemH ? ((uRemH+1) * uSourceBufferWidth * uBytesPerPixel) : 0;

		PXP_Init(base);

		/* PS configure. */
		const pxp_ps_buffer_config_t psBufferConfig = {
			.pixelFormat = kPXP_PsPixelFormatRGB565,
			.swapByte    = false,
			.bufferAddr  = (uint32_t)pSourceBuffer - uSourceHOffset,
			.bufferAddrU = 0U,
			.bufferAddrV = 0U,
			.pitchBytes  = uSourceBufferWidth * uBytesPerPixel,
		};

		PXP_SetProcessSurfaceBackGroundColor(base, 0U);

		PXP_SetProcessSurfaceBufferConfig(base, &psBufferConfig);

		// Disable AS.
		PXP_SetAlphaSurfacePosition(base, 0xFFFFU, 0xFFFFU, 0U, 0U);

		// rotate
		PXP_SetRotateConfig(base, kPXP_RotateProcessSurface, kPXP_Rotate90, kPXP_FlipDisable);
		PXP_SetProcessSurfacePosition(base, 0, 0, uSourceBufferHeight -1, uSourceBufferWidth -1);

		// Output config.
		outputBufferConfig.pixelFormat    = kPXP_OutputPixelFormatRGB565;
		outputBufferConfig.interlacedMode = kPXP_OutputProgressive;
		outputBufferConfig.buffer0Addr    = (uint32_t) (pDestBuffer + (uRotatedY * uDestBufferWidth * uBytesPerPixel) + ((uRotatedX + uRemH) * uBytesPerPixel));
		outputBufferConfig.buffer1Addr    = 0U;
		outputBufferConfig.pitchBytes     = uDestBufferWidth * uBytesPerPixel;
		outputBufferConfig.width          = uBlitH;
		outputBufferConfig.height         = uBlitW;

		PXP_SetOutputBufferConfig(base, &outputBufferConfig);

		// Disable CSC1, it is enabled by default.
		PXP_EnableCsc1(base, false);

		// off we go
		PXP_Start(base);

		// Wait for process complete.
		while (!(kPXP_CompleteFlag & PXP_GetStatusFlags(base)))
		{
		}
		PXP_ClearStatusFlags(base, kPXP_CompleteFlag);
	}
	else
	{
		uRemW = uSourceBufferWidth;
		uRemH = uSourceBufferHeight;
	}

    // tidy up remainders
    if(uRemH)
	{
		//need bottom uRemH lines
		uint16_t *pSource   = (uint16_t *)pSourceBuffer + (uSourceBufferWidth * (uSourceBufferHeight - uRemH));
		uint16_t *pDestBase = (uint16_t *)pDestBuffer + uRemH + uRotatedX -1 + (uRotatedY * uDestBufferWidth) ;
		for(int16_t uH = 0; uH < uRemH; uH++)
		{
			uint16_t *pDest = pDestBase - uH;

			for(uint16_t uW = 0; uW < uSourceBufferWidth -uRemW; uW++)
			{
				*pDest = *pSource;
				pDest += uDestBufferWidth;
				pSource++;
			}

			pSource+=uRemW;
		}
	}

	if(uRemW)
	{
		//need right uRemW columns
		uint16_t *pSourceBase = (uint16_t *)pSourceBuffer - uRemW + (uSourceBufferWidth * uSourceBufferHeight);
		uint16_t *pDestBase   = (uint16_t *)pDestBuffer + ((uRotatedY + uSourceBufferWidth - uRemW) * uDestBufferWidth) + uRotatedX;
		for(int16_t uW = 0; uW < uRemW; uW++)
		{
			uint16_t *pDest   = pDestBase + (uW * uDestBufferWidth);
			uint16_t *pSource = pSourceBase + uW;

			for(uint16_t uH = 0; uH < uSourceBufferHeight; uH++)
			{
				*pDest  = *pSource;
				pSource -= uSourceBufferWidth;
				pDest++;
			}
		}
	}
}

 

The main problem is that lvl runs very slowly even without the rotation because they spin the cpu waiting for their internal PXP calls to finish in the cpu rendering code they have rather than batching it up properly, so updating the full screen takes around 11ms and uses 100% cpu (this is without the rotate cost), I haven't looked at the RTOS version maybe that works a bit better.

I came to the conclusion that the CPU cost of using LVGL on this screen was far too much.

If you want to try it out though the simplest set the lvl display up to be 1280x720 and give it its own full frame buffer, then in the flushDisplay:

static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p)
{
	// copy
	//resetCpuCycleCount();
	DCACHE_CleanInvalidateByRange((uint32_t)s_frameBuffer, DEMO_FB_SIZE);
	DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE);

	blit_90(PXP, s_frameBuffer, 720, 1280, color_p, 1+(area->x2-area->x1), 1+(area->y2-area->y1), area->x1, area->y1, 2 );

     lv_disp_flush_ready(disp_drv);
}

 

 

Where s_frameBuffer is our real frame buffer.

This is all single buffer to keep it easy.

 

 

0 Kudos
Reply

2,626 Views
AndyCapon
Contributor II

Hi Jeremy,

Thanks for the reply, I tried the 2.9.0 and 2.9.1 sdks.

Since originally posting I looked at the code and as it stands there is no way it will work correctly in landscape mode with portrait displays.

The version of lvl used in the sample doesn't support rotation fully and the example uses the two actual display frame buffers to pass to lvlgl which expects landscape displays. There have been changes to the code from other landscape displays to limit the display to how it is seen in the image I posted.

I have it working in landscape now but this required using different frame buffers in lvl and then rotating the data to the real display framebuffers in the flush callback.

I'm still trying to get my head around why the RK055HDMIPI4M is a portrait display, it makes everything so much more effort. There are 6 jumpers on the board but there doesn't seem to be any documentation anywhere, I'm wondering if one of these may put it into landscape mode, do you have any info on this?

Thanks

Andy

0 Kudos
Reply

2,550 Views
auftrag2021
Contributor III

I have exactly the same problem. I am also looking for the RK055HDMIPIM Eva-board jumper information all around (even by local distributor Farnell in Germany), but failed...

auftrag2021_0-1619858802264.png

I also got two document about this LCD-module

RK055AHD091-CTG (LCD Module Specification)

RM68200 Data Sheet_V2.6 (LCD controller referece manual)

But none of them mention any information about the jumer or landscape/portrait configuration.

Can anyone from NXP confirm this issue?

1. Is this landscape/portrait problem really caused by these jumpers?

2. Or the problem can fixed in SDK software? (the latest SDK version see below)

auftrag2021_1-1619859119781.png

 

 

 

0 Kudos
Reply

2,522 Views
AndyCapon
Contributor II

Hi There,

I have heard from the distributer and NXP that it is not possible to get this display into landscape mode.

I think as it stands LVGL and this display is not viable.

In general the LVGL rendering is pretty slow due to the high resolution and ineffective use of PXP, combine that with then having to rotate the data and it all crawls.

There are some other related threads:

https://community.nxp.com/t5/i-MX-RT/Framebuffer-rotation-Some-advice-needed-VGLite-PXP-LCDIFV2/m-p/...

https://community.nxp.com/t5/i-MX-RT/PXP-Rotation-with-destination-offsets-not-divisible-by-BLOCK/m-...

 

 

 

 

0 Kudos
Reply

2,618 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Thanks for your reply.
1) There are 6 jumpers on the board but there doesn't seem to be any documentation anywhere, I'm wondering if one of these may put it into landscape mode, do you have any info on this?
-- No, I'm afraid it can't set the jumper to rotate the display in the LCD.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply