ST7701S Support

[flykarlos]

Dear Bodmer

I am writing here with request to add support for displays with ST7701S driver. I am approaching to realization of my project which will be using display equipped with such driver IC. I ordered this one (SPI version). It is 480x480 resolution.

http://surenoo.tech/download/04_STP/R0210/STP480480_R021A2.pdf?spm=a2g0o.detail.1000023.17.454942c2mfqUMx&file=STP480480_R021A2.pdf

I am amazed, how great is Your TFT_eSPI library. Also, I am aware of how much work it goes to maintain and provide such support, so I would like to ask you if you have any donation profile, pay pal etc? Your work has to be appreciated more than saying thanks every time You help.
Also, please send me email with delivery address so I can order same display for You for test purposes.
Thank You very much!
Karol

[Bodmer]

Hi, I have a lot of projects on the go at the moment so unfortunately I do not have the time to help you.

The library does allow new displays to be added, but this is not something I have time to do. Thanks for your offer and kind comments about the library.

[flykarlos]

Thanks for answer. Do You have any guide how to create a driver? I went through existing drivers and looks like they all follow some "schematic". Do You know any document to help me understand how should I do it? or I just have to study driver IC manual and successively create new driver based on drivers already existing? Maybe there's no single and simple answer.

[Bodmer]

To add a new display 3 new files need to be created here. xxxx_Init.h, xxxx_Defines.h and xxxx_Rotation.h

The init sequence is critical and needs to set the display to 4 wire and 16 bit colour. The Init sequences can often be found on the web using a Google search, or may be provided by the display supplier.

Then a reference needs to be allocated here.

And links created, here and here.

[Bodmer]

The complication with the 3 wire displays is that the Data/Command (DC) bit must be sent as a 9th bit for every byte sent. This is possible but is an extra complicationsince the data stream has to be divided up and shifted to make use of the 8/32 bit SPI output registers/buffers. I have avoided since there are plenty of supported 4 wire displays available.

There are Arduino graphics libraries that do support 3 wire displays, but it is not a feature I will be adding.

[flykarlos]

Thank You for answer

Just after posting my question I realized that You actually mentioned on main page that 3 wire SPI is not supported.
I agree that many cheap displays are available, but it is not an option in my case, because I am limited to round shape displays due to specification of my project. There are a number of round displays available, but if somebody is looking on something bigger than 2 inch in diameter with SPI support currently there is only ST7701S based display.
Whats funny is that driver IC itself supports 4 wire SPI, but DC pin is not routed on ribbon cable..
Anyway, thanks for Your hard work!

[flykarlos]

Sorry for bothering you again. I am in process of learning and understanding display interfaces. One thing bothers me..
I fully understand that Your library does not support 3 wire SPI. Thats perfectly ok. But I got "addicted" to this library which suits almost all my needs, so I would stick to it with future projects. So I am looking for a way to use 3 wire SPI.
During surfing internet for more info about usage of SPI+RGB interface I found this:

The 3-wire Serial Peripheral Interface (SPI) and the 16/18/24-bit RGB parallel interface are used in a sequence to communicate data to the display. The SPI interface is first used to initialize the display parameters through command registers. Once initialized, the display can receive data over the RGB parallel interface at a higher speed. This data can be sent in segments of 16, 18 or 24-bit lengths depending on what is specified by the SPI initialization commands.

Sorry for pretty noob question, but.. theoretically.. would it be possible to initialize display using 3 wire SPI using some other library or just raw code, and then drive same display using 18 bit RGB making use of Your library? Is Your library limited to 8 Bit parallel?

[Bodmer]

The RGB interface is intended to be driven by a dedicated hardware graphics chip and requires other control signals (e.g. dot clock at 6.35MHz, v sync and h sync etc) these have very critical timing requirements that would be tricky to generate with a microcontroller.

[flykarlos]

thanks for reply, I thought so that it is not that simple. I have to stick with other display models. Thanks again :)

[mm108]

@flykarlos hi, any (further) luck with getting ST7701S to work? I am looking at a 2.8 inch TFT LCD ,480x640 with ST7701S driver IC. I am planning to get a bunch of random boards ( but only those with higher resolution ).

The other one I am getting is driven by HX8357 (3.2 inch/480x320). This I think some folks have been able to get it to work so I haven't researched that much yet. This one I think should not be a problem.

And thanks to you all wonderful folks who have built this library and contributed to it's advancements.

[flykarlos]

@flykarlos hi, any (further) luck with getting ST7701S to work? I am looking at a 2.8 inch TFT LCD ,480x640 with ST7701S driver IC. I am planning to get a bunch of random boards ( but only those with higher resolution ).

The other one I am getting is driven by HX8357 (3.2 inch/480x320). This I think some folks have been able to get it to work so I haven't researched that much yet. This one I think should not be a problem.

And thanks to you all wonderful folks who have built this library and contributed to it's advancements.

Hi m-menon
Unfortunately I was not able to modify Bodmer's library or find any other library currently supporting 9bit SPI ST7701s display.
There is a library called Arduino_GFX whose owner says about adding optional support to 9bit SPI in the future.
I chosen another approach and I'm using raspberry pi together with hyperpixel 2.1 round display. I wanted to stick with ESP32 /ESP32S and 480x480 round display, but I had to switch to RPI to be able to continue my project with round display.

My opinion about Bodmer's library stays unchanged- Greatest library that I ever used, and best support I have ever received.

Thanks Bodmer once again!

[mm108]

Thanks @flykarlos for the update. I checked the Arduino_GFX and it's work in progress but it does support 9 bit SPI and a bunch of other chips. One of the first things with Arduino_GFX is the (slower) speed. It does support a bunch of driver ICs and it does include couple of those that I am interested in.

Also another "temporary" option for those really in need of high res displays on their ESP32, there is this option on Tindie. It is out of stock though and kinda expensive for those who just want a high res display on esp32 without the other bells and whistles.

As for Bodmer's TFT_eSPI, I have the same opinion as you. It is one of THE BEST libraries out there and the support from Bodmer has been nothing short of amazing. TFT_eSPI is my go-to TFT display library unless there is a limitation where a solution, workaround or hack is impossible. I can't thank Bodmer enough for TFT_eSPI.

And ya thanks once again for the update.

[projectitis]

I've got a device with the ST7701S display working with a sample project using ESP-IDF (this one, in fact).
I'm now converting to PlatformIO and Arduino using TFT_eSPI, and am adding support for ST7701S to TFT_eSPI.
I have the startup sequence, the rotation and most of the commands/defines...

However, ST7701S does not have GRAM, and as such does not have a CASET, PASET, RAMWR or RAMRD command. These are required in ST7701S_Defines.h.
@Bodmer, is there another display you support that doesn't have GRAM that I can copy as an example?
If this is the first GRAM-less display, I suspect there will be lots of other changes required to support it, and that would be beyond me.

[DrJaymz]

I am using the lilygo-t-rgb with this display. I am also using the TFT_eSPI library. What I am doing is preparing a main sprite and then pushing the memory to the panel object.

// finally output the image
panel.pushColors(0, 0, WIDTH, HEIGHT, (uint16_t *)fbuff.getPointer());

I don't really know how efficient doing it this way is, but I also didn't want to learn yet another framework. Copying memory feels like it should be reasonably quick and I find it takes me about 70ms to do that. So its a bit like an unnecessary double buffer. This means that I can use the functions in the library and presumably there will be some limitations but I achived what I set out to.

If there's a better solution - I would love to hear it.

[projectitis]

@DrJaymz are you sure you are using TFT_eSPI? If so, which TFT_Driver are you using - I can't find a matching driver for the ST7701s, or a user-setup, and same for the lilygo-t-rgb.

I have my code working with a different display library (TFT library for Arduino) which supports the ST7701s but I haven't been able to get it to work with TFT_eSPI.

Sorry - reading your post again it sounds like you are using a combination of libraries, correct? TFT_eSPI just for its drawing routines, and then pushing the buffer to the TFT using another library?

[Sturmbock]

I have a related problem with a ST7701 display, but have a solution to it in part. I am using an Adafruit Qualia ESP32S3 card to interface to it, so I can use the TFT_eSPI library to manipulate sprites and push them to memory (pushSprite). I then use GFX (draw16bitBeRGBBitmap) to draw them to the display. The bit I can’t find a solution to is, I normally use the TFT library (pushRotated) to push the needle on a gauge at a specific angle to the display. The GFX library does not seem to support this, any ideas most welcome.

[bajacondor]

@DrJaymz , Can you provide a bit more context/example of your approach? I'm trying to do something similar. I have a bus to the panel working with esp_display_panel, I would like to write a TFT_eSPI buffer directly to that panel so that I can draw with TFT_eSPI and write to esp_display_panel's bus. Is that what you are doing?

[DrJaymz]

@bajacondor Sure. Basically you have an instance of TFT_eSPI just to create a sprite which you draw on as you normally would. Then you copy that sprite to the panel its a memory copy so its quite fast.

LilyGo_RGBPanel panel;

// Initialize T-RGB, 
panel.begin(LILYGO_T_RGB_ORDER_BGR));
   
//create an instance of TFT_eSPI
TFT_eSPI tft = TFT_eSPI();

//create a sprite
TFT_eSprite fbuff= TFT_eSprite(&tft);

// do all your stuff with the sprite (keep it global so the memory stays static
fbuff.createSprite(WIDTH, HEIGHT);
fbuff.setColorDepth(16);

//draw whatever...
fbuff.<draw whatever you like using TFT_eSPI>
sprintf(strBuff, "%0.0f", vs);
fbuff.drawString(strBuff, vsiLeft + 8, vsiBug, GFXFF);
fbuff.drawWedgeLine(centerX, centerY, posX, posY, 8, 4, needle_colour);

// finally output the image - this copies the sprite memory directly to the panel
panel.pushColors(0, 0, WIDTH, HEIGHT, (uint16_t *)fbuff.getPointer());

If you don't use the TFT_eSPI then you're limited to much simpler primatives or using another library which I wasn't familiar with.

[bajacondor]

Hi James, Thanks for your response! I actually got this working just as you say. I'm using the esprssif esp_display_panel lib so I'm pushing to the screen with the drawBitmap() method. I'm having a couple issues that I'll mention in case you know of any better solutions: 1. The endian-ness of colors is reversed. I'm having to shift all my colors when rendering the final sprite. 2. Gradients are banded and look wrong. I think this probably has to do with #1 above. 3. Performance is pretty bad with larger sprites. I was surprised that the bottleneck is not drawing to the screen (it's a 480x480 RGB565) but the layering of the sprites in memory. I'm trying to do some fullscreen rotation, so the main sprite has to be a bit bigger than the screensize, then I use pushRotated() to another screen-size sprite, which then renders. I'm only getting ~4 fps with this method. What kind of fps do you see? Is there anything I can do to speed things up? Thank you!!

…

On Mon, Sep 2, 2024 at 11:52 PM James ***@***.***> wrote: @bajacondor <https://github.com/bajacondor> Sure. Basically you have an instance of TFT_eSPI just to create a sprite which you draw on as you normally would. Then you copy that sprite to the panel its a memory copy so its quite fast. LilyGo_RGBPanel panel; // Initialize T-RGB, panel.begin(LILYGO_T_RGB_ORDER_BGR)); //create an instance of TFT_eSPI TFT_eSPI tft = TFT_eSPI(); //create a sprite TFT_eSprite fbuff= TFT_eSprite(&tft); // do all your stuff with the sprite (keep it global so the memory stays static fbuff.createSprite(WIDTH, HEIGHT); fbuff.setColorDepth(16); //draw whatever... fbuff.<draw whatever you like using TFT_eSPI> sprintf(strBuff, "%0.0f", vs); fbuff.drawString(strBuff, vsiLeft + 8, vsiBug, GFXFF); fbuff.drawWedgeLine(centerX, centerY, posX, posY, 8, 4, needle_colour); // finally output the image - this copies the sprite memory directly to the panel panel.pushColors(0, 0, WIDTH, HEIGHT, (uint16_t *)fbuff.getPointer()); — Reply to this email directly, view it on GitHub <#1055 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAM4MO3LTTNBGEPASXZ743ZUVMBVAVCNFSM4YXGDQX2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBVGI4DAMBV> . You are receiving this because you were mentioned.Message ID: ***@***.***>