https://github.com/RudolphRiedel/FT800-FT813

This does not sound like it but the current version of my library actually supports FT810 to BT817.
The file EVE_config.h has timings for most modules with EVE chips on them.
And there is support for quite a number of controllers, Arduino and Bare-Metall, a few with DMA.

What I only barely started though is export support to ESE.

To wrap this up, I tested this with the RVT50HQBNWC00-B now as well.
And the display list itself really is not the limiting factor.
I currently have it running with 6 LINE_STRIP blocks of 265 segments each.
Plus another block of 170 segments.

The list gets transmitted in two blocks via DMA of 7432 bytes combined and the resulting display list
is 7948 bytes long.


The limiting factor really is not that the display-list can not be bigger than 4 kiB,
but the complexity of the display list per line and how much time EVE has to throw out pixels per line.
Much like the bandwidth of the external flash is a limiting factor so displaying images directly from flash should be used sparingly if not avoided alltogether.
And using fonts from flash is actually displaying images as well, at least we have CMD_FONTCACHE to help with that (but only for a single font).

So we need to put things in RAM_G, especially at resolutions of 800x480 or beyond.
And we have ASTC to help with that, using ASTC 8x8 with only 2 bits per pixel brings down full color images with alpha channel to 1/8 of ARGB1555.

Then EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500); gives EVE more flexibility with the timing.

And the last measure would be to reduce pixel-clock and therefore the framerate.

i replaced STRIPLINE through POINTS and also LINES.

Well, both require less computations in EVEs graphics backend,
i can totally see that making a difference.

I merely changed the precision to remove the multiplications on the controller side.

My value for EVE_HCYCLE is also 1344.

This made it much better:
Code: EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);

Also i don't understand what it does?

This allows EVE to extend lines by additional clock cycles and there gives it more time to compute the display-list.


Here is something weird though.
I calculated the time per line in µs based on HCYCLE and the pixel clock.
EVE3_43G: 53.278 µs
EVE3_50G: 25.778 µs
RVT50H: 34 µs
RVT70H: 26.353 µs
RVT101H: 20.282 µs

So actually the BT817 on the RVT70H with 1024x600 has more time per line than the EVE3_50G.
I am using the EVE3_50G with 36 MHz pixel-clock due to limited options to setup the pixel-clock with the FT81x and BT815/BT816, the value for HCYCLE is 928.
On the RVT70H the line is much longer with 1344 and I am using a pxiel clock of 51 MHz.

The time per visible pixel is lower for the RVT70H though - if that even is a valid concern.


I ordered a RVT50HQBNWC00-B as I do not have a BT817 with 800x480 so far.
And I will test what happens when I lower the frame-rate by reducing the pixel-clock.


Edit: I played with it some more.
Now I am using two DMA transfers to reduce the time for the actual transfer, just to make sure
everything is within my intended timing of 50 changes per second.

And I was wrong before, 190+190+190+190+150 is not the limit.
I have it currently running with 6 x 255 Segments, the size of the display-list is 7400 bytes.
The frames per second actually dropped from 60 to 57/58 - which is to be expected when EVE is allowed to lengthen the lines to compensate for more complex lines.

The complexity per line is key.
When I change the last block to overlapped with these before -> tilt.

>i'm testing a MicroChip PIC32 EV-board

I would be interested in the target code for this one since I do not have any code for PICs so far.
Never found these attractive, I do not like MPLAB-X at all and Platformio "only" supports the Arduino framework for PIC32.


I just tried this with an EVE3-50G connected to an ESP32-S3 as I had this already connected.
And I pushed it to 5x 365 Line-Strip Segments filling the display-list with 8176 bytes with the attached souce,
this is for everything, the whole display-list.

I modified my basic demo for this:
EVE_color_rgb(RED);
EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
for(uint16_t i = 0 ; i < 365 ; i++ )
{
    if( i % 2 )
    {
        EVE_cmd_dl(VERTEX2F( i, LAYOUT_Y1));
    }
    else
    {
        EVE_cmd_dl(VERTEX2F( i, LAYOUT_Y1 + 50));
    }
}

EVE_cmd_dl(DL_END);

Now there are a few things to mention.
Usually I am using DMA which limits the amount of bytes that can be send to 4k as the FIFO "only" is 4k.
This is not really an issue since under normal conditions as the display-list is composed by the co-processor with commands like CMD_BUTTON, CMD_TEXT or CMD_NUMBER which need more bytes in the display-list than in the FIFO.
Try this in EVE Screen Editor, add 19 buttons for example and RAM_DL shows around 50%, depending on where the buttons are placed (less with coordinates below 511).
But this is not under normal conditions and you are not using DMA so I switched if off as well for the 5x 365.


With DMA on I just pushed it to 190 per color which resulted in 4076 bytes for the FIFO and 4688 bytes for the display-list.
Using two or more segments to push more than the 4k out by DMA to the FIFO is possible, but beyond the scope right now.

Next thing is that you might be missing an EVE_cmd_dl(DL_END); line.

The EVE_execute_cmd(); lines in between the segments in your version are not doing anything in this context.
All this does is to wait for the FIFO to be empty but since every command is executed on it's own with a separate chip-select cycle and VERTEX2F is just copied over from the FIFO to the display-list by the co-processor, the FIFO is always empty anyways.

And at last this is awfully slow.
The time in the image is wrong, I limited the digits to 4 and num_profile_a was "only" 16 bits.
I consider over 2ms to be not viable for my applications.
With 32 bits and 6 digits I get 118680µs now (ouch), this is for the whole TFT_display() function.
This is mostly for the transfer without DMA (adds 3 bytes overhead) at 10MHz using the ESP32-S3.

And a smaller part is from calculating VERTEX2F since X is at bit 15...29.

Segments of 190 without DMA: 63510µs
Segments of 190 with DMA: 348µs and the SPI transfer itself needs 2069µs.
No segments with DMA: 44µs
So calculating 950 VERTEX2F needs about 300µs - and that is on a 32 bit controller clocked 240MHz.

This still does not answer why it crashes for you and I still need to test this with a BT817.
I am fairly certain though this is neither on my side or the fault of the BT817.

(wall of text deleted again)

What are you actually trying to do?

Note that for EVE_cmd_flashupdate(uint32_t dest, uint32_t src, uint32_t num) the destination needs
to be 4096 byte aligned, the source needs to be 4 byte aligned and the number of bytes needs to be a
multiple of 4096.

I posted this yesterday and somehow it got lost.
I asked about your SPI clock and if you tried to lower it.

I am seeing this with my hardware as well, in the last test I conducted I got to 17MHz before touch stopped working
but could use 40MHz just fine for the writes.

What does your hardware up to the FFC connector look like?
I am using one of these https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08
And this one may work a bit higher for the reads.

My guess is that the turnaround-delay is getting too high between the clock-signal and MISO, especially with glue-logic in between.

For simple buttons I just use rectangles with text on them and change the color when pressed.
And by changing the line-width you can have rectangles with rounded corners.

For EVE Screen Editor:
CLEAR(1, 1, 1)
TAG(100)
LINE_WIDTH(100)
BEGIN(RECTS)
COLOR_RGB(255,255,100)
VERTEX2F(3376, 2896)
VERTEX2F(5264, 3776)
END()
COLOR_RGB(0,0,0)
CMD_TEXT(223, 195, 28, 0, "My Button")
TAG(0)