My additional points would be:

VERTEX2F:
http://www.brtcommunity.com/index.php?topic=10.0

Variants with LVDS interface.

A whole lot more bitmap handles. Like 256 in total.

Additional graphics primitives:
Circle - this needs two POINTS now
Box - like drawing two overlapping RECTS

>Posted by: FlorianG
>The first is the screen resolution.

Well, in theory EVE already supports 2048x2048 pixels. :-)
So to take this point all by itself I would argue that this already is plenty. :-)
But more seriously, yes, I would like to use a panel like this:
https://www.winstar.com.tw/de/products/tft-lcd/ips-tft/ips-lcd.html
In case the link does not work, this is a WF101GTYAPLNG0, a 10.1" LVDS IPS 1280x800.
And this is just the first thing I find with Googe and "ips tft".

>The second is a customizable clock frequency.

The clock frequency already is customizable.
But given the rest of your point it looks like you rather wish for a substantial increase in clock frequency in
order to run higher resolution panels at high framerates.
And yes, I totally agree with this.
What is a bit strange is the pixel clock setup in REG_PCLK as fractions of the main clock.
I guess these need to be in sync but the divider does not really work for higher clocks.
72MHz, 36MHz, 24MHz, 18MHz, 14,4MHz, 12MHz, 10,3MHz
This is perfectly fine for small displays needing low clock rates.
But there is no way to setup 48MHz for example.
Maybe a second PLL would help with this issue.

>The last point is about the memory size of the "RAM_CMD" and the "RAM_DL"

I agree, although even double the amount would be nice, so 16kB and 8kB.


Posted by: darkjezter
>Ability to sidestep RAM_DL contention. 

Seriously?

I have found the solution  :

Ft_Gpu_CoCmd_MemWrite(disp_host, RAM_G+Offset, fileSize); // EVE upload with the filesize initialize

while()
{
...
Ft_Gpu_Hal_WrCmdBuf(phost, imageBuffer, blockLen); // write data in the command buffer
...
}

// END COPY FILE TO EVE
    Ft_App_WrCoCmd_Buffer(disp_host, BEGIN(BITMAPS));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_HANDLE(0));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SOURCE(RAM_G+Offset));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_LAYOUT(RGB565, 100*2, 50));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SIZE(NEAREST, BORDER, BORDER, 100, 50));
    Ft_App_WrCoCmd_Buffer(disp_host, VERTEX2II(0, 0, 0, 0));
    Ft_App_WrCoCmd_Buffer(disp_host, END());

Hi,

I try to upload some RAW graphic files to the GRAM of the FT800.
It is some old project that needs a gui update. Until now I had only one jpeg sucessfully loaded with CMD_LOADIMAGE, this works but now I need to place several graphics in raw (RGB565) format.

When using a jpeg there is the load_image command before loading the file into the command buffer.
But I can't find any command for raw

The commands to handle the image when its already in the ram are quite clear to me:

Ft_App_WrCoCmd_Buffer(disp_host, BEGIN(BITMAPS));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_HANDLE(id));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SOURCE(RAM_G + offset));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_LAYOUT(RGB565, 100, 50));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SIZE(NEAREST, BORDER, BORDER, 100, 50));
Ft_App_WrCoCmd_Buffer(disp_host, VERTEX2II(0, 0, id, 0));

But how do I put the bitmap to the position (RAM_G + offset) in VRAM?

I had tryed Ft_Gpu_Hal_WrMem(phost, (RAM_G + Offset), ....) but it doesn't work.

I will be grateful for any advice!

Best regards,
Philipp

Based on my own experiences with the BT816:

Control over built-in widget theming (drop shadow on fonts, 3d edges/corners, etc)

Ability to sidestep RAM_DL contention.  This one is a bit open-ended, but in a nutshell, RAM_DL is used both for preparing a new display list (and thus becomes unavailable when a swap is pending), and also for the construction of co-processor widgets.  This is the only case where I've found any issues overrunning the command FIFO.  The most powerful solution would be allowing the coprocessor to target an arbitrary RAM_G location for widget construction, however I have also explored aborting pending swap requests if the commands queued in RAM_CMD are no longer required.

Resistive touchscreen pressure measurement fixes.  After digging into an issue where the touchscreen reports touch events that do not correspond to actual events I found that the pressure measurement will successfully report a touch pressure when the analog measurement never settled during the measurement interval.  As pressure is the only configurable threshold to distinguish between touch and no-touch events, this leads to pressure thresholds that must be far less sensitive then the hardware would actually allow.  This issue allows X&Y coordinates that deviate from actual points of touch to be reported by the EVE in the case where the pressure measurement failed to stabilize.  Making use of the existing oversampling parameter to determine if the measurement did in fact settle to a valid reading would greatly improve this chip's touch reporting.

I can probably come up with some more suggestions, but I would have to say these are my big 3.

Cheers!

Hello everyone,

I propose this new topic in order to give us want / need about the new generation of chip "EVE" which I hope is already in the process of preparation
The current EVE BT81x are good but I'm sure Bridgetek can still boost

For my part I think there is 3 something that the new generation can improve. (In addition to always having more power and why not more features for 3D )

The first is the screen resolution. I would say that HD with 1 megapixel on the screen is the priority point.
But in the circumstance that the chips start to be used in time as GPU HDMI as for example with the project of GD3X HDMI of James Bowman the full hd can be very interesent. Maybe even the 4K, let's go crazy   

The second is a customizable clock frequency. in this way it would be easier to achieve the best performace of the screen use. And in addition to that overclock the chip to exceed 60 ip / s  .
I know that it was not all the objective of this chip but for some people (and I think the arduino community that pushes further and further the limits of the material) it can be very very interesent

The last point is about the memory size of the "RAM_CMD" and the "RAM_DL" which are not great in view of the fact that the memory of the bt81x and 4 times larger than the FT801.
Not to mention the fact that we can multiply it again by 256.
The ideal would be at least 64KB instead of 4KB.

Here is my list, if you want to add or discuss some point this topic is made for this 

Hello,

Thanks for your question, I have referred this to the development team who are better suited to answering your queries.

In the meantime the user guide can be found here:
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/Modules/EVE/ESD-User-Guide-4.8.pdf

Best Regards,
BRT Community

I'm new to ESD and I'm looking for advice to create a display something like a radar display, where i need place between 0 and N spots on the screen and position and render these according to incoming data from an external source unrelated to Eve Code.

Each spot is independent from the others. I can kind of achieve this by creating a fixed number of ESDCircle widgets offscreen and linking each independently with their own unique  ESD_FUNCTION as shown in the attached pic

However this feels very inefficient as I need 6 unique functions for each of my N spots.

Is there are more effective/efficient way of achieving this result?

Is there any way of defining an array of widgets? If so how is indexing determined?
Within an ESD based project, can I dynamically add and manage widgets through external code?
Can I create a custom ESD_FUNCTION that would set all my parameters in one call? (valid,x,y,w,h,col)

Thanks in advance

There is a new EVE Asset Builder - v1.2.0 - and I like it. 

With regards to this thread it is now possible to set the tiling manually or disable it entirely.
Thanks!

Also interesting is the option to feed it GIF animations.

Okay, I received a new EVE3-50G today and have it up and running.

The good news is, I have no problem at all displaying the full set of 28 different icons directly from flash
with this display.

The bad news is, I still have no idea why it fails on the other display with the same resolution using the same code with an identical micro-controller and using the same pins.

With the EVE3-50G I can attach a USB adapter and flash from EVE Asset builder.
This works fine.
And erasing the flash and re-writing it from my Controller like I had to with the other displays also works fine.

There is a W25Q128JVSIQ FLASH on the display that fails and a 25Q32JVSIQ on the EVE3-50G.
The BT815 on the display that fails is labeled: K1COK BT815Q 1905-A
The BT815 on the EVE3-50G is labeled: K61TL.03 BT815Q 1842-A

And just for reference, I bought a chip from DigiKey that also is labeled like the on the EVE3-50G.
And the one on the RVT43 I have from Riverdi is labeled: K61TL.13 BT815Q 1802-A

So the "wafer lot number" looks different on the BT815Q from the display that fails but it still is
a revision "A" chip so it should just behave like the one on the EVE3-50G.

Whatever the heck is going on there?

Hello,

I will consult the development team, but currently I don't believe there is any support for creating portrait display projects within ESD.

Best Regards,
BRT Community