BRT Community

Please login or register.

Login with username, password and session length
Advanced search  


Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rudolph

Pages: [1] 2 3 ... 23
Discussion - EVE / Re: Porting ESD to esp32-s3
« on: March 29, 2023, 06:16:01 PM »
This is sitting here for a while without answer.
I do not use ESD so I can not help with that.

But I did adapt my own library to support ESP32-S3.
And all I really had to do in the end was to change "HSPI_HOST" to "SPI2_HOST".

Edit: and sorry, I just noticed that I was trying to help with the wrong issue.
I believed going from ESP32 to ESP32-S3 was what you are trying to solve as I thought ESD is supporting ESP32 already.
But it is the BRT_AN_025 library that is supporting ESP32. among others, not ESD.

Discussion - EVE / Re: Drawing arcs and circles
« on: March 29, 2023, 06:07:08 PM »
First of I feel like I need to apologize, I am certain that a live conversation would come across friendlier. :-)

Thanks for taking some time.

This is a mere coincidence, I only analyzed the SPI traffic from GD2 library to be able to add
support for the GD3X to my library.
I do not know why, but there is close to no documentation for the GD3X.
Anyway, I got all the data I was looking for and some I was not looking for.

The library for gameduino 23x has the file wiring.h as its axis of operation, within that file the starting of the EVEx chips occurs.

This is the library I've been testing with: GDSTx. You just have to place it in the libraries folder of the arduino IDE.

I already saw that it differs from GD2 library but did not have a chance so far to actually run it and look at the trace.
I opened an issue on Github to ask about the target support.
Looks like of the boards I have "only" the Teensy 4.1 is supported and I did not get around connecting a display, yet.

I uploaded the video examples, as evidence that it is possible to draw arc segments, not to test them; As I said, I have spent several years trying to understand the library and adapt it to be able to use it with teensy 4.1 and especially with its SDIO reader. Over time there have been several versions of the library, which is why I decided to upload the changes to Github to always have a backup. Unfortunately several examples were lost, when the hard drive I was working on failed a couple of years ago; only youtube videos remained.

I apologize for not being able to share the complete examples or the libraries, as I no longer have them.

I share the example for drawing arc segments, which resulted from all those experiments.

Absolutely no need for you to apologize.
I liked the examples and also the last image looks very nice.
Only my perspective is a bit different, my view is from the bottom and not from the top.
I spent quite a number of years now writing my own library.

And while I still apreciate your examples, my view from the bottom tells me that GD2 library and also GDSTx library
has a number of issues at the very core, starting with that the initialization bears close to no resemblence with the description in the programming guide.
Yes, this is way off topic now and again coincidence that I even saw this.

Have a look at my library:
Not to switch over, but to take whatever you might need.
My library does for example use DMA for the display-update SPI transfers on the Teensy 4 boards.

Discussion - EVE / Re: Drawing arcs and circles
« on: March 24, 2023, 07:51:16 AM »
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)

MCU: Nucleo STM32F767ZI
TFT: Riverdi FT813 5"

MCU: Arduino Due
TFT: 4DSystem FT843 4.3" (FT800)
Library: gameduino 2

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 and a FTDI NerO:

Code: [Select]
#include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>

void setup()
  GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "Hello world");

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:
Code: [Select]
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));


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.

Discussion - EVE / Re: Drawing arcs and circles
« on: March 20, 2023, 12:06:40 PM »
I just checked the code and while it works this is probably the worst solution to solve the problem.

  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);

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.

Discussion - EVE / Re: Flashing BT815 from ESP32
« on: March 12, 2023, 02:08:42 PM »
Anyway, it looks like a timing issue. It may depend on the SPI being too fast. When I tested the SPI code I could see the display I had to slow down some requests/responses. Unfortunately there is no better documentation to diagnose the issue. The timing diagrams are pretty basic.

I am not saying that it is not a timing issue but the flash is on it's own QSPI bus and compared to the 133MHz the flash chips usually support, it is slow.

Discussion - EVE / Re: Widgets
« on: March 07, 2023, 03:31:29 PM »
how can I create, upload to the display (BT815) and call a widget?
Note: I can't use the ESD.


No, uploading functions for the command co-processor to execute and add lines to the display-list based on supplied parameters is not possible,
or at least there is no documented API for that.
And the few bits and pieces that I gathered about the undocumented API do not seem to allow this either.

What you can do is pre-calculate sequences of display-list commands, copy these from the display-list to RAM_G and then use CMD_APPEND to add these snippets into your display list.
Ok, this not not CMD_MYBUTTON but you can still reduce the SPI traffic significantly.
In my simple example code I am using this mechanism only to create a section of display list commands that never change, a colored rectangle on top, a line to separate things, a text in the middle and o logo.

Sure, you could take it one step further and manipulate the snippets before using them.
But this would mean to mix co-processor commands for the display llist and memory functions,
probably does not much to reduce the SPI traffic and the result is probably rather slow compared to
do the display update in one DMA transfer.

There also is CMD_NEWLIST / CMD_CALLIST which allows to write co-processor commands verbatim to RAM_G and execute this snippets during display list building.
The difference to CMD_APPEND is that you get for example cmd_button(20, 20, 60, 60, 30, 0, "OK!"); in RAM_G and not all the display list commands that the co-processor is generating from a widget command.

Discussion - EVE / Re: Flashing BT815 from ESP32
« on: March 06, 2023, 05:23:13 PM »
I am only using PlatformIO because I would not even call "Arduino IDE 1.x" an IDE and the 2.0 still has nothing that VSCode could not do better.

Look, I already wrote that Arduino IDE is not good, but I can't migrate the rest of the libraries just because of this. I have good reasons for this choice and I know what I am speaking of.

Relax? I believe you misread my "I did" with "you have to".

No, there is no need to put the flash thru the init state, it even should go thru the init automatically and reach BASIC state.

I am not setting the INIT state. After successfully flashing I read the state and it transitions to INIT without ever going to basic. If I then reboot, everything is ok and I can transition to FULL as well.


I just added two reads for REG_FLASH_STATUS, one directly after my EVE_init() function which does nothing with the flash
and one later.
And with not using the flash the values are 2 and 2 which means that the flash is in state BASIC.

When I add a CMD_FLASHERASE() in between it stays 2 / 2.
When I throw in a CMD_FLASHUPDATE for the first block I still get 2 / 2.
When I swith to use CMD_FLASHUPDATE for the whole 85k flash image I still get 2 / 2.
This all is without using CMD_FLASHFAST.

I added an EVE_init_flash() and it changed to 2 / 3, so the flash is in state FULL.

Throwing in a CMD_FLASHERASE() I get 2 / 2 the next time after that and 0xE002 from CMD_FLASHFAST - no header detected in sector 0.

Ok, now I got 1 / 1 on coldstart and it does not go away with a reset of the controller.
I can not reproduce it though, the next coldstart it is 2 / 2 again.

So there is something there, I only can not reproduce it reliably.
Maybe some race condition that somehow locks up the QSPI of the flash chip?

I added three more EVE_init_flash() after the first in between in hope I get a 1 / 2 with maybe on the third EVE_init_flash()
that the flash starts working somewhere alone the lines.
But nothing, does not happen anymore, not after 2 seconds cold or 2 minutes, also not when bringing down the current from the bench PSU
to close what the dispay draws.

I triggered it with a little under-voltage which probably did odd things to  my backligh-supply.
And the repeated calls of EVE_init_flash() do nothing.

Now I added a delay of 100ms before calling my EVE_init() function and it works even with the PSU voltage lower than
my backlight voltage.

So at least what I get here looks like a supply issue, bringing EVE out of reset before the voltage rails are stable.

Discussion - EVE / Re: Flashing BT815 from ESP32
« on: February 23, 2023, 06:13:43 PM »
Because of other integrations, I choosed not to work with PlatformIO even if I agree that the plain Arduino IDE is way too basic.

I am only using PlatformIO because I would not even call "Arduino IDE 1.x" an IDE and the 2.0 still has nothing that VSCode could not do better.

I tried to move your library to the plain Arduino and it was too tricky because of PlatformIO (compiler definitions are not supported by the Arduino IDE but only using the CLI).

Hmm, I had an intern for the last two weeks and I gave him an Arduino UNO and an EVE3-50G to play with.
I took my current example and after a little convincing it ran in Arduino IDE 1.8.19.
He used my archive with Arduino IDE 2.0.3 on his own notebook and apart from that the "IDE" killed the project a couple of times it worked fine.

Also, I am pretty much done. All I have to do is integrating the "low level" APIs with my own abstraction layer that allows to draw items using OOP and completely forget about commands and the underlying BT C APIs.

Well, you still could use my library as a reference point.

Everything works but I am trying to understand what does not work with flashing. Most of the issues I had is because of the very poor documentation. But after reading tons of posts here and examples, I am pretty sure that the code is ok (I also compared the flashing procedure to your code).

I was wondering why BT does not provide a clear documentation of these procedures. Even reading the BT IC datasheet I could not find exhaustive explanations.

Have you ever had problems with unreliable writing on the flash?

No, I can't recall that I ran into severe issues when I implemented the flash commands.
But then I am probably not a good reference here since I am doing this for a number of years now. :-)
One thing that is important when using these functions though and that is that the alignment requirements must be strictly followed.
This is why I added these to the comment on top of my functions:

Code: [Select]
/* This is meant to be called outside display-list building, it includes executing the command and waiting for completion, does not support cmd-burst.*/
/* write "num" bytes from src in RAM_G to to the external flash on a BT81x board at address dest */
/* note: dest must be 4096-byte aligned, src must be 4-byte aligned, num must be a multiple of 4096 */
/* note: EVE will not do anything if the alignment requirements are not met */
/* note: the address ptr is relative to the flash so the first address is 0x00000000 not 0x800000 */
void EVE_cmd_flashupdate(uint32_t dest, uint32_t src, uint32_t num)

And yes, it took a few iterations to make the code this "simple". :-)

I am normally using CMD_INFLATE to get the data into RAM_G since especially fonts are usually highly compressable, probabably because they contain empty glyhps and because all glyphs need to be the same pixel size.

And then flashing from the host controller is not really meant for regular use, for a bigger project with several fonts and images I would flash the image file from EAB with a USB/SPI adapter.

I was forgetting one important info.
I carefully observed with the oscilloscope the timings of the ESP32 SPI using both ESP32-IDF (with and without DMA) and the Arduino SPI for ESP32.
The results are:
- The native ESP-IDF performance is poor (even using transactions) because there are lengthy gaps between every transmissions.
- The Arduino SPI library is much way faster.
In the ESP32-IDF forums I was told that the Arduino wrapper does NOT use the IDF abstraction APIs but goes directly to the ESP32 registers. They also said that the IDF library is typically much slower because Espressif wants to provide a stable abstraction over future silicons.

Oh? When did this change?
When I implemented the ESP32 Arduino code back in end of 2020 it was really really slow.
On a first test with the SPI class my ESP32 was running the display update in 1476µs while the Arduino UNO
was running the exact same code in 516µs.

The SPI class was running on top of ESP-IDF back then.

So I may need to try this again.
What I am not seeing in the current ESP32 SPI class is DMA support though.
And what I do see is that there is a heck of a lot of code that gets executed everytime in order to try to make the implementation bullet proof.
So even if it really is running faster it still is running with the handbrake engaged.

Update: I was able to reliably flash the display with the same code but changing cable.

Anyway, I always have to reboot the display (after flashing), otherwise the FLASH always stay in the "INIT" state and never changes.
How can I make the display flash transitioning from INIT to (at least) BASIC?

Is rebooting after flashing a mandatory action?

No, there is no need to put the flash thru the init state, it even should go thru the init automatically and reach BASIC state.

From my example, shortened a little:

Code: [Select]
void TFT_init(void)
    if(E_OK == EVE_init())
         EVE_memWrite8(REG_PWM_DUTY, 0x30);  /* setup backlight, range is from 0 = off to 0x80 = max */

    #if 0
        /* this is only needed once to transfer the flash-image to the external flash */
        uint32_t datasize;

        EVE_cmd_inflate(0, flash, sizeof(flash)); /* de-compress flash-image to RAM_G */
        datasize = EVE_cmd_getptr(); /* we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size */
        EVE_cmd_flashupdate(0,0,4096); /* write blob first */
        if (E_OK == EVE_init_flash())
            EVE_cmd_flashupdate(0,0,(datasize|4095)+1); /* size must be a multiple of 4096, so set the lower 12 bits and add 1 */

        if (E_OK == EVE_init_flash())
          EVE_cmd_flashread(MEM_FONT, 84928, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */

This code assumes that the flash is completely empty and it does not bother to check the state of the flash first since there practically is no way
that a correctly attached flash is not in state BASIC at this point, especially not after full initialization of the display.
The first 4k contain the binary blob that is necessary to put the flash into state FULL so this is flashed first.
After that my EVE_init_flash() function is called to put the flash into state FULL - and it does a whole lot more than just that, have a look.
If the flash was sucessfully initialized to state FULL the whole image is flashed with CMD_FLASHUPDATE.
The next call to EVE_init_flash() is only there as the block that flashes the image can be commented out after the first time.

So even on a first run with flash update active this just runs thru, no need for a reset at all.

And the only reason I am doing this in two steps is that writing to the flash is a lot faster in state FULL.

If the flash is viable then REG_FLASH_STATUS automatically indicates state BASIC after power-up and from there you can use CMD_ FLASHERASE, FLASHWRITE, FLASHUPDATE, FLASHPROGRAM, FLASHREAD and FLASHDETACH.

Discussion - EVE / Re: Reading BT815 font metrics
« on: February 22, 2023, 05:16:06 PM »
Ok, then it looks like the datasheet needs a revision.

Discussion - EVE / Re: FT813 bin compression algorithm documented?
« on: February 21, 2023, 05:14:26 PM »
The "ASSET COMPRESSOR" in EAB says: "Compress asset by using Zlib or Zopfli library".
And the difference is that Zopfli is compressing better but eats more computrons doing so.

Discussion - EVE / Reading BT815 font metrics
« on: February 20, 2023, 06:38:03 PM »
I am playing with reading the BT815 font metrics and the results do not match the "Table 4-8 ROM Font Table" in version 1.2 of the BT817/BT818 or version 1.0 of the BT81x datasheet.
For font 28 I get L4/9/18/25 while the datasheet has L4/9/19/25.

Now table 4-9 lists a width of 19 pixels for "@" and "M" and the width value I am reading from the table is indeed 19.
For "W" I get a value of 18, for "R" I get a value of 13 and both match table 4-9 as well.

There seems to be at least a bug with rom_font.pixel_width of font 28?

Discussion - EVE / Re: Simple way to draw meter
« on: February 18, 2023, 01:56:38 PM »
A simple way to draw a meter could be to use cmd_gauge with OPT_NOBACK and OPT_NOTICKS on a fancier background image.

What I have done a couple of times now in projects which is even simpler is to use two rectangles on top of each other for a frame and then use a third rectangle within the frame, not as fancy but very efficient.
And you can round the edges of rectangles with the line width.
The result is more like a battery indicator.
It could be combined with changing the color, lines on top to form segments, numbers on the side and/or a number below/on top to show the current value.
I displayed values for temperature, voltage, torgue and rotational speed next to each other.
Funtionality was the goal, not so much eye-candy.

Discussion - EVE / Re: Flashing BT815 from ESP32
« on: February 18, 2023, 01:38:36 PM »
My library does support the ESP32:
This includes DMA for both Arduino (by going around the Arduino SPI class) and ESP-IDF.

And in my example code I show how to write to the flash with flash_update, look for the define TEST_UTF8 which is set to "0" by default.
The part that actually writes the flash-image containing an UTF-8 font is commented out with "#if 0" since it only needs to be run once.

Discussion - EVE / Re: ASTC Custom Font from Flash
« on: November 30, 2022, 03:47:49 PM »
Have you checked with CMD_FONTCACHEQUERY how many glyphs are actually used?
In my experience it does not flicker though, using more characters than there is room for in the cache did result in crashes for me.

And I just checked the timings, I am using these as well.
Except for the magic cookie "0xD12" as my library configures the display clock by Hz.
"0xD12" is 51MHz though according to table 4-11 of the datasheet and I am using 51MHz.

How fast do you update the display?
There is flickering when you try to update the display list faster than EVE can display it.
With the given timing parameters the frame rate is 59,76 Hz so the pause between two updates should be
longer than 16.73 ms.

Discussion - EVE / Re: 5" EVE Touchscreen Display
« on: November 28, 2022, 05:01:03 PM »
I am using an adapter with a switching regulator for my tests with all kind of breadboards.

This is for a supply voltage of 5V to 18V (depending on the regulator) and the voltage
for I/O and backlight is about 3.35V - deliberately a little over 3.3V.

The only challenging part is the FFC connector as it has 0.5 mm pitch.

In regards of the biggest displays that I have connected, I am using the single supply 3.3V version with EVE2-70G and EVE3-70G.

I designed a PCB with two switching regulators specifically for the RVT101HVBNWC00-B as it needs 7V to 12V for the backlight.
This PCB somehow barely also fits mechanically at the back of the RVT70HSBNWC00-B for which I changed the backlight supply to 5V.

Pages: [1] 2 3 ... 23