Newhaven EVE_NHD_43_800480 issue

[jsr64]

Dear Rudolph
I was very happy knowing about capability of library to cover FT800 to FT813 series.
However I am facing problem with NHD_43_800480 capacitive screen work with library.
In EVE_config.h its mentioned as untested !!
When I run this TFT NHD-4.3-800480FT-CSXP-CTP with its shield NHD-FT81x-SHIELD and flat cable connected to display using Arduino Due and even Arduino Giga R1/Arduino Portenta H7, it works partially.
The display blinks and shows the correct display but goes blank immediately within fraction of seconds.
I have changed the below code with "for" loop repeating it, and display does repeat but again it blinks and goes blank

if(E_OK == EVE_init()) /* make sure the init finished correctly /
{
EVE_cmd_dl(CMD_DLSTART); / instruct the co-processor to start a new display list /
EVE_cmd_dl(DL_CLEAR_COLOR_RGB | 0xffffff); / set the default clear color to white /
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_color_rgb(0x000000); / set the color to black /
EVE_cmd_text(EVE_HSIZE/2, EVE_VSIZE/2, 30, EVE_OPT_CENTER, "Hello, World!");
EVE_cmd_dl(DL_DISPLAY); / mark the end of the display-list /
EVE_cmd_dl(CMD_SWAP); / make this list active /
// EVE_execute_cmd(); / wait for EVE to be no longer busy */
}

I am stuck up, is there minor tweaking required in EVE_config.h
#if defined(EVE_VM810C) || defined(EVE_ME812A) || defined(EVE_ME813A) || defined(EVE_GEN4_FT812_50) ||
defined(EVE_GEN4_FT813_50) || defined(EVE_GEN4_FT812_70) || defined(EVE_GEN4_FT813_70) ||
defined(EVE_NHD_43_800480)
#define Resolution_800x480

#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 2
#endif

And also I wish it works with Portenta H7 and Giga R1 platform. STM32H747 is mentioned in EVE_target.h but will that cover Arduino Portenta and Giga R1 board too?

Regards
JS Rawat

[RudolphRiedel]

I will have a look but i am travelling today.
This does not sound like an issue with the configuration.
The Due, Portenta H7 and Giga R1 are not currently supported directly as you are the first to ask and these are a bit pricey to have laying around and collecting dust:-)
These should be working with the generic Arduino target unless the Arduino core does something differently than other cores, like implenting a non standard spi class.
And looks like it works in general.

[RudolphRiedel]

Ok, now I can even quote. :-)

In EVE_config.h its mentioned as untested !!

Yes, I am trying but I can't buy them all. :-)
Well, and especially with older ones I am less motivated to do so. :-)

When I run this TFT NHD-4.3-800480FT-CSXP-CTP with its shield NHD-FT81x-SHIELD and flat cable connected to display using Arduino >Due and even Arduino Giga R1/Arduino Portenta H7, it works partially.

I wonder if this shield even can work properly with 3.3V targets as both the 5V and the 3.3V are regulated on the shield and there is no way around the level-shifter.

The display blinks and shows the correct display but goes blank immediately within fraction of seconds.

This should not be happening.
Do you have any other Arduino to test this with? Perhaps an Uno (clone) in regards of the 5V?

I have changed the below code with "for" loop repeating it, and display does repeat but again it blinks and goes blank

Not the issue to solve here, but using it in a loop requires to have a delay of some sort between the loops.
It starts to blink though if the refresh-rate is higher than the FPS of the screen.

The display should be completely static after the code was executed once in setup().

I am stuck up, is there minor tweaking required in EVE_config.h

The configurations are generally make-or-break, meaning that nothing is displayed when the configuration is wrong.
There are a few execeptions with the image shifted on the panel if the configuration is slightly off for example.

Which pins are you using for EVE_CS and EVE_PDN?
The Due, Portenta H7 and Giga R1 are compiled with the default Arduino target since I have no special target "driver" for these.
That is EVE_target/EVE_target_Arduino_generic.h will be used and therefore EVE_CS and EVE_PDN will use pins 10 and 8 unless you already changed that.
And the SPI pins are whatever the default SPI pins are for these boards.

STM32H747 is mentioned in EVE_target.h but will that cover Arduino Portenta and Giga R1 board too?

No, that entry is for the non-Arduino targets.
And while the STM32 part compiles, it still does not work out-of-the-box so far.

I modified my simple "Hello, World!" example and also the more "complex" basic demo to compile with PlatformIO for the Due and both cores of the Portenta H7.
And it compiles at least:
Environment Status Duration

---

uno SUCCESS 00:00:01.440
dueUSB SUCCESS 00:00:01.899
portenta_h7_m4 SUCCESS 00:00:07.081
portenta_h7_m7 SUCCESS 00:00:07.430

Looks like the Giga R1 is not (yet) supported by PlatformIO so I could not test this as easily.

I just opened the Arduino IDE 1.8.19, installed the "Giga" board package, selected the Giga R1 package and compiled.
As expected the EVE_target_Arduino_generic.h was missing from my folder and it could not compile.
So I copied over the file and it compiles:
Sketch uses 123752 bytes (6%) of program storage space. Maximum is 1966080 bytes.
Global variables use 49664 bytes (9%) of dynamic memory, leaving 473960 bytes for local variables. Maximum is 523624 bytes.

So it should work, albeit way slower than it could as this is just using the standard Arduino SPI class with no DMA support.

I also installed the package for the Portenta H7 now and it compiles just fine as well.

I do have the file "EVE_target_Arduino_Nucleo_F446RE.h" plus code in EVE_cpp_target.cpp for it to use SPI over DMA.
This is probably a good starting point for an adaption to the Giga R1 and Portenta H7.

I do not know how the build process differentiates between the M4 and the M7 though.

Edit, missed this one:

I was very happy knowing about capability of library to cover FT800 to FT813 series.

Actually, the name is not accurate anymore but kind of stuck.
FT80x support is gone since 5.x but BT81x support is added.
So right now it is FT810 to BT818 and probably BT88x.

[jsr64]

NHD-FT81x-SHIELD has provision for level shifting and it is working fine in another library FT800 of NewHaven https://github.com/NewhavenDisplay/EVE2-TFT-Modules . I could run the https://github.com/NewhavenDisplay/EVE2-TFT-Modules/tree/master/4.3in/_800x480/Capacitive/FT_App_Gradient/Project/Arduino/Ft_App_Gradient. The touchscreen and display are working fine. However I feel the software simplicity of your library so I want to use that.
I agree that The display should be completely static after setup. In the repeat loop I did gave delay of 1000ms and it does displays content at that interval, but again it goes blank or black immediately. I will work on other Arduino like UNO and Mega next week to see if this resolves and will revert back.

Thanks and warm regards.

[RudolphRiedel]

NHD-FT81x-SHIELD has provision for level shifting

Yes, that is my point, it provides level shifting between the 3.3V FT8xx and a 5V target controller.
But I just checked the schematic for the shield again and the datasheet for the NVT2010BQ chip on the shield.
While yes, MISO gets pulled to 5V (and the other outputs), at least the current is limited by R6, so this should not directly kill a 3.3V target controller.

Are you using the Arduino IDE?

Then try this:
EVE_Test_Arduino_IDE.zip

It uses EVE_CS = 10 and EVE_PDN = 8.

Which pins do you actually have connected and which did you leave out?

In the repeat loop I did gave delay of 1000ms

I checked the configuration and the resulting screen-rate should be 61,58 Hz, so anything above 16ms should be fine.
I normally use 20ms / 50Hz for the refresh.
That is of course when it does not go blank or black anymore with the 1000ms delay.

[dstulken]

Sorry guys, I meant to share the word on this earlier...

Newhaven did us all a serious disservice in the middle of 2022, and silently changed the hardware (and the resulting software interface) on the NHD-4.3-800480FT-CSXP-CTP, without revising the part number or publishing any notice of the change. They just changed it and released the new parts into the wild. 🙄

Prior production displays used the FAN5333BSX backlight driver, and due to component shortages and a desire to keep production going, Newhaven switched to the SGM3766YTN5G. The key difference between these is that the original chip has a maximum backlight PWM frequency of 1KHz, while the replacement has a minimum PWM frequency of 10KHz (more on this later). If you attempt to run a newer display with older software, the backlight will go off at any setting below about 50% brightness (REG_PWM_DUTY). Above about 50%, the display turns on, but the backlight linearity is very coarse and not reflective of the value commanded.

I couldn't say for sure when this issue first occurred, but we discovered it around August of 2022. It caused my company a costly two week production shutdown while Engineering worked to isolate the cause, and it was clear that Newhaven didn't know about the issue until we contacted them. Their ultimate explanation was that they had staffing changes in engineering and it slipped through, but even so, the displays shouldn't have passed QC testing, shouldn't have been released without changing the part number or revision (since they are software incompatible), and a Product Change Notification should have been published. So there were multiple process failures at Newhaven.

So now... where does that leave us. Remember those two backlight PWM chips? The original with a maximum PWM frequency of 1KHz, the replacement with a 10KHz minimum. Note that there is no overlap between those ranges. Newhaven suggested we run the new displays at 10KHz, which is unacceptable for any commercial manufacturer as it leaves them with two separate software branches, and a random chance that the display won't work depending on which production batch you have in hand. (And with no altered part number or revision markings, there is no way to tell without testing.) It also means that product repair or warranty work is dicey, as again, a replacement display (or logic board driving it) may or may not have the right software for the hardware. We let them know this was not acceptable, and they got back to us advising us to run the new displays at a backlight frequency of 800Hz. I pointed out that this is out of range for the new PWM driver, and we were told that Newhaven does not expect any long term reliability issues.

To the best of my knowledge, the NHD-4.3-800480FT-CSXP-CTP then gets the dubious honor of being the only EVE-based display that uses a non-standard backlight PWM frequency. Since the display config structures in the library don't provision for changing this (Why would you, when "no display needs it!"), I modified my local copy of the library to place the line:
#if defined (EVE_NHD_43_800480)
EVE_memWrite16(REG_PWM_HZ, 0x320); //0x320 = 800Hz
#endif
at the top of the TFT_init() function, to change the frequency from the default 250Hz to the revised 800Hz.

In case it matters for your application, I will point out that the backlight brightness linearity is not the same between the old and new displays. They both dim through the full range, but the curves are not the same.

And also, I can add that displays with stickers on the back reading "5913 0920 1L" and "7273-2721 1L" used the original FAN5333BSX chip, and "WO198-1222" uses the new SGM3766YTN5G chip. I don't have any information beyond that, that's just what our company could determine when triaging the issue.

As a related aside... does anyone know of any other vendors offering an 800x480 4.3" EVE-based display? Asking for a friend...

[RudolphRiedel]

Wait, what?
Yes, I usually do not change REG_PWM_HZ, it might help with audio quality though.

I checked the demo app and found that it is not even touching REG_PWM_DUTY or REG_PWM_HZ, so it runs on the default values of 250Hz and 100%.

@jsr64
-> change the EVE_memWrite8(REG_PWM_DUTY, 0x30); in TFT_init() of tft.c to write 0x80.
Or yes, add writing to REG_PWM_HZ as stated above, I would go for 10000 though.

Then I checked the datasheet for the NHD-4.3-800480FT-CSXP-CTP and it shows the SGM3766YTN5G in the schematic and states "the on-board backlight driver’s PWM frequency is 800 to 100KHz".
The datasheet of the SGM3766YTN5G however gives a range of 10kHz to 100kHz for the "PWM Dimming Frequency Range" at +25°C.
And the display datasheet correctly states "the range available on the FT81x is 250 to 10KHz".
Hmm, I hope they asked SGMICRO what happens when the PWM is out of spec, and if even is when setting REG_PWM_HZ to 10000.
The schematic differs from the datasheet, maybe to reduce flicker at the lower frequencies.

As a related aside... does anyone know of any other vendors offering an 800x480 4.3" EVE-based display? Asking for a friend...

I would rather go with 5" but you could ask Crystalfontz.
They have 4.3" panels with 800x480:
https://www.crystalfontz.com/product/cfaf800480h0043sn-800x480-4-point-3-inch-tft-display

And they already have a number of EVE displays up to BT817, for example these:
https://www.crystalfontz.com/product/cfa800480e3050sw-800x480-5-inch-eve-touchscreen-tft-display

So they could be inclined to do a 4.3" 800x480 with EVE chip, even more so if your friend is planning to order in bulk. :-)

Hmm, that CFA800480E3-050SW is interesting.
Not only do I need to add a couple more boards to EVE_config.h, the pcb has the footprint of an ESP32 module.

[RudolphRiedel]

I just pushed a change to EVE_commands.c and EVE_config.h.

There is a new optional parameter in EVE_init() now: EVE_BACKLIGHT_FREQ
And the configuration for the EVE_NHD_43_800480 is now separate and sets it to 800 if EVE_NHD_43_800480 is not already defined.
So the value can be overwritten for EVE_NHD_43_800480 and it can be used with other displays thru the project options.

And when testing it with the EVE_RVT50H I currently have on my desk I found that the backlight intensity changes with the backlight frequency - which really should not be the case.
At the same duty value the brightness first goes down when I increase the frequency from 250Hz to 300Hz and further down when I increase the frequency to 400Hz and even lower at 410Hz.
At 420Hz however the brightness is a lot higher than at 250Hz.
So the EVE_NHD_43_800480 might not be the only one needing a setting of REG_PWM_HZ.

Edit: Riverdi does not specify the PWM frequency for the EVE4 series, or which chip is used.
Their non-Arduino example code for all EVE chips is using 4000Hz with a few extra lines in App_Common.c which are not implemented in the Arduino version App_Common.cpp - and checking the differences between App_Common.c and App_Common.cpp these are mostly identicle, only someone forgot to update the header when updating App_Common.c and also forgot to update the Arduino repository.

[RudolphRiedel]

Well, Riverdi answered me: "The minimum is 1kHz, we recommend 4kHz." - excellent, now I am really glad that the displays worked regardless so far and that we had this conversation.

[jsr64]

Thanks Rudolph and dstulken
I could sort it out, somehow could not log it earlier and respond.
But the things are working great with Arduino Due and even in Giga R1.
only change required was the PWM duty cycle which as you pointed out was done by
EVE_memWrite8(REG_PWM_DUTY, 0x30);
I changed it to 0x50, display was consistent though flickering
but 0x60 gave very stable performance.

thanks a lot rudolph and dstulken
regards

[RudolphRiedel]

Oh, my part was quick and easy.
But that issue is a new one for me, my thanks to @dstulken for pointing that out.

[RudolphRiedel]

But the things are working great with Arduino Due and even in Giga R1.

Ah, forgot about this part, there are probably numerous applications that are ok like this and when I started to use EVE displays I only worked with AVR controllers.
But, without extra support the SPI is running in blocking mode, like on the AVR which has no DMA unit.

I'll have to check if there is any DMA support in the Arduino classes but DMA seems to be a somewhat alien concept for Arduino.
I just checked my sources and for the couple of Arduino targets I support with DMA,
only the Teensy SPI class actually has DMA support, for the rest I need to go around the SPI class.
And this is different levels of painfull to implement. this is where the dark part of the forrest begins. :-)

[jsr64]

I checked it on GIGA R1 and it worked. It has DMA but i didn't checked whether the code or library is utilising DMA.
I myself don't have much clue or expertise on using DMA. I will check that out once I switch back to GIGA R1 from Due.

I have another query regarding capacitive touch...

I was going through the programmer guide, I have observed that in a capacitive touch display there are multiple touch points, but it doesn't elaborate the touch sequence (perhaps its obvious !)On putting that in extended touch mode, how does the touch work?1) Does all the 5 points need to be touched simultaneously or does it detect the sequence of touch (one at a time)?2) Or the presence of maximum 5 touch points it identifies (and that too in sequence)tag = EVE_memRead8(REG_TOUCH_TAG);
I guess It is going to put corresponding tag values in 5 different REG_TOUCH_TAG registers, and that will be based on the sequence in which touch points were touched. So the sequence matters as tag value will keep on shifting across tag registers 0,1,2,3,4 based on touch sequence.

Regards
JS

[RudolphRiedel]

As I learned while playing with the Arduino UNO R4 over the last week, Arduino does not know DMA and adding features to pull-request is a strict no-go.
So no DMA so far for the GIGA R1 I am afraid.

What are the Time1 and Time2 values for the GIGA R1 with my basic demo?
Even though not by DMA (yet), I should be able to reduce that numbers.

And by coincidence I am looking at the SPI driver right now that is used by mbed-os for the STM32 inside the Arduino core. :-)

Regarding the touch, yes, that last part, it puts the tag values into the different REG_TOUCH_TAG ... REG_TOUCH_TAG4 registers in the order you put your fingers on the display.

The default mode is single-touch though, you need to activated mutli-touch after the calibration:
EVE_memWrite8(REG_CTOUCH_EXTENDED, 0);

[jsr64]

Time T1 and T2 are 503 and 56 microseconds for Due board.
For GiGa R1 it was surprisingly high at 720 and 60 microseconds. I had expected Giga having STM32H747 may work faster.
Later I figured out that i hadn't defined STM32H7, so the target STM32H7 wasn't selected and it worked with ARDUINO as default target.

I came across another problem. I believe using Giga R1 board, the display TFT NHD-4.3-800480FT-CSXP-CTP with its shield NHD-FT81x-SHIELD were working fine earlier with both display and touch, but now only display is working while touch is not responding. This erratic behaviour i though was due to loose FPC connector. Since I wanted to develop code for Giga having larger RAM and better feature so have to change the connector to get Giga board work again with display and touch too. However the register values show no touch at all ! If display is working SPI is working and I2C touch signals are internally generated so it should not get affected !! The same cable works fine with touch when shield is mounted over Arduino Due !!

In compatibility mode these were register hex values:
REG_TOUCH_CONFIG = 381
REG_TOUCH_MODE = 3
REG_CTOUCH_EXTENDED = 1
REG_TOUCH_RAW_XY = FFFFFFFF
REG_CTOUCH_TOUCH0_XY= 80008000
REG_CTOUCH_TOUCH1_XY= FFFFFFFF
REG_TOUCH_TAG = 0

In extended mode these were register hex values:
REG_TOUCH_CONFIG = 381
REG_TOUCH_MODE = 3
REG_CTOUCH_EXTENDED = 0
REG_TOUCH_RAW_XY = 80008000
REG_CTOUCH_TOUCH0_XY= 80008000
REG_CTOUCH_TOUCH1_XY= 80008000
REG_TOUCH_TAG = 0

I also wish to later use SPI of STM32H747 and its DMA too by selecting it as target board.

[RudolphRiedel]

Time T1 and T2 are 503 and 56 microseconds for Due board.
For GiGa R1 it was surprisingly high at 720 and 60 microseconds. I had expected Giga having STM32H747 may work faster.

Is this after the updates I pushed a few days earlier or still with an older version?
The DUE is using ArduinoCore-sam while the Giga is using ArduinoCore-mbed.
https://github.com/arduino/ArduinoCore-sam/blob/master/libraries/SPI/src/SPI.cpp
https://github.com/arduino/ArduinoCore-mbed/blob/main/libraries/SPI/SPI.cpp

And the SAM core is using registers, the mbed core is going thru several layers of extra code.
uint8_t arduino::MbedSPI::transfer(uint8_t data)
dev->obj->write((const char*)&data, 1, (char*)&ret, 1); - where-ever the heck that goes
Somewhere in there is some call to variants/GIGA/libs/libmbded.a

There is stm32h7xx_ll_spi.h in ArduinoCore-mbed though so there may be a way to significantly speed things up.
Platform ststsm32 for PlatformIO does not support the Giga officially yet which makes this tough for me to compile.

[jsr64]

The SPI speed I had changed therefore Giga was showing slower response earlier. Now its showing 400 and 46 us for your test program.
I installed version 5.0 and found target files for Giga, I changed/pointed the target files to Arduino generic and Giga header files, they work fine for display part but touch part still not working. I changed cable too.
When the SPI commands are sent and received too what stops the touch?
I can directly see the registers are uploaded, changed and even read. Only the touch Registers are not showing the change in X,Y location and even Tag value not coming up. Touch registers stay in reset state. I have included such serial.print code.

Serial.print(" HSIZE reg, eve ="); Serial.print(EVE_memRead16(REG_HSIZE)); Serial.print("\t"); Serial.println(EVE_HSIZE);
Serial.print(" REG_CTOUCH_TOUCH0_XY=\t"); Serial.println(EVE_memRead32(REG_CTOUCH_TOUCH0_XY ), HEX); // 0x00302124UL

The output i get is...
HSIZE reg =800, HCYCLE reg =928, HOFFSET reg =88, HSYNC0 reg =0, HSYNC1 reg =48, VSIZE reg =480, VCYCLE reg =525, VOFFSET reg =480, VSYNC0 reg =0, VSYNC1 reg =3, SWIZZLE reg =0, PCLK_POL reg =1, CSPREAD reg =0
REG_TOUCH_CONFIG = 381, REG_TOUCH_MODE = 3, REG_CTOUCH_EXTENDED = 0, REG_TOUCH_RAW_XY = 80008000, REG_CTOUCH_TOUCH0_XY= 80008000, REG_CTOUCH_TOUCH1_XY= 80008000, REG_TOUCH_TAG = 0

The Giga board can upload code using Arduino generic or Giga header files. The display and counter T1 and T2 are also running, The configuration registers are being shown as altered and read too continuously in loop. But the touch press and location are not getting updated. Maybe I am missing somewhere. so still stuck up!

[RudolphRiedel]

Hmm, I was about the write that you should try and lower the SPI clock since reading reliably usually stops working at a lower threshold than writing.
But this obviously is not the issue when you can the registers just fine.
Have you calibrated the touch?
My next concern would be the supply voltages, especially that the logic supply does not glitch when switching on the backlight,
but since you are using the Newhaven shield this should work.

[jsr64]

The good news is touch is working fine in Arduino Giga. I just removed flex cable and used IDC header with SPI, 8,9,10 pin and supplies. Some poor contact issue perhaps earlier.

The bad one is that the target board chosen was Arduino Generic, choosing target as (ARDUINO_GIGA) the giga board shows fault in upload, but on choosing Arduino Generic board, the same giga board works fine. There are other issues with Giga itself particularly the memory mapping. The integer array is not working inside VERTEX2F(x,y).

I was just trying to upload an integer array mem_sine[256] to EVE_RAM_G by

EVE_memWrite_sram_buffer(EVE_RAM_G + 1024, mem_sine, 256);
void EVE_memWrite_sram_buffer(uint32_t const ft_address, const uint8_t *p_data, uint32_t const len)

All the arguments are constant type!! This inhibits me to display real time waveform from EVE_RAM_G, though the x-y values of curve are possible even by SRAM memory directly. I was able to compile with non constant variables and upload too but the display just hangs up.
Also seems accessing x-y values from EVE_RAM_G by DL commands may not be that fast as when these values are obtained from SRAM directly. Seems this memory is only meant for audio, video and image.

I wanted to display partial curve with each display refresh, so that complete curve is generated by few display refresh. This would have saved my limited DL memory. But with 6000 us display refresh for my display list for each display refresh, the curve kind of starts blinking as if i am loosing persistence of vision. If I keep a single display refresh and change x-y values there is smooth movement of curve, but when I split curve display over two separate position then it kind of blinks. Though I am not aware of display varieties and technology but it appears to me EVE display are more suited for colourful GUI, audio, video, images with touch. The DL memory of 8K is not suited for large curve data more than 1K points at a time.

[RudolphRiedel]

Hmm, I just happen to have the Arduino IDE 1.8.19 open as I am playing with a W806 board and right now I can only use it with Arduino.

I added this:
uint8_t mem_sine[256];

for (uint8_t counter = 0; counter < 100; counter++)
{
EVE_memWrite_sram_buffer(EVE_RAM_G + 1024 + counter, &mem_sine[40+counter], 12+counter);
EVE_cmd_dl(VERTEX2F(100 + counter, 90 + counter * 2));
}

And it just compiles for the W806 and works, the traffic on the SPI makes no sense at all but it works. :-)

I switched over to Arduino Giga R1 and it correctly did not compile as EVE_target_Arduino_GIGA_R1.h was missing.
I copied over EVE_target_Arduino_GIGA_R1.h and now it compiles just fine.

What am I missing?
Yes, the parameters are const, but this only applies to the function itself, for the most part this forces me to not modify the parameters.

I wanted to display partial curve with each display refresh, so that complete curve is generated by few display refresh.
This would have saved my limited DL memory.

No, Eve does not work like this, the display list is worked thru line by line and when you replace it then the new list gets worked thru.

But with 6000 us display refresh for my display list for each display refresh, the curve kind of starts blinking as if i am loosing persistence of vision.

6ms is 166 Hz, if you are updating this fast it will blink, even when writing the same display list over and over again.
The update of the display list must be slower than the screen rate for the panel is.
With the settings I made for the NHD43_800480 it should run at about 61.58Hz, so the display refresh needs to be 16ms or slower.

The DL memory of 8K is not suited for large curve data more than 1K points at a time.

Well. 8kiB is up to 2000 commands.
But filling 8kiB with basic display-list commands like VERTEX2F that go verbatim from the 4kiB ram-cmd to the display list is a bit tricky.
With the co-processor commands like cmd_text that get translated into a larger display list segment than what they need in ram-cmd this is usually not an issue, you run faster out of ram-dl than ram-cmd.

As I show in the README.md, you can split the display list generation, you only need to make sure that you have one CMD_DLSTART in the first block and DL_DISPLAY plus CMD_SWAP in the last block.

I am usually using 20ms / 50 Hz refresh.
When running on a 1ms task one could either refresh the display every 20th call.
But as this probably would violate the 1ms time budget, the refresh could be split into 20 segments.
Or make that 16 and use the other 4 slots in the task to read the touch data.