can try to play "mute" to get the AUDIO_L pin low:

write 0x60 (mute) to REG_SOUND.

It should make AUDIO_L pin low...

Thanks mmottola. Your tip works well.

That example was only an approximation with simple mathematics, the editor can only handle basic things, more advanced examples can be achieved with relatively few instructions, but with slightly more complex mathematics that must consider that the TFT has the Y axis reference frame on the contrary, we must not forget that the EVEx graphics chip does all the drawing work, leaving the MCU only the calculation part.

MCU: teensy 3.6
TFT: NHD 5" FT813
Library: GDSTx (2023)
https://www.youtube.com/watch?v=LmyN9tgATtc

MCU: Nucleo STM32F767ZI
TFT: Riverdi FT813 5"
https://www.youtube.com/watch?v=Yb60PmJu5S0

MCU: Arduino Due
TFT: 4DSystem FT843 4.3" (FT800)
Library: gameduino 2
https://www.youtube.com/watch?v=FOhaWL84bKU

Well, I did not write that the code is not working, I wrote that the code presented is the worst solution for the issue, it still is a solution.
The examples look fancy but there is no source-code for the first and the third.
And while there is an archive with code for the second, I can not get GD3_Gauge_NG_3.rar to compile in the Arduino IDE 1.x and it is not even using the original GD2 library - whatever it is that it actually uses.
So there is no way to tell how long this takes to execute, how full the display list is and what the framerate is.

And speaking of GD2 library, I analyzed the datastream for a 7" GD3X display for the following code using Gameduino2-v1.3.4.zip and a FTDI NerO:

#include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>

void setup()
{
  GD.begin(0);
  GD.ClearColorRGB(0x103000);
  GD.Clear();
  GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "Hello world");
  GD.swap(); 
}

void loop()
{
}

So I modified the basic hello-world example to only run once.

And not going into details, I wonder why there even is the "Hello world" displayed on the screen at the end.
My impression is that GD2 library is more working by chance than by design - and I really did not expect that.
Apart from the 320ms delay a good portion of the >400ms from start to finish is spent on waiting for the command co-processor to time out on the supplied commands.

I put a EVE_GD3X config in my library and modified my Arduino code to this:
void setup()
{
    pinMode(EVE_CS, OUTPUT);
    digitalWrite(EVE_CS, HIGH);
    pinMode(EVE_PDN, OUTPUT);
    digitalWrite(EVE_PDN, LOW);

    SPI.begin(); /* sets up the SPI to run in Mode 0 and 1 MHz */
    SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));

    TFT_init();
    TFT_display();
}

void TFT_init(void)
{
    if(E_OK == EVE_init())
    {
        tft_active = 1;

        EVE_memWrite8(REG_PWM_DUTY, 0x40);  /* setup backlight, range is from 0 = off to 0x80 = max */

        EVE_memWrite32(REG_TOUCH_TRANSFORM_A, 0x0000D09D);
        EVE_memWrite32(REG_TOUCH_TRANSFORM_B, 0xFFFFFE27);
        EVE_memWrite32(REG_TOUCH_TRANSFORM_C, 0xFFF0838A);
        EVE_memWrite32(REG_TOUCH_TRANSFORM_D, 0xFFFFFF72);
        EVE_memWrite32(REG_TOUCH_TRANSFORM_E, 0xFFFF7D2B);
        EVE_memWrite32(REG_TOUCH_TRANSFORM_F, 0x01F3096A);
    }
}

void TFT_display(void)
{
    if(tft_active != 0)
    {
        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(DL_CLEAR_COLOR_RGB | BLACK); /* set the default clear color to black */
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); /* clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers */

        EVE_cmd_text(EVE_HSIZE / 2, EVE_VSIZE / 2, 31, EVE_OPT_CENTER, "Hello World");

        EVE_cmd_dl(DL_DISPLAY); /* instruct the co-processor to show the list */
        EVE_cmd_dl(CMD_SWAP); /* make this list active */

        EVE_end_cmd_burst(); /* stop writing to the cmd-fifo, the cmd-FIFO will be executed automatically after this or when DMA is done */
    }
}

So almost the same display.
I did not use the external flash, did not flip the view upside down and have the BT816 running at 72MHz instead of 60MHz.
This needs 120ms from start to finish with a fraction of the SPI traffic.

The logfiles are attached, these are from the Salaea Logic 2 software.

Yes, ESP32 does support the trig functions, thanks

Another (slightly unrelated) question. Do you have an example to fill polygons (with a mix of convex/concave points)?
I found posts in this forum using the stencils, but when there is an irregular shape, the filling process fails somewhere as this snippet shows:

CLEAR(1, 1, 1)
SAVE_CONTEXT()
LINE_WIDTH(32)
COLOR_RGB(255, 255, 0)
STENCIL_OP(INCR, INCR)
COLOR_MASK(0,0,0,0)
BEGIN(EDGE_STRIP_L)
VERTEX2F(7232, 2848)
VERTEX2F(5984, 5344)
VERTEX2F(8272, 4144)
VERTEX2F(10496, 4944)
VERTEX2F(9760, 1504)
VERTEX2F(5920, 1504)
VERTEX2F(7232, 2848)
END()

STENCIL_OP(KEEP, KEEP)
COLOR_MASK(1,1,1,1)
STENCIL_FUNC(EQUAL, 1, 255)
CMD_GRADIENT(655, 38, 0x0000FF, 348, 416, 0xFF0000)



Hi,

Do you have SIN and COS functions in your MCU code framework?
It can be done using just the EVE commands (we can send an example) but ideally it works best if you have these trig functions available (either full or via lookup table).

Best Regards,
BRT Community

Gentleman, thank you all for your answers.
I looked into the FTDI code to create arcs and, while it is certainly more efficient, it has a lot of dependencies and it's hard to pull off from the Screen Designer.
I played a bit with filling convex and concave polylines with weird results. Unfortunately there are not examples explaining well how to use them.

I will try using the scissors but it's a painful process. This is going to be a far too expensive development for this project.

That example was only an approximation with simple mathematics, the editor can only handle basic things, more advanced examples can be achieved with relatively few instructions, but with slightly more complex mathematics that must consider that the TFT has the Y axis reference frame on the contrary, we must not forget that the EVEx graphics chip does all the drawing work, leaving the MCU only the calculation part.

MCU: teensy 3.6
TFT: NHD 5" FT813
Library: GDSTx (2023)
https://www.youtube.com/watch?v=LmyN9tgATtc

MCU: Nucleo STM32F767ZI
TFT: Riverdi FT813 5"
https://www.youtube.com/watch?v=Yb60PmJu5S0

MCU: Arduino Due
TFT: 4DSystem FT843 4.3" (FT800)
Library: gameduino 2
https://www.youtube.com/watch?v=FOhaWL84bKU

Hi,

As you said Rudolph, two dots is a good way to make an un-filled circle.

Blending/stencilling can be used to create an arc by drawing an edge strip to overlap the active or non-active area of the circle if you want to have a certain quadrant shown and then only displaying the part of the circle which is within this arc. This is similar to the technique we often use to draw an arc gauge. We can create and post a small example here once it is ready.

Best Regards, BRT Community

 

I just checked the code and while it works this is probably the worst solution to solve the problem.

  GD.Begin(LINE_STRIP);
  GD.ColorRGB(0xFFFFFF);
  int x, y;

  for (int i = 0; i <= valor; i++) {
    x = 400 + 100 * cos(i * PI/180 );
    y = 240 + 100 * sin(i * PI/180 );
    GD.Vertex2f(16*x, 16*y);
  }
  GD.RestoreContext();

So the segment of the circle is actually composed of a LINE_STRIP for which the coordinates are calculated.
Not only does this take rather long to calculate, one full circle would take 18% of the display list.

Not that I have a simple and elegant solution for the issue, for circles I am using two DOTs and making it to an arc might involve SCISSORS.
Or two DOTs and a RECTANGLE could be used.
A different solution would be to render the arc in a bitmap and display it.

An arc command would be as nice, yes, but this is something we do not currently have.

Great work!
Initially I tried to use the Gameduino library because it looked a very neat and good way to work.
But moving it to a plain ESP32 looked like a lot of work, but I may have missed something.
There are ports on Github but they are quite old and not sure about their validity.
How difficult was your port?
Thank you