Hi,
I am using iMXRT1060 and will be using a 24 bit LCD display. I would like to know if it is possible to drive the display using 16 lines in RGB24 bit mode from the MCU. Since we also require the Ethernet functionality, we can use only 16 lines from eLCDIF.
Thanks
I do exactly that on a couple of projects on RT1064 devices. I use a 24 bit RGB panel, but with only 16 datalines. The rest of the LCD interface I use for connection to a KSZ8081 for Ethernet. Works fine.
Connected like this:
Hi,
Thanks for your quick response. We will be using an 7" LCD with resolution of 1024x600. Mainly we are worried about the clarity when driving with reduced lines. How is the display performance and what is the model, size and resolution of your display? Since we are in the initial phase, we are looking at various options as to use an external controller or the internal controller module.
Thanks.
No worries
And no, none of the two displays have built-in controller, they both use HSYNC/VSYNC/CLK and RGB data (24 bit wide interfaces where I only use 16 from the eLCD)
From the 7" datasheet:
Hi @carstengroen,
I would like to clarify regarding the LCD mode. Since you have used a 7" TFT display and I see that your display also has option to set the DE or SYNC mode. I would like to understand what mode should be set in the LCD for the iMXRT1060 LCDIF controller. I see that the eLCDIF controller used all HSYNC, VSYNC, LCD_ENABLE and CLK. So it is bit confusing as to which mode should the LCD be tied to and do we need to make any changes to the controller settings.
Thanks for your help in advance.
I run the display as it is "out of the box". I do not set anything in the display, I "just" connect it as is, so that means I run it with "DEN" mode (thats how the eLCDIF/GPIO pins is set up)
Hi @carstengroen,
Thanks for your quick clarification.
Just to clarify,
I run the displays in RGB565 mode:
const elcdif_rgb_mode_config_t config = {
.panelWidth = LCD_WIDTH,
.panelHeight = LCD_HEIGHT,
.hsw = LCD_HSW,
.hfp = LCD_HFP,
.hbp = LCD_HBP,
.vsw = LCD_VSW,
.vfp = LCD_VFP,
.vbp = LCD_VBP,
.polarityFlags = LCD_POL_FLAGS,
/* littlevgl starts render in frame buffer 0, so show frame buffer 1 first. */
.bufferAddr = (uint32_t)s_frameBuffer[1],
.pixelFormat = kELCDIF_PixelFormatRGB565,
.dataBus = LCD_LCDIF_DATA_BUS,
};
I use both this 4.3 inch 480x272 pixel: https://www.buydisplay.com/sunlight-readable-4-3-inch-high-brightness-480x272-tft-lcd-display
and this 7 inch 800x480 pixel: https://newhavendisplay.com/7-0-inch-sunlight-readable-capacitive-tft-display
both with capacitive touch.
Hi,
I see that the 7" display you use has a built-in display controller. So you are not using the eLCDIF driver of the MCU? Sorry to ask you many questions. I am just curious about the performance.
Thanks.
Hi @kerryzhou,
Yes, I understand that 24 lines are required to drive 24 bit LCD in RGB888 mode but what confuses me is the section 35.3.2 Write Data Path in the Reference Manual. You can see the figure 35-3, 35-4 and 35-5 which states how an 8 bit and 16 bit interface is used to transfer 24bpp data. Can you provide me some insight on this? Is there any example of how to use it?
Thanks.
Hi @EmbeddedTech ,
Good question!
Talk about my understanding.
I think the 35-3, 35-4 and 35-5 means, when the data buffer input is 16 bpp or the 8bpp, but your LCD need the 24 bit, in fact, in the hardware side, it still connect 24 data line to your LCD, as your 24bit LCD need it. So, like the RM said:
if the input frame has fewer bits per pixel than the display, as in
a 16 bpp input frame going to 24 bpp LCD, eLCDIF will pad the MSBs of each color to
the LSBs of the same color for each pixel.
In fact, it will give the same color to the related LCD_DATA16-DATA24.
But, what your lack is the hardware, not the input frame, as you know, the LCD need to receive the data from RT eLCDIF interface.
You also can conside, you didn't connect DATA16-data24 to your external 24 bit LCD, but I think the display is not good.
Wish it helps you!
Best Regards,
Kerry
Hi @kerryzhou,
I understand that if the input frame has fewer bits per pixel than the display then the MSB's will be padded to the LSB of the same color.
What I am trying to understand from RM is,
It is important to note that the number of data lines is not always proportional to color depth. For
example, a 6-bit (6-line) RGB interface can be chosen to display 565-RGB colors over 3 clock pulses rather than all at once. The RGB interface also needs the control signals HSYNC, VSYNC, DCLK and DE to indicate where and when the RGB data should be displayed. Below is an example of the pin descriptions for a 24-bit RGB interface."
Based on the above statement is it possible to drive a 24-bit LCD in RGB 888 mode using 16 lines in 2 clock cycles or so?
Thanks.
Hi @EmbeddedTech ,
So, your mentioned:
It is important to note that the number of data lines is not always proportional to color depth. For
example, a 6-bit (6-line) RGB interface can be chosen to display 565-RGB colors over 3 clock pulses rather than all at once. The RGB interface also needs the control signals HSYNC, VSYNC, DCLK and DE to indicate where and when the RGB data should be displayed. Below is an example of the pin descriptions for a 24-bit RGB interface."
is from the LCD RM, not the RT chip RM, right?
I think the RT elcd can't support it, but you may consider to use the flexIO to simulate it, then you can use small pad to send out the data with more clocks.
Best Regards,
Kerry
Hi @kerryzhou,
Yes that is not from RT RM.
If that is the case, is it possible to share the flexIO code which will work with iMXRT1060EVK?
Can that be used on the EVK without any hardware modifications in order to test its functionality?
Thanks.
This is the flexio LCD application note:
https://www.nxp.com/docs/en/application-note/AN5280.pdf
https://www.nxp.com/docs/en/application-note-software/AN5280SW.zip
You can refer to the code, but you need to modify it to the RT1060 to match your own LCD, we don't have your LCD, so no directly code to run.
Best Regards,
kerry
Hi @kerryzhou , I think you meant @EmbeddedTech in your message
Hi @kerryzhou,
So the 8 bit interface and 16 bit interface mentioned in the Reference Manual is direct RGB interface and not any MPU parallel interface right.
I saw in one document explaining the difference between the RGB and the MCU interface as in below link,
Parallel Interfaces MCU vs. RGB (focuslcds.com)
"The number of bits transmitted effects the color depth of the display. For example, a 16-bit RGB interface would have 5 red, 6 green, and 5 blue data bits/pixel. This results in a 65k color depth ( 2^16 = 65𝑘 𝑐olors). The RGB interface typically sends the 16-bit data over the 16 data pins in one HSYNC pulse.
It is important to note that the number of data lines is not always proportional to color depth. For
example, a 6-bit (6-line) RGB interface can be chosen to display 565-RGB colors over 3 clock pulses rather than all at once. The RGB interface also needs the control signals HSYNC, VSYNC, DCLK and DE to indicate where and when the RGB data should be displayed. Below is an example of the pin descriptions for a 24-bit RGB interface."
Is it possible to achieve something as mentioned above?
Thanks.