@scoprioprise

I was finally able to get something working. I started a new clean project and was able to get my external data to display using the following method.

Create a custom function such as

static int my_val;
ESD_FUNCTION(ReadValue, Type = int )
ESD_PARAMETER(val, Type = int)
int ReadValue(int val)
{
        // update my_val in your own custom way
my_val++;
return my_val;
}

In this i just increment a value but you can inside of this call something external like int GetMySensorData().

The trick is to link this to your widget (I attached the logic view). You'll need a new function for each value you want to represent.


Once you've done this (I think) the function is called whenever the framework requires the widget value. Its therefore important the call completes quickly, eg just call the getter on a variable. just replace the sample ++ with your GetMySensorData() and return the value.



Whats odd is that I had tried this previously on my original EVE project but didnt seem to get anywhere? hence i got more and more confused?
Whats even more odd is my VM810 devkit has completely died today, fails to read the CHIPID and reset value registers??? I just get zero whatever I do....

Since it already is within my Library I just tried it myself here now. 

My mobile is not really capturing it nicely but as you can see in my picture I got it to work.
Check the four numbers under the table, this is my debug output.
This means:
2068 bytes send over SPI
4248 bytes in the resulting display-list
1036 µs to compose the image
26 µs spent for the touch function

So this is only half the FIFO in use and only half the display list filled.
I put all the parts you posted into a single display list.

For the static part that you use with EVE_cmd_append() I could only guess and just put
the drawing of the 5 red lines plus printing the text there.

Likewise, what "{FT813_ShowHex(30 + temp_c*75, Y, Data[temp_c],     2,28,0,ORANGE);}" is actually doing could be hiding what might be your issue.

I translated that into:
EVE_cmd_setbase(16L);

Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++)
{
EVE_cmd_dl(DL_COLOR_RGB | ORANGE);
EVE_cmd_number(30 + temp_c*75, Y, 28, 2, Data[temp_c]);
}
...
EVE_cmd_setbase(10L);

And at first I left out setting the color but then I thought you might be wanting to set the color
for each cell individually based on the values.

This I commented out:
EVE_cmd_dl(SCISSOR_XY(0,0));
EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
EVE_cmd_dl(CLEAR(1,1,1));

This really is pointless after "EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);"


Optimising, well.

I would draw the line-grid in the static part.
Or well, yes, as suggested, just use a picture for the table - and display the picture in the static part.
However, not drawing the grid at all gives me this debug output: 1872 4048 932
That saves a little but printing the 80 numbers is what really is filling the list.

Setting the color only once to orange (while again drawing the grid) results in: 1748 3924 855

So lets see what really is going on there.
Open the EVE Screen Editor and enter:
CLEAR(1, 1, 1)
CMD_SETBASE(16)
CMD_NUMBER(572, 272, 28, 0, 42)
CMD_NUMBER(597, 311, 28, 0, 68)

When you switch from the "Coprocessor" tab to the "Inspector" tab you see that these lines are translated into:
Raw Text
0 0x26000007 CLEAR(1, 1, 1)
1 0x22000000 SAVE_CONTEXT()
2 0x27000002 VERTEX_FORMAT(2)
3 0x0500001c BITMAP_HANDLE(28)
4 0x1f000001         BEGIN(BITMAPS)
5 0x06000032 CELL(50)
6 0x44780440 VERTEX2F(2288, 1088)
7 0x06000041 CELL(65)
8 0x44900440 VERTEX2F(2336, 1088)
9 0x23000000 RESTORE_CONTEXT()
10 0x22000000 SAVE_CONTEXT()
11 0x27000002 VERTEX_FORMAT(2)
12 0x0500001c BITMAP_HANDLE(28)
13 0x1f000001         BEGIN(BITMAPS)
14 0x06000034 CELL(52)
15 0x44aa04dc VERTEX2F(2388, 1244)
16 0x06000034 CELL(52)
17 0x44c204dc VERTEX2F(2436, 1244)
18 0x23000000 RESTORE_CONTEXT()

So while conveniant, this creates quite some redundant code, that is just the price for it.

To aoid using cmd_number we can easily break this down to:
CLEAR(1, 1, 1)
VERTEX_FORMAT(2)
BITMAP_HANDLE(28)
BEGIN(BITMAPS)
CELL(50)
VERTEX2F(2288, 1088)
CELL(65)
VERTEX2F(2336, 1088)
CELL(52)
VERTEX2F(2388, 1244)
CELL(52)
VERTEX2F(2436, 1244)
END()

Also, why cmd_number() is using VERTEX_FORMAT(2) eludes me, we can as well use VERTEX_FORMAT(0).
The coordinates can be fixed, its like VERTEX2F(collum, row) / VERTEX2F(collum+12, row).
That leaves the CELL() commands and these are just ASCII values.
CELL(50) : "2"
CELL(65) : "A"

Okay, lets see what happens.

uint8_t hex_table[] = "0123456789ABCDEF";

EVE_cmd_dl(BITMAP_HANDLE(28));
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);

Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++)
{
EVE_cmd_dl(DL_COLOR_RGB | ORANGE);

EVE_cmd_dl(CELL(hex_table[Data[temp_c] >> 4]));
EVE_cmd_dl(VERTEX2F(30 + temp_c*75, Y));

EVE_cmd_dl(CELL(hex_table[Data[temp_c] & 0x0f]));
EVE_cmd_dl(VERTEX2F(42 + temp_c*75, Y));
}
...
EVE_cmd_dl(DL_END);

The result is: 2060 3104 1273

So compared to the original result we have pretty much the same amout of bytes we need to write out by SPI.
The display-list shrinks from 4248 bytes to 3104 bytes - which is quite a lot.
The time to compute this however increases from 1036 µs to 1273 µs.

And it looks exactly the same.

Hi qwerty100,
I faced the very same problem, but I based all exporting the EVE project, not using freeRTOS.
I've posted into  http://www.ftdicommunity.com/index.php?topic=146.msg541#msg541 , it's a "hacked" way of doing this....
Hope this helps

Hello,

You can only display one display list at a time with EVE although you can use the append technique as you have done to allow screen updates without re-sending all data. There is a limit of 8Kbytes for the display list.

Note that this is the actual RAM_DL content rather than the number of bytes of co-processor commands as some co-processor commands generate more bytes of RAM_DL instructions than the command itself. Also, note that this total also includes any appended commands and so ensure to count any appended data too.

You can send several blocks of co-processor instructions but you should only have your DISPLAY and SWAP at the end of the last block and begin the first block with a DL_START. Therefore even if you split the commands into several blocks, the result will still be one list in RAM_DL.

If you want to check if you are running out of RAM_DL, you can check the REG_CMD_DL register after executing a set of one or more commands. This register defines where the next RAM_DL entry will be put by the co-processor and so you can check when your list is approaching the limit.

RAM_DL always defines what is actually on the screen whereas RAM_CMD commands will be executed and will result in RAM_DL instructions being generated.

If your issue is running out of RAM_DL, you could consider making some lines or other items into bitmaps as these can be displayed with only a few commands. Your entire table could be make with an L1 bitmap and then just add the text values afterwards.

Best Regards, BRT Community

Hello, community!
I am only new in EVE, now I am connecting the first my screen with FT813.
Can someone explain me, how to display several coprocessor display lists on one screen. Unfortunately, I couldn’t understand this from the EVE FT81x programming guide.
I need to displays many text data and draw couple diagrams. And I came to the fact that everything I want to display does not fit in one display list. When I try to execute one display list, and then without giving the CMD_SWAP command, load and execute the second display list, I get a completely broken image on the screen.
Here is a display function that is called every 20 ms (I simplified it). Please tell me what's wrong with it!
void TFT_loop(void)
{
   uint8_t temp_c;
uint16_t temp_16;
// uint32_t temp_32;
uint16_t Y;
static uint8_t Data[128];

if(tft_active != 0) {

      for (temp_c = 3;temp_c < 77;temp_c++) {Data[temp_c] = temp_c;}
Data[0]++;
Data[1] += 2;
Data[2] += 3;

Data[77] += 3;
Data[78] += 2;
Data[79] += 1;

  //------
//FT813_StartDisplayList();
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
   EVE_cmd_dl(CMD_DLSTART); /* start the display list */
   EVE_cmd_dl(VERTEX_FORMAT(0)); /* reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */
   EVE_cmd_dl(TAG(0));
//------
//FT813_ClearScreen(0x00505050);
EVE_cmd_dl(CLEAR_COLOR_RGB(0x50,0x50,0x50));
    EVE_cmd_dl(SCISSOR_XY(0,0));
   EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
      EVE_cmd_dl(CLEAR(1,1,1));
//------
EVE_cmd_append(MEM_DL_STATIC, num_dl_static); /* insert static part of display-list from copy in gfx-mem */
//------
Y = 50;
//------
//for (temp_c = 0;temp_c < 9; temp_c ++) { FT813_ShowLine(0,temp_c*40 + Y,749,temp_c*40 + Y,16,WHITE);}
EVE_cmd_dl(LINE_WIDTH(16));
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_dl(DL_BEGIN | EVE_LINES);
for (temp_16 = 0;temp_16 < 9; temp_16 ++) {
EVE_cmd_dl(VERTEX2F(11, Y + temp_16*40));
EVE_cmd_dl(VERTEX2F(759,Y + temp_16*40));
}
EVE_cmd_dl(DL_END);
//------
//for (temp_c = 0;temp_c < 11; temp_c ++) { FT813_ShowLine(temp_c * 75,Y,temp_c * 75,Y + 320,16,WHITE);}
EVE_cmd_dl(LINE_WIDTH(16));
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_dl(DL_BEGIN | EVE_LINES);
for (temp_16 = 0;temp_16 < 11; temp_16 ++) {
EVE_cmd_dl(VERTEX2F(10+temp_16*75,Y+1));
EVE_cmd_dl(VERTEX2F(10+temp_16*75,Y + 320));
}
EVE_cmd_dl(DL_END);
//--------------------------------------------------
Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[temp_c],     2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[10 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[20 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[30 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[40 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[50 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[60 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[70 + temp_c],2,28,0,ORANGE);}
Y += 40;
//==================================================

//------
EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
   EVE_cmd_dl(CMD_SWAP); /* make this list active */
   EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
   EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
while (EVE_busy()) {;}

//---------------------------------------------------
EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART); /* start the display list */
   EVE_cmd_dl(VERTEX_FORMAT(0)); /* reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */
   EVE_cmd_dl(TAG(0));
//------
EVE_cmd_dl(CLEAR_COLOR_RGB(0x50,0x50,0x50));
    EVE_cmd_dl(SCISSOR_XY(0,0));
   EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
      //EVE_cmd_dl(CLEAR(1,1,1));
//==================================================

EVE_cmd_dl(DL_COLOR_RGB | GREEN);
EVE_cmd_text(10,390,23,0,"Font 23: Quick brown fox jumps over a lazy dog 0123456789");
EVE_cmd_dl(DL_COLOR_RGB | BLUE);
EVE_cmd_text(10,410,24,0,"Font 24: Quick brown fox jumps over a lazy dog 0123456789");
EVE_cmd_dl(DL_COLOR_RGB | YELLOW);
EVE_cmd_text(10,440,25,0,"Font 25: Quick brown fox jumps over a lazy dog 0123456789");
//--------------------------------------------------
EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl(CMD_SWAP); /* make this list active */
EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
//=======================================================================================
while (EVE_busy()) {;}
}

}


And here is what I want it to display:


And what I get, instead:

I'm using Eve Screen Designer 4.6 (on an FT810) and have the system integrated into my own embedded CPU setup. The Framework is running as a FreeRTOS task. I have other tasks managing a range of sensors and I want to reflect the sensor data onto the GUI.

I can display the widgets, create internal time based animations via the GetMilliseconds node, and using a custom User Function, pass output data to the rest of my system.

What I'm struggling with is how to bring external sensor data INTO the framework. The examples are very much stand alone I've not found a case where this is shown.


I'm assuming on an Update, I'd somehow call a user function that reads the values I wish to display, sets these to "Variables" and after that I'm OK with getting them rendered.

Alternatively the generated code provides a PageName__Set_VaiableName__ESD() call but these are only valid during simulation and not exported. It also requires knowledge on the context pointer which I'm guessing should not be used outside of the framework internals?


Can someone please provide an example or explain the correct way I should do this.


Many Thanks.

 

First, "CMD_FLASHDETACH → CMD_FLASHATTACH → CMD_FLASHERASE → CMD_FLASHFAST cycle"  is not feasible because after flash is erased

You're right. I fixed my post by adding an extra CMD_FLASHWRITE(unified.blob).

Secondly,  at my side,  with your code logic, cmd_flashread can read the flash sector correctly
after cmd_flasherase is done.   The buffer is filled with 0xFF, not 0x55.

If your run the code again, what do you read? 0xFF or the older FLASH content?

In my test I didn't switch off the board, rather I started over and sent a RST_PULSE host command before accessing the FLASH again.

First, "CMD_FLASHDETACH → CMD_FLASHATTACH → CMD_FLASHERASE → CMD_FLASHFAST cycle"  is not feasible because after flash is erased , it is in Basic mode and there is no way to way to go back the full speed mode,  due to the lack of flash driver(known as blob).  The flash erase
will write every bytes of the whole chip into 0xFF. 
So you shall not run the cycle again and again.

Secondly,  at my side,  with your code logic, cmd_flashread can read the flash sector correctly
after cmd_flasherase is done.   The buffer is filled with 0xFF, not 0x55.

Hi,

I also asked at NHD forum:
https://www.newhavendisplay.com/NHD_forum/index.php/topic,12110.0.html

We have NHD-3.5-320240FT-CSXN-CTP, and want to use it with a Toradex Colibri iMX6 module. A Qt/C++ application will run and control the display.

I tried the designer, but I dont know what target platform should I select.

Can we use EVE Screen Designer to generate source code for Qt/C++ ?
How can I integrate generated codes in to Qt project ?

Thanks

If you are not using the full unicode font characters,  you shall define your own set of characters to be used in your application.  It can minimize the size of font data.  Here is the screenshot of
EAB. Try to use ASTC8x8 or ASTC10x10 to see if the quality meets your needs and it saves the space too.

Hope it is helpful for you.