FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - jberkhout

Pages: [1] 2 3
1
So it still is possible, indirectly. This simple demo shows endless possibilities using EVE displays.
In the captured screenshots, there are just two items shown: the text at the top and just below it a rather large
480x320 RGB565 bitmap, which is entirely rendered by the MCU. But multiple smaller bitmaps can be used as well, the MCU can update the one of choice.
For this demo, the display and SD-Card were interfaced in 4-bit mode, and bus masters were used to transfer data, without CPU intervention.
An ARM Cortex-H7 running at 480MHz was used, but an (multi-core) MPU can be used as well. The SD-Card was mainly used to save the screenshots.

This is not a replacement for the EVE graphics, but rather an addition. The EVE should be used as much possible, it's blazing fast, we can't beat that with rendering by using the MCU.
We should use the MCU for rendering only when really needed:
- we need non-static graphics
- it's not possible to render it using EVE commands
- it's eating the display-list
- we don't need to render too much
- on-time only (startup) renderings, like styled buttons

Combining EVE commands and MCU rendering is flexible, it allows custom gauges, graphs and widgets which require dynamic updates.

The Gauge on the top right was rendered in 21mS using 4x-anti-aliasing for 100x100 pixels. Using 2x-anti-aliasing it takes 5mS and without it, it takes less than 750uS. Text is always using anti-aliasing, but is done very efficient, it isn't noticeable slower than non-anti-aliased fonts.
Without AA, the images still look pretty good, useful when there are many of those to update.



For this demo, the MCU wrote images to an EVE bitmap, rotated and scaled. Just nice, if we need it in a custom rendered image. Less artifacts but slower when done by the MCU.



A nice example of pixel-level access: we can zoom in endlessly on the Mandelbrot set, by touching a point of interest, getting new interesting views of it. Each rendering is unique.
You won't even be able to get the same picture ever again if you start it over, using touching.











2
General Discussion / Re: FT813 Custome Font Text
« on: July 23, 2020, 05:07:01 PM »
Thank you very much!

Indeed I saw I had to specify 31 as the first character instead of 32.
The problem was the Raw Data Address (RDA) in the Metric Block (MB), that Asset builder calculated.
It is possible I make some wrong adjustment in Asset Builder, but I couldn't find it.
Asset Builder got the RDA wrong, which caused that problem.
And it uses a wrong index in the Glyph Width Table (the first 128 bytes in the Metric Block).
But for bitmaps it is an excellent tool!

Using a font start of 31 was the only way to get it working when the raw file was generated from Asset Builder.
I noticed it calculated various values for the RDA, depending on the chosen font size.
It sometime even came up with negative values for it!
To calculate the RDA, it seemed to follow this formula: RDA = 1000 - Stride * Max_Height + 148;

I got around these issues by creating my own program to convert fonts to raw and header files.
The RDA reflects the load address in RAMG and the MB size (148 Bytes).
This program creates a valid Glyph Width Table and RDA.
It also does batch processing for different font families, styles and sizes, generating many file sets in one go. (no need to wait, just let it work for a period of time)
And I can replace the '$' for '°' symbol. I never use the $ sign on an embedded project but I do use '°' symbol for temperatures.

Now I modified my embedded library so it calculates and sets the RDA on the fly during loading, to allow for much more flexibility.
This way font raw files can be loaded at any location in RAMG, regardless the RAMG address used during conversion.
I now specify 32 as the first character, the RDA will always be correct.
The function that loads the raw files no longers takes a destination address, instead it returns the address it got loaded to.
It also stores the properties into a structure, and it keeps track of the content of the RAMG.
A collection of fonts and images in RAMG can be assigned an unique ID, so it is easy to check if a page needs to reload RAMG with a different collection of images and fonts.
There also is a function to check if a particular images exists in RAMG, and what the properties are.

3
General Discussion / Re: FT813 Custome Font Text
« on: July 21, 2020, 07:55:42 PM »
It seems EVE Asset Builder Version 1.6.0 still has this little glitch where, when converting fonts, the font width table has the glyph widths shifted to much too the start of the table.
This results in all lowercase characters all being printed over each other, so the cursor doesn't move on when these characters are printed, according to the wrong table content.
The raw file can easily be patched by editing using an HEX-editor, shifting the values in the glyph width table to the right positions solves the issue. I created and attached a python script to do this, it is easy to use.
Note my characters.txt contains these characters (including a space at the start):
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
The first 128 bytes in the raw file are for the width of the individual glyphs.
The displays assumes the index of this table being equal the ASCII character value, but Asset builder assumes the index as in the characters.txt file (that defines the characters to be captured).
When we shift those values to the right place, the display prints the strings as expected.
This can easily be done with a python script, I created and attached here.
These are my observations, I hope it will help others who want to use custom fonts.
It is possible I have a flaw somewhere in my conversion process, but I can't see how or where.
Otherwise the EVE Asset Builder is a great program!
For the font conversion, I created a windows program, where I select a font via the font dialog, then it generates the .raw and .h files, see attached example of a .h file.
Some part of the .h header file generated by my program looks like:
Code: [Select]
  /* Character 56 0x38 '8' */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x05, 0x9B, 0xA7, 0x20, 0x00, 0x00,  /*      :e63+.      */
  0x00, 0x01, 0xCF, 0xFE, 0xFF, 0xF6, 0x00, 0x00,  /*    `G##$###r     */
  0x00, 0x0D, 0xF8, 0x00, 0x04, 0xEF, 0x40, 0x00,  /*    8#o   ,$#,    */
  0x00, 0x4F, 0xC0, 0x00, 0x00, 0x4F, 0xB0, 0x00,  /*   ,#G     ,#6    */
  0x00, 0x6F, 0x90, 0x00, 0x00, 0x0F, 0xD0, 0x00,  /*   r#e      #8    */
  0x00, 0x4F, 0xC0, 0x00, 0x00, 0x1F, 0xB0, 0x00,  /*   ,#G     `#6    */
  0x00, 0x0D, 0xF8, 0x00, 0x00, 0x8F, 0x50, 0x00,  /*    8#o    o#:    */
  0x00, 0x02, 0xDF, 0xD6, 0x05, 0xF9, 0x00, 0x00,  /*    .8#8r :#e     */
  0x00, 0x00, 0x3F, 0xFF, 0xFF, 0xA0, 0x00, 0x00,  /*     -#####3      */
  0x00, 0x08, 0xFA, 0x38, 0xDF, 0xF9, 0x00, 0x00,  /*    o#3-o8##e     */
  0x00, 0x9F, 0x70, 0x00, 0x03, 0xDF, 0xB0, 0x00,  /*   e#+    -8#6    */
  0x02, 0xFB, 0x00, 0x00, 0x00, 0x0D, 0xF4, 0x00,  /*  .#6       8#,   */
  0x06, 0xF8, 0x00, 0x00, 0x00, 0x08, 0xF8, 0x00,  /*  r#o       o#o   */
  0x05, 0xF9, 0x00, 0x00, 0x00, 0x08, 0xF8, 0x00,  /*  :#e       o#o   */
  0x01, 0xFF, 0x30, 0x00, 0x00, 0x1E, 0xF4, 0x00,  /*  `##-     `$#,   */
  0x00, 0x7F, 0xF8, 0x31, 0x26, 0xDF, 0xB0, 0x00,  /*   +##o-`.r8#6    */
  0x00, 0x05, 0xEF, 0xFF, 0xFF, 0xF8, 0x00, 0x00,  /*    :$######o     */
  0x00, 0x00, 0x03, 0x67, 0x64, 0x00, 0x00, 0x00,  /*      -r+r,       */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /*                  */
It gives me some extra flexibility to adjust character and line spacing. It also can load raw files to show the characters in it, as they would appear on the display, but just on the PC.
I'm using the display connected to a QUADSPI peripheral on a 480MHz STM32H7. I do like the EVE displays much!

4
General Discussion / Re: FT813 Custome Font Text
« on: October 04, 2019, 09:19:03 AM »
Hi, thank you very much! I tested the utility used in the upcoming application note BRT_AN_042.zip, and it has exactly the same issue.
While I may be missing something, the proposed fix (modifying the raw file) works well.

5
General Discussion / Re: FT813 Custome Font Text
« on: September 11, 2019, 06:12:23 PM »
Hi thank you very much!
BTW, pasting the URL helps, except it then asks for a username and password, and it doesn't accept what I use over here.
Do you have any ideas?

6
General Discussion / Re: FT813 Custome Font Text
« on: September 10, 2019, 06:04:18 PM »
Thank you. The link to BRT_AN_042.zip does not work unfortunately.

Yes it clearly is a issue with the fonts width table, having the widths in the wrong locations.

Rudolph and me follow the standard FTDI API, and we do not handle the width of individual characters, the display does it using the information in the RAW file.
Therefore Rudolph's code can't be blamed anyway.

Looking a bit further,I found this:
In SourceCodePro-Regular.ttf_40_L4.rawh, the below line exactly explains the problem:

/* Widths */
0,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

The list is actually shifted to much to the front, using the index as in the characters file. The display expect the index conform the ASCII values.

This works fine (modified):
/* Widths */
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,

After editing the raw file with a hex-editor and fixing the wrong font-widths, it works!
I changed the values inside the red box from 0x00 to the correct width 0x18 (mono-space font here).

Perhaps the font convert utility can be corrected?
In the mean time I will create my own font convert utility (with GUI).

7
General Discussion / FT813 Custom Font Text
« on: September 07, 2019, 09:09:59 PM »
Hi, I use a custom font.
I ported Rudolph Riedel library (Thank you very much!) to STM32H7 (480MHz) and drive the display using Quad-SPI (4-bit).
For the SD-card, I use the SDMMC (4-bit) interface, and FATFS.

I created the font with command:
fnt_cvt.exe -i SourceCodePro-Regular.ttf -s 40 -u characters.txt -d 1000
The file characters.txt contains this string (excluding the first and last double-quote):
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[|]^_`abcdefghijklmnopqrstuvwxyz{|}~"

When printing strings, all works fine until the printed character value reaches 96, after which the characters are printed over each other (so the cursor-position didn't increment to the next horizontal character position). To illustrate it, I have attached a photo from the screen.

In the top three lines, I first print the characters individually on a calculated (forced) position. That works, all characters are printable.

The fourth line should read as: "0123456789 The quick brown fox jumps over the lazy dog", but problems start beyond character value 96, with the lower case characters, being printed over each other.
The 7th line should read as "abcdefghijklmnopqrstuvwxyz", but shows those characters all printed over each other on one place.
In the last line I take a string with the character 96 somewhere near the end ("XYZ[|]^_`abc"). The first part goes well until character 96.

My code:

Code: [Select]
/*
 * This example shows the use of the SETFONT2 command.
 * Simpler method to load RAM font. Use the font conversion utility to convert the desired
 * subset of the ASCII characters, load font data, and use cmd_setfont2 command.
 * In characters.txt
 *  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[|]^_`abcdefghijklmnopqrstuvwxyz{|}~
 */
void Ft813Setfont40(void)
{
  /*
   * The converted font file will have a starting address of
   * RAM_G or 0th byte mark
   */
  uint8_t FontHandle = 1;
  uint16_t fontFileAddress = RAM_G + 1000;
  uint16_t FontWidth = 22;
  uint16_t FontHeight = 40;

  Ft813DLstart();
  Ft813DL(CLEAR_COLOR_RGB(0, 0, 0));
  Ft813DL(CLEAR(1, 1, 1));
  Ft813DL(COLOR_RGB(255, 255, 255));
  Ft813LoadRawFile(fontFileAddress, "SourceCodePro-Regular.ttf_40_L4.raw");      /* Load font data */
  Ft813SetFont2(1, fontFileAddress, 31);
  /*
   * Set ram font to font handle 1, font metric block starts at fontFileAddress(RAM_G),
   * and set the starting character to the 32th character in the set.
   */
  uint16_t x = 10;
  for(uint8_t i = 0; i < 32; i++)
  {
    char str[2];
    str[1] = 0;
    str[0] = i + 0x20;
    Ft813Text(x, 10, FontHandle, 0, str);
    str[0] = i + 0x20 + 32;
    Ft813Text(x, 10 + FontHeight, FontHandle, 0, str);
    if (i + 0x20 + 64 < 127)    /* Do not print space character (0x20) */
    {
      str[0] = i + 0x20 + 64;
      Ft813Text(x, 10 + FontHeight * 2, FontHandle, 0, str);
    }
    x += FontWidth;
  }

  Ft813Text(10, 10 + FontHeight*4, FontHandle, 0, "0123456789 The quick brown fox jumps over the lazy dog");
  Ft813Text(10, 10 + FontHeight*5, FontHandle, 0, "The quick brown fox jumps over the lazy dog");
  Ft813Text(10, 10 + FontHeight*6, FontHandle, 0, "ABCDEFGHIJKLMNOPQRSTUVWXYZ");
  Ft813Text(10, 10 + FontHeight*7, FontHandle, 0, "abcdefghijklmnopqrstuvwxyz");

  Ft813DL(DISPLAY());         /* Display the image */
  Ft813Swap();                /* Swap the current display list */
  Ft813Flush_Co_Buffer();     /* Download the commands into fifo */
  Ft813WaitCmdFifoEmpty();    /* Wait till coprocessor completes the operation */
}


The function Ft813Text:

Code: [Select]
/* Draw Text: FT81x Series Programmers Guide Section 5.41 */
void Ft813Text(int16_t x, int16_t y, int16_t font, uint16_t options, const char* s)
{
  Ft813StartFunc(FT_CMD_SIZE * 3 + strlen(s) + 1);
  Ft813SendCmd(CMD_TEXT); // 4294967052 = FFFFFF0C
  Ft813SendCmd((((uint32_t) y << 16) | (x & 0xffff)));
  Ft813SendCmd((((uint32_t) options << 16) | (uint32_t) font));
  Ft813SendStr(s);
  Ft813EndFunc();
}
Probably, I'm overlooking something.
Note, in the function Ft813SetFont2, I specified 31 as first character, perhaps there is a limit on the character value of 127.
I hope this helps somebody having the same problems.

8
Discussion - Hardware / Re: FT813 GRAM size 1MB to be increased soon?
« on: September 27, 2018, 09:33:33 AM »
Thank you very much, for the information. The limited 1MB of RAM_G is a deal breaker for us.
We will investigate alternative solutions, as we need to finish the product very soon.
But I'm looking forward to see a new FT82x? product in the future, with more capacity (2MB would probably be sufficient for 800x480 display) of RAM_G, then it would be an amazing display (and unmatched solution)!

9
Discussion - Hardware / Re: FT813 GRAM size 1MB to be increased soon?
« on: September 26, 2018, 02:09:16 PM »
So, the BT815/6 is the solution for that problem?

10
Discussion - Hardware / Re: FT813 GRAM size 1MB to be increased soon?
« on: September 20, 2018, 12:57:00 PM »
The images are first stored on eMMC as .bin files, converted using img_cvt.exe, so I assume they are in ASTC.
So loading saves time, but once loaded into G_RAM, they are inflated, and all we need at the same time does not fit into just 1MB of G_RAM.
We may need several MBs worth of bitmap data to be used on a screen page (it being updated with different images).
With the FT813 this is not possible, right, so we need to wait for the new display to become available?

11
Discussion - Hardware / Re: FT813 GRAM size 1MB to be increased soon?
« on: September 20, 2018, 10:29:47 AM »
Does this mean, I can load multiple images in one screen page, with a total of more than 1MB?
Below I explain the problem:
For a gauge, we like to use several bitmaps:
- the indicator surface plate (800x480 16-bit = 768k),
- two gauge needles (different colors), need to be rotated (480x480 8 bit),
- and a "shiny glass" overlay with opacity (800x480 8-bit).
This would, I think require 1382400 bytes of G_RAM for the FT813 under test.
With the FT813 this is not possible, right?
Would that be possible with BT815/6 series?

12
Discussion - Hardware / Re: FT813 GRAM size 1MB to be increased soon?
« on: September 14, 2018, 10:28:05 AM »
Hi, we also have (16GB) eMMC memory on the (STM32) MCU board, to store images and fonts, however that does not solve the issue of the small amount of available GRAM.
The problem and limitation of this solution is, at the moment we start overwriting parts of the contents of GRAM, we overwrite what is currently shown on the display.
Does the external flash overcome this and directly display the stored bitmaps on it without the need to load it in GRAM first?
Otherwise it is not a solution to the problem. 2MB or 4MB of GRAM would be so much better then.
Today we started looking for competitive solutions for the screen, because of this limitation.

13
Discussion - Hardware / FT813 GRAM size 1MB to be increased soon?
« on: September 12, 2018, 01:24:58 PM »
Hi,
we use a lot of bitmaps, and when bitmaps are displayed, they have to stay in GRAM, so removing them while displaying content is not possible.
Or to do this, we may need to blank the display for a moment, every time we show a new page.
Of course we try to optimize bitmaps and load first what we always need, so we can keep them, while reloading a part of GRAM.
But 1MB of GRAM is a limiting factor to use this display for all our applications.
Is there a chance a new controller will be developed with more GRAM, say 4MB?
Regards,
Jack.

14
Discussion - Software / Re: Timing parameters for EVE modules?
« on: July 08, 2018, 05:11:35 PM »
Hi Rudolph,

this is what I collected:

Code: [Select]
/* Macros for display panels */

// QVGA 320x240
#define FT_DISPLAY_HSIZE_QVGA_320x240           (320L) // DispWidth  display width
#define FT_DISPLAY_VSIZE_QVGA_320x240           (240L) // DispHeight display height
#define FT_DISPLAY_HCYCLE_QVGA_320x240          (408L) // DispHCycle
#define FT_DISPLAY_HOFFSET_QVGA_320x240         (70L)  // DispHOffset
#define FT_DISPLAY_HSYNC0_QVGA_320x240          (0L)   // DispHSync0
#define FT_DISPLAY_HSYNC1_QVGA_320x240          (10L)  // DispHSync1
#define FT_DISPLAY_VCYCLE_QVGA_320x240          (263L) // DispVCycle
#define FT_DISPLAY_VOFFSET_QVGA_320x240         (13L)  // DispVOffset
#define FT_DISPLAY_VSYNC0_QVGA_320x240          (0L)   // DispVSync0
#define FT_DISPLAY_VSYNC1_QVGA_320x240          (2L)   // DispVSync1
#define FT_DISPLAY_PCLK_QVGA_320x240            (8)    // DispPCLK
#define FT_DISPLAY_SWIZZLE_QVGA_320x240         (2)    // DispSwizzle
#define FT_DISPLAY_PCLKPOL_QVGA_320x240         (0)    // DispPCLKPol
#define FT_DISPLAY_DISPCSPREAD_QVGA_320x240     (1)    // DispCSpread
#define FT_DISPLAY_DISPDITHER_QVGA              (1)    // DispDither

// WQVGA 480x272
#define FT_DISPLAY_HSIZE_WQVGA_480x272          (480L) // DispWidth  display width
#define FT_DISPLAY_VSIZE_WQVGA_480x272          (272L) // DispHeight display height
#define FT_DISPLAY_HCYCLE_WQVGA_480x272         (548L) // DispHCycle
#define FT_DISPLAY_HOFFSET_WQVGA_480x272        (43L)  // DispHOffset
#define FT_DISPLAY_HSYNC0_WQVGA_480x272         (0L)   // DispHSync0
#define FT_DISPLAY_HSYNC1_WQVGA_480x272         (41L)  // DispHSync1
#define FT_DISPLAY_VCYCLE_WQVGA_480x272         (292L) // DispVCycle
#define FT_DISPLAY_VOFFSET_WQVGA_480x272        (12L)  // DispVOffset
#define FT_DISPLAY_VSYNC0_WQVGA_480x272         (0L)   // DispPCLKPol
#define FT_DISPLAY_VSYNC1_WQVGA_480x272         (10L)  // DispVSync1
#define FT_DISPLAY_PCLK_WQVGA_480x272           (5)    // DispPCLK
#define FT_DISPLAY_SWIZZLE_WQVGA_480x272        (0)    // DispSwizzle
#define FT_DISPLAY_PCLKPOL_WQVGA_480x272        (1)    // DispPCLKPol
#define FT_DISPLAY_DISPCSPREAD_WQVGA_480x272    (1)    // DispCSpread
#define FT_DISPLAY_DISPDITHER_WQVGA_480x272     (1)    // DispDither

// HVGA 320x480 Portrait
#define FT_DISPLAY_HSIZE_HVGA_480x320          (320L) // DispWidth  display width
#define FT_DISPLAY_VSIZE_HVGA_480x320          (480L) // DispHeight display height
#define FT_DISPLAY_HCYCLE_HVGA_480x320         (400L) // DispHCycle
#define FT_DISPLAY_HOFFSET_HVGA_480x320        (40L)  // DispHOffset
#define FT_DISPLAY_HSYNC0_HVGA_480x320         (0L)   // DispHSync0
#define FT_DISPLAY_HSYNC1_HVGA_480x320         (10L)  // DispHSync1
#define FT_DISPLAY_VCYCLE_HVGA_480x320         (500L) // DispVCycle
#define FT_DISPLAY_VOFFSET_HVGA_480x320        (10L)  // DispVOffset
#define FT_DISPLAY_VSYNC0_HVGA_480x320         (0L)   // DispPCLKPol
#define FT_DISPLAY_VSYNC1_HVGA_480x320         (5L)   // DispVSync1
#define FT_DISPLAY_PCLK_HVGA_480x320           (4)    // DispPCLK
#define FT_DISPLAY_SWIZZLE_HVGA_480x320        (2)    // DispSwizzle
#define FT_DISPLAY_PCLKPOL_HVGA_480x320        (1)    // DispPCLKPol
#define FT_DISPLAY_DISPCSPREAD_HVGA_480x320    (1)    // DispCSpread
#define FT_DISPLAY_DISPDITHER_HVGA_480x320     (1)    // DispDither

// ME812A-WH50R, ME812AU-WH50R, ME813A_WH50C, ME813AU_WH50C
// WVGA 800x480
#define FT_DISPLAY_HSIZE_WVGA_800x480           (800L) // DispWidth  display width
#define FT_DISPLAY_VSIZE_WVGA_800x480           (480L) // DispHeight display height
#define FT_DISPLAY_HCYCLE_WVGA_800x480          (928L) // DispHCycle
#define FT_DISPLAY_HOFFSET_WVGA_800x480         (88L)  // DispHOffset
#define FT_DISPLAY_HSYNC0_WVGA_800x480          (0L)   // DispHSync0
#define FT_DISPLAY_HSYNC1_WVGA_800x480          (48L)  // DispHSync1
#define FT_DISPLAY_VCYCLE_QVGA_800x480          (525L) // DispVCycle
#define FT_DISPLAY_VOFFSET_WVGA_800x480         (32L)  // DispVOffset
#define FT_DISPLAY_VSYNC0_WVGA_800x480          (0L)   // DispVSync1
#define FT_DISPLAY_VSYNC1_WVGA_800x480          (3L)   // DispVSync1
#define FT_DISPLAY_PCLK_WVGA_800x480            (2)    // DispPCLK
#define FT_DISPLAY_SWIZZLE_WVGA_800x480         (0)    // DispSwizzle
#define FT_DISPLAY_PCLKPOL_WVGA_800x480         (1)    // DispPCLKPol
#define FT_DISPLAY_DISPCSPREAD_WVGA_800x480     (0)    // DispCSpread
#define FT_DISPLAY_DISPDITHER_WVGA_800x480      (1)    // DispDither

Then you could maybe use something like this to select the correct block, depending on the display panel.

Code: [Select]
//#define ME800A_HV35R (1)  // 480x320
//#define ME810A_HV35R (1)  // 480x320
//#define EVE2_43G (1)  // 480x272
//#define ME812A_WH50R (1)  // 800x480
//#define ME812AU_WH50R (1)  // 800x480
#define ME813A_WH50C (1)  // 800x480
//#define ME813AU_WH50C (1)  // 800x480
//#define ME810A_WH70R (1)
//#define ME811A_WH70C (1)

#if defined(EVE2_43G)
#define my_DispWidth    FT_DISPLAY_HSIZE_WQVGA_480x272
#define my_DispHeight   FT_DISPLAY_VSIZE_WQVGA_480x272
#define my_DispHCycle   FT_DISPLAY_HCYCLE_WQVGA_480x272
#define my_DispHOffset  FT_DISPLAY_HOFFSET_WQVGA_480x272
#define my_DispHSync0   FT_DISPLAY_HSYNC0_WQVGA_480x272
#define my_DispHSync1   FT_DISPLAY_HSYNC1_WQVGA_480x272
#define my_DispVCycle   FT_DISPLAY_VCYCLE_WQVGA_480x272
#define my_DispVOffset  FT_DISPLAY_VOFFSET_WQVGA_480x272
#define my_DispVSync0   FT_DISPLAY_VSYNC0_WQVGA_480x272
#define my_DispVSync1   FT_DISPLAY_VSYNC1_WQVGA_480x272
#define my_DispPCLK     FT_DISPLAY_PCLK_WQVGA_480x272
#define my_DispSwizzle  FT_DISPLAY_SWIZZLE_WQVGA_480x272
#define my_DispPCLKPol  FT_DISPLAY_PCLKPOL_WQVGA_480x272
#endif

#if defined(ME800A_HV35R) || defined(ME810A_HV35R)
#define my_DispWidth    FT_DISPLAY_HSIZE_WQVGA_480x272
#define my_DispHeight   FT_DISPLAY_VSIZE_WQVGA_480x272
#define my_DispHCycle   FT_DISPLAY_HCYCLE_WQVGA_480x272
#define my_DispHOffset  FT_DISPLAY_HOFFSET_WQVGA_480x272
#define my_DispHSync0   FT_DISPLAY_HSYNC0_WQVGA_480x272
#define my_DispHSync1   FT_DISPLAY_HSYNC1_WQVGA_480x272
#define my_DispVCycle   FT_DISPLAY_VCYCLE_WQVGA_480x272
#define my_DispVOffset  FT_DISPLAY_VOFFSET_WQVGA_480x272
#define my_DispVSync0   FT_DISPLAY_VSYNC0_WQVGA_480x272
#define my_DispVSync1   FT_DISPLAY_VSYNC1_WQVGA_480x272
#define my_DispPCLK     FT_DISPLAY_PCLK_WQVGA_480x272
#define my_DispSwizzle  FT_DISPLAY_SWIZZLE_WQVGA_480x272
#define my_DispPCLKPol  FT_DISPLAY_PCLKPOL_WQVGA_480x272
#endif

#if defined(ME813A_WH50C) || defined(ME813AU_WH50C) || defined(ME812A_WH50R) || defined(ME812AU_WH50R)
#define my_DispWidth    FT_DISPLAY_HSIZE_WVGA_800x480
#define my_DispHeight   FT_DISPLAY_VSIZE_WVGA_800x480
#define my_DispHCycle   FT_DISPLAY_HCYCLE_WVGA_800x480
#define my_DispHOffset  FT_DISPLAY_HOFFSET_WVGA_800x480
#define my_DispHSync0   FT_DISPLAY_HSYNC0_WVGA_800x480
#define my_DispHSync1   FT_DISPLAY_HSYNC1_WVGA_800x480
#define my_DispVCycle   FT_DISPLAY_VCYCLE_QVGA_800x480
#define my_DispVOffset  FT_DISPLAY_VOFFSET_WVGA_800x480
#define my_DispVSync0   FT_DISPLAY_VSYNC0_WVGA_800x480
#define my_DispVSync1   FT_DISPLAY_VSYNC1_WVGA_800x480
#define my_DispPCLK     FT_DISPLAY_PCLK_WVGA_800x480
#define my_DispSwizzle  FT_DISPLAY_SWIZZLE_WVGA_800x480
#define my_DispPCLKPol  FT_DISPLAY_PCLKPOL_WVGA_800x480
#endif

Hope this helps.

If somebody has more definitions, let us collect them Rudolph's thread.

Kind regards,
Jack.

15
This is very useful information! Thank you very much!

Pages: [1] 2 3