BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: FT813 REG_DLSWAP not working as expected  (Read 16268 times)

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
FT813 REG_DLSWAP not working as expected
« on: May 05, 2021, 09:13:43 AM »

Hi,

I am using an FT813 chip to drive an 8 inch LCD. Every thing seems to be working fine except for REG_DLSWAP command. I am using the following code which is fairly straightforward:

Code: [Select]
reset_ft813();
ft800cmdWrite(EVE_CLKEXT,0x00);
//activate module
  ft800cmdWrite(EVE_ACTIVE, 0x00);
  do
{
ddd = ft800memRead8(REG_ID);
}while(ddd != 0x7c);
  //turn on display
  select_spi_mode(SPI_MODE_QUAD);
  delay_ms(2);
  do
{
ddd = ft800memRead8(REG_ID);
}while(ddd != 0x7c);

  do
{
ddd = ft800memRead8(REG_CPURESET);
}while(ddd != 0x00);

ft800memWrite16(REG_HCYCLE,  1266);  /* total number of clocks per line, incl front/back porch */
ft800memWrite16(REG_HOFFSET, 23); //TVB   /* start of active line */
ft800memWrite16(REG_VCYCLE,  526);  /* total number of lines per screen, including pre/post */
        ft800memWrite16(REG_VOFFSET, 46); //THB /* start of active screen */
        ft800memWrite8(REG_SWIZZLE,  0); /* FT8xx output to LCD - pin order */
        ft800memWrite8(REG_PCLK_POL, EVE_PCLKPOL); /* LCD data is clocked in on this PCLK edge */
        ft800memWrite8(REG_CSPREAD, 0); /* helps with noise, when set to 1 fewer signals are changed simultaneously, reset-default: 1 */
ft800memWrite16(REG_HSIZE,   LCD_HORIZONTAL);   /* active display height */
ft800memWrite16(REG_VSIZE,   LCD_VERTICAL);   /* active display height */


//***************************************
// Write Initial Display List & Enable Display

  ramDisplayList = RAM_DL;
  ft800memWrite32(ramDisplayList, DL_CLEAR_RGB|FT813_COLOR_GREEN);
  ramDisplayList += 4;
  ft800memWrite32(ramDisplayList, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
// Clear 00100110 -------- -------- -----CST  (C/S/T define which parameters to clear)
  ramDisplayList += 4;
  ft800memWrite32(ramDisplayList, DL_DISPLAY);

  ft800memWrite32(REG_DLSWAP, DLSWAP_FRAME);
// Nothing is being displayed yet... the pixel clock is still 0x00
  ramDisplayList = RAM_DL;
 
ft800memWrite8(REG_GPIO,0x80); //enable display

  ft800memWrite8(REG_PCLK, 2);

When code reaches this point LCD screen turns green as expected.

I then immediately try to display the FTDI logo using this code:


Code: [Select]
ft800memWrite32(RAM_DL + 0, CLEAR(1, 1, 1));           // clear screen
ft800memWrite32(RAM_DL + 4, BEGIN(BITMAPS));  // start drawing bitmaps
ft800memWrite32(RAM_DL + 8, VERTEX2II(220, 110, 31, 'F')); // ascii F in font 31
ft800memWrite32(RAM_DL + 12, VERTEX2II(244, 110, 31, 'T')); // ascii T
ft800memWrite32(RAM_DL + 16, VERTEX2II(270, 110, 31, 'D')); // ascii D
ft800memWrite32(RAM_DL + 20, VERTEX2II(299, 110, 31, 'I')); // ascii I
ft800memWrite32(RAM_DL + 24, END());
ft800memWrite32(RAM_DL + 28, COLOR_RGB(160, 22, 22)); // change colour to red
ft800memWrite32(RAM_DL + 32, POINT_SIZE(320)); // set point size to 20 pixels in radius
ft800memWrite32(RAM_DL + 36, BEGIN(POINTS)); // start drawing points
ft800memWrite32(RAM_DL + 40, VERTEX2II(192, 133, 0, 0)); // red point
ft800memWrite32(RAM_DL + 44, END());
ft800memWrite32(RAM_DL + 48, DISPLAY()); // display the image
ft800memWrite8(REG_DLSWAP, DLSWAP_FRAME);

Unfortunately nothing happens unless I change the last line of code to:
ft800memWrite8(REG_DLSWAP, DLSWAP_LINE);

What am I doing wrong?
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 746
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #1 on: May 06, 2021, 04:08:48 PM »

Hello,

Thank you for question.

Could you let me know the exact display settings you are using for the panel?
Specifically LCD_HORIZONTAL and LCD_VERTICAL, if you can provide the panels datasheet that would be helpful as well.

Best Regards,
BRT Community
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 391
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #2 on: May 06, 2021, 08:50:39 PM »

The question for the timing parameters and that this is a 8' made me curious.
I checked the post before but I have no direct answer for the issue.

Now I tried to check what the timing parameters would result in and noticed that
the HSYNC and VSYNC values are missing.
The default VSYNC values might be okay with 0/10.
The default HSYNC values might be okay with 0/46.

HSIZE and VSIZE are not given but I guess these are 800x480?

The HCYCLE value is unusually high for 800, really high.

VOFFSET seems to be a bit high.
And HOFFSET seems to be a bit low.
Are these perhaps swapped around?

With this settings I get a resulting framerate of 45 Hz for a FT813.
This would be quite a bit low.


What I did not realise at first, this code looks like a modified version of my own code library.
A very old version, V2.x from back in 2016 and oddly modified.
And technically, only technically this would be a license violation since I only added a license later.  ;)
Regardless of where you dug this out and who modified it, I would like to point you to my most current version:
https://github.com/RudolphRiedel/FT800-FT813

Back to the topic itself, you are directly writing to the display list.
While this is a valid thing to do, you are missing out on all the additional features that are only
available thru the command co-processor.
Like for example just writing strings with CMD_TEXT.

Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 746
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #3 on: May 07, 2021, 10:36:39 AM »

Hello,

Just to clarify I am interested in the display settings being used as we have seen issues with the SWAP command when the following conditions are not adhered to:

HOFFSET < (HCYCLE – HSIZE)
VOFFSET < (VCYCLE – VSIZE)
 
As such the following must also be adhered to:

HCYCLE > HSIZE
VCYCLE > VSIZE


Best Regards,
BRT Community
Logged

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #4 on: May 08, 2021, 10:53:04 AM »

Hello,

Thank you for question.

Could you let me know the exact display settings you are using for the panel?
Specifically LCD_HORIZONTAL and LCD_VERTICAL, if you can provide the panels datasheet that would be helpful as well.

Best Regards,
BRT Community

I am using these values:
Code: [Select]
ft800memWrite16(REG_HSIZE,   800);   /* active display height */
ft800memWrite16(REG_VSIZE,   480);   /* active display height */

And this is the LCD I am using: AT080TN64

Datasheet can be found here:
https://datasheetspdf.com/pdf/911649/Innolux/AT080TN64/1

This is the first time I am working on a TFT LCD and I even designed the hardware driver from scratch. I might have messed up the aforementioned values. If that is the case I would be grateful if you can explain what I have done wrong.

Best wishes
« Last Edit: May 08, 2021, 11:00:07 AM by harry »
Logged

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #5 on: May 08, 2021, 11:19:12 AM »

The question for the timing parameters and that this is a 8' made me curious.
I checked the post before but I have no direct answer for the issue.

Now I tried to check what the timing parameters would result in and noticed that
the HSYNC and VSYNC values are missing.
The default VSYNC values might be okay with 0/10.
The default HSYNC values might be okay with 0/46.

HSIZE and VSIZE are not given but I guess these are 800x480?

The HCYCLE value is unusually high for 800, really high.

VOFFSET seems to be a bit high.
And HOFFSET seems to be a bit low.
Are these perhaps swapped around?

With this settings I get a resulting framerate of 45 Hz for a FT813.
This would be quite a bit low.


What I did not realise at first, this code looks like a modified version of my own code library.
A very old version, V2.x from back in 2016 and oddly modified.
And technically, only technically this would be a license violation since I only added a license later.  ;)
Regardless of where you dug this out and who modified it, I would like to point you to my most current version:
https://github.com/RudolphRiedel/FT800-FT813

Back to the topic itself, you are directly writing to the display list.
While this is a valid thing to do, you are missing out on all the additional features that are only
available thru the command co-processor.
Like for example just writing strings with CMD_TEXT.

I don't know if this section of the code is a modification of your code or someone else. I studied at least three different examples from the internet including your old code and the resulting messy code that I am using now probably has elements from all of those examples. But honestly, your code was the first one I used as the base for making the LCD work because It was the first project that came up in Google. I then used this example project: "BRT_AN_014FT81X Simple PIC Library Examples". I am using a cortex M7 ARM MCU and there are no example codes on the internet that can directly run on this MCU. I had to rewrite most functions from scratch although I have used the same function names from the examples to help me debug the code. I even had to write a bitanged manual spi driver functiopn for quad-spi because the QUAD SPI pins on the MCU were being used for something else.

Anyway, if I have violated your license I am truly sorry because I didn't realize this.  :(

And thanks for pointing me to your updated project.  :)

The reason I am writing to the display list directly is simply for debugging purposes so I can isolate the bug.

The reason HSYNC and VSYNC values are missing is because I am using the LCD in DE mode not SYNC mode. The datasheet of the lcd states that there is no need to connect the hsync and vsync pins in DE mode, and I haven't connected these pins and I didn't assign any values to the registers. Have I messed this up too?!

Best wishes

« Last Edit: May 08, 2021, 12:47:24 PM by harry »
Logged

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #6 on: May 09, 2021, 08:26:45 AM »

Thanks to you I managed to fix the issue. I had totally messed up the Cycle and Offset vales. It now works like a charm.
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 391
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #7 on: May 10, 2021, 06:19:00 PM »

Just to make this complete I would start with this:

HSIZE800
VSIZE480
VSYNC00
VSYNC10
VOFFSET23
VCYCLE525
HSYNC00
HSYNC110
HOFFSET46
HCYCLE1056
PCLK2

And that should result in 54 Hz.

Quote
I am using a cortex M7 ARM MCU and there are no example codes on the internet that can directly run on this MCU.

Which one?
I know for example that a colleague has been using ATSAMx70 but I never bothered to officially add this to my zoo of supported controllers. That one is strange. Too bad that Atmel is gone, and Microchip has not released any new M7.

Quote
I even had to write a bitanged manual spi driver functiopn for quad-spi because the QUAD SPI pins on the MCU were being used for something else.

Isn't that a bit extreme? :)
I never used QSPI since I never had an issue with startup-times and for the display-refresh with well below 4k of data I am using DMA transfers once every 20ms.

Quote
Anyway, if I have violated your license I am truly sorry because I didn't realize this.

That was a joke and that would have been my fault since I failed to add a license for the first versions.  :)
Logged

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #8 on: May 17, 2021, 08:10:55 AM »

Just to make this complete I would start with this:

HSIZE800
VSIZE480
VSYNC00
VSYNC10
VOFFSET23
VCYCLE525
HSYNC00
HSYNC110
HOFFSET46
HCYCLE1056
PCLK2

And that should result in 54 Hz.


I used these values and it is working without a problem:
HCYCLE,  1056
HOFFSET, 46
VCYCLE,  525
VOFFSET, 23

The values you mentioned were OK too.

I'm using STM32F777BIT6 MCU.

Quote
Isn't that a bit extreme? :)
I never used QSPI since I never had an issue with startup-times and for the display-refresh with well below 4k of data I am using DMA transfers once every 20ms.
I need to load a lot of image data. Better to be safe than sorry :) 


Quote
That was a joke and that would have been my fault since I failed to add a license for the first versions.  :)
8) ;)
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 391
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #9 on: May 17, 2021, 04:42:14 PM »

I'm using STM32F777BIT6 MCU.

I am not saying that this is not working but using EVE with these is a bit out-of-scope. :-)
After all, this thing they still call microcontroller has an embedded graphics unit complete with MIPI DSI support up to 720p.

Quote
I need to load a lot of image data. Better to be safe than sorry :) 

You may get better results using a BT81x then, the ASTC compression allows for more images in RAM_G and depending on the amount and resolution of the images you could also display them directly from the attached QSPI-Flash.
Logged

harry

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: FT813 REG_DLSWAP not working as expected
« Reply #10 on: May 19, 2021, 11:07:26 AM »


I am not saying that this is not working but using EVE with these is a bit out-of-scope. :-)
After all, this thing they still call microcontroller has an embedded graphics unit complete with MIPI DSI support up to 720p.

You may get better results using a BT81x then, the ASTC compression allows for more images in RAM_G and depending on the amount and resolution of the images you could also display them directly from the attached QSPI-Flash.

It's complicated. I'm upgrading a device to support an 8inch color LCD instead of the old small LCD that it is already using. We don't want to change the previous hardware, so I have no choice but to use an external Graphics Driver (it's much cheaper than changing the hardware). And there are a few thousand devices that need to be upgraded.
Logged