ST7796S 16bit speed

I got this display https://www.aliexpress.com/item/4000126450233.html (ST7796S, set to 16bit, running on MEGA2560) and got it working with setting special and mega16bit. Total running time for graphicstest is 6,45 seconds. Is that what can be expected? The source states 2,7seconds, but no resolution is mentioned.

If more info is required, happy to provide them.

The 2.7 sec probably refers to a 240x320 geometry for comparison.

From special.h

//#define USE_MEGA_8BIT_SHIELD      // 4.7sec Mega2560 Shield
//#define USE_MEGA_8BIT_PORTC_SHIELD // 4.7sec Mega2560 Shield
//#define USE_MEGA_16BIT_SHIELD     // 2.14sec Mega2560 Shield

320x480 would be 2x the time for a 240x320 screen. Perhaps I should do some up to date timings.

All the same, 6.45 sec is not unreasonable for 320x480. Much better than a 320x480 Uno Shield on a Mega2560

David.

Edit. Just ran a 320x480 RM68140 with USE_SPECIAL, USE_MEGA_16BIT_SHIELD and it took 5.90sec. Which is clearly more than the suggested 4.28sec
I do have a regular 320x480 ST7796S Blue Uno Shield. 14.01sec

Ok. So, sounds like it is what can be expected.
Do you know an other display chip that has better performance given the "slow" Mega2560 clock?
I try to run it with a DUE and post that here too. Might take some time before I post.

The Mega Shield uses data bus pins suited to the ATmega2560
These end up as random pins on a Due. So the TFT data speed will not be much better.

Obviously computational speed is better on a 84MHz Cortex-M3.
For example decoding JPEGs is much faster.

Seriously, sit down with a nice cup of tea.
Design your project. Minimise the amount of TFT updating.

All TFT controllers are faster than the Mega2560. There is no point in changing controller with an AVR target.
An SSD1963 controller is faster than ST7796 but still dumb. You need a fast ARM to achieve top SSD1963 speed.
You can use an intelligent controller like RA8875 which will do lightning fast graphics with few commands on the data bus. But some individual pixel operations will be slower.
Or use a dumb controller with its own MCU like Nextion or FTDI. i.e. an intelligent display.
Likewise, some operations will be difficult.

You really need to provide an explanation of what you want to do (in English)

David.

Ah, had hoped that the DUE was more compliant with the mega on port / header pinning.

Anyway I did the test and came out at 3.62sec. I assume it would be possible to rewire by hand to more suiting ports on the DUE. Question is, how much would that improve. Do you have any guestimates what might be possible? Don't mind to put some time in it.

Yes, do realise that the MCU needs to do a lot of computations when redrawing a (full)screen. The actual application will not require smooth 120fps video, but rather static screens with some buttons. However, the switching from one page to the other needs to take as little time as possible to avoid visible flickering. Hence my idea to use a DUE for raw power at reasonable cost. Obviously other options exist too: ESP32 just to name one. But have no experience yet with that one.

Tinkered with the Nextion too, but the LCD used has very bad viewing angles. Nextion can do an IPS variant, but MOQ is 10000 units so didn't ask for a price quote.

Also note that at current it is at prototype level, so fast results (even if not 100%) are ok. Just to show what could be done, with some fitting and meaningful UI.

I have had USE_DUE_8BIT_PROTOSHIELD since the dawn of time. i.e. a Protoshield that receives regular Uno Display Shields.
Since it maps to 8 consecutive PORT bits on the Due it works very fast.

You could map your Mega Display Shield to 16 consecutive PORT bits on the Due.

Or you buy a 40-pin Display with the appropriate 40-pin Adapter Shield.
These come in both Mega and Due versions. The Due version has sensible data bus mapping.

What do you really want to do?
Displaying graphical animations is one thing.
Displaying full colour 480x320 video from an SD card is something else.

David.

Thanks for the input David.

From this Arduino - PinMappingSAM3X I can not really see any consecutive 16bit port mapping, without loosing to much other functionality. What comes closest from my limited knowledge would be Port C with one byte mapped to PC1 - 9 and the other byte to PC12 -19. They are on the same port, but not consecutive. Don’t know it that would work or not.

Ah, just noticed a USE_DUE_16BIT_SHIELD in mcufriend_special.h. On line 666 the settings are defines in detail. That seems to use the same data port mapping as I found above. It does use other pins for the LCD control lines, but they can be used too I think.

Do you think this is a possible solution?

Mapping any groups of pins on an ARM works pretty well. The ARM has a barrel shifter.
So it does not matter if you choose PC1-9 or whatever.

First off, you should think about what you actually want to do and design your project accordingly.

As I said, there are several commercial 40-pin Adapter Shields for the Due.
There are many more Adapters for Mega2560.

Some STM32 devices have special hardware for driving TFTs. Teensy4.0 is very fast.
Anything is better than Mega2560 or STM32F103

Most MCU boards have enough pins for an 8080-8 interface. Some have enough for 8080-16.
ARM and ESP chips have DMA which makes SPI interface attractive (and wastes few pins).
ESP32 has two cores which means one core can decode while the other code sends data.

Life is much easier if you just say what you want to do.

David.

Ok, wired things up with more suitable port mappings. I’ve made an extension to the mcufriend_special.h for my purposes (it really is just a copy of USE_DUE_16BIT_SHIELD, but now I can thinker with it without breaking anything):

#elif defined(__SAM3X8E__) && defined(USE_DUE_16BIT_BREAKOUT)  // 3.95" LCD Mega via break out on DUE
#warning USE_DUE_16BIT_BREAKOUT
#define USES_16BIT_BUS
// configure macros for the control pins
#define RD_PORT PIOA
#define RD_PIN  15     //D24 
#define WR_PORT PIOD
#define WR_PIN  1      //D26
#define CD_PORT PIOD
#define CD_PIN  0      //D25
#define CS_PORT PIOD
#define CS_PIN  2      //D27
#define RESET_PORT PIOD
#define RESET_PIN  3   //D28
// configure macros for data bus 
// DB0..DB7 on PIOC1..PIOC8,  DB8..DB15 on PIOC12..PIOC19
// Pinout on board: D33, 34, 35, 36, 37, 38, 39, 40 => DB0 ..DB7
//                  D51, 50, 49, 48, 47, 46, 45, 44 => DB8..DB15
// MISO, MOSI, CLK from SPI header SPI-1, 3, 4
// touch CS D32, SD CS D30
//
#define CMASKH        (0xFF00<<4)
#define CMASKL        (0x00FF<<1)
#define CMASK         (CMASKH | CMASKL)
#define write_8(x)    { PIOC->PIO_CODR = CMASKL; PIOC->PIO_SODR = (((x)&0x00FF)<<1); }
#define write_16(x)   { PIOC->PIO_CODR = CMASK; \
                        PIOC->PIO_SODR = (((x)&0x00FF)<<1)|(((x)&0xFF00)<<4); }
#define read_16()     (((PIOC->PIO_PDSR & CMASKH)>>4)|((PIOC->PIO_PDSR & CMASKL)>>1) )
#define read_8()      (read_16() & 0xFF)
#define setWriteDir() { PIOC->PIO_OER = CMASK; PIOC->PIO_PER = CMASK; }
#define setReadDir()  { PMC->PMC_PCER0 = (1 << ID_PIOC); PIOC->PIO_ODR = CMASK; }
#define write8(x)     { write16(x & 0xFF); }
#define write16(x)    { write_16(x); WR_ACTIVE; WR_STROBE; WR_IDLE; WR_IDLE; }
#define READ_16(dst)  { RD_STROBE; RD_ACTIVE4; dst = read_16(); RD_IDLE; RD_IDLE; RD_IDLE; }
#define READ_8(dst)   { READ_16(dst); dst &= 0xFF; }

// Shield Control macros.
#define PIN_LOW(port, pin)    (port)->PIO_CODR = (1<<(pin))
#define PIN_HIGH(port, pin)   (port)->PIO_SODR = (1<<(pin))
#define PIN_OUTPUT(port, pin) (port)->PIO_OER = (1<<(pin))

More importantly, the graphicstest now concludes in 2.5 seconds. It really runs smoothly, also the scrolling.

On the functionality: just a few simple screens with buttons, but there will be some images that need to be changing on the fly. The latter will take some MCU resources to do, but judging from my test and the modifications it seems do-able.

Next step will be to use GuiSlice to make some actual screens and test that.

derrudi63:
I got this display https://www.aliexpress.com/item/4000126450233.html (ST7796S, set to 16bit, running on MEGA2560) and got it working with setting special and mega16bit. Total running time for graphicstest is 6,45 seconds. Is that what can be expected? The source states 2,7seconds, but no resolution is mentioned.

If more info is required, happy to provide them.

Well I tryed for a week now, same board, 16bit R5 connected. Not running 8 bit, not running 16 bit. Yes #define USE_MEGA_16BIT_SHIELD, read everything over and over again. JUST A EMPTY SCREEN. Lcdwiki is working fine, any help?

It is relatively complex to configure MCUFRIEND_kbv for a SPECIAL.
You have to edit two files in the library. e.g. delete // on specific lines.
This is too hard for some people.

Since the shield is write-only you have to force the ID to 0x7796 if readID() returns 0xD3D3

So if you like badly-spelled libraries, I suggest that you stick with LCDWIKI.

David.

Well the lcdwiki library is not my favorit, 16bit touch is not provided. To use it you have to alter the code aswell removing // for 16bit code and filling in st7796s as id. No big deal.

But after filling in the special.h of your library, adding support 16 bit for the #define, checking it all for the 10th time, reading the needed same code changes at dozen places on the internet and ending up always with a empty screen. So i found your Adafruit st7796 library too, but same no screen, makes me very sad just for Xmas.

My Adafruit_st7796_kbv is designed for SPI interface.

Seriously. Re-install MCUFRIEND_kbv. Take notes on paper.

Type up your notes to your message.
Then we can see where you have gone wrong.

From the how_to.txt file:

17. If you do not have a standard Uno Shield, you can add a SPECIAL to the mcufriend_special.h
    Edit mcufriend_shield.h:  #define USE_SPECIAL
    Edit mcufriend_special.h: e.g. #define USE_MEGA_16BIT_SHIELD
    If your "special" is write-only,  the library can not read the ID.  It always returns 0xD3D3

Most punters attempt to put those defines into the sketch instead of shield.h and special.h

David.

david_prentice:
My Adafruit_st7796_kbv is designed for SPI interface.

Seriously. Re-install MCUFRIEND_kbv. Take notes on paper.

Type up your notes to your message.
Then we can see where you have gone wrong.

From the how_to.txt file:

17. If you do not have a standard Uno Shield, you can add a SPECIAL to the mcufriend_special.h

Edit mcufriend_shield.h:  #define USE_SPECIAL
   Edit mcufriend_special.h: e.g. #define USE_MEGA_16BIT_SHIELD
   If your “special” is write-only,  the library can not read the ID.  It always returns 0xD3D3



Most punters attempt to put those defines into the sketch instead of shield.h and special.h

David.

Put #include <mcufriend_shield.h> in the code to use
Put mcufriend_shield.h and mcufriend_special.h in the \Arduino Sketchbook\libraries\MCUFRIEND_kbv directory
Change if (ID == 0xD3D3) ID = 0x7796; // write-only shield
// ID = 0x9329; // force ID
Serial.print(“ID = 0x”);
Serial.println(ID, HEX);
tft.begin(ID);

That is the complete story, Thanks David

Please read the instructions that I gave you in #12.
You do not include any extra mcufriend_shield.h

All the example sketches should work when you change one statement in setup()
e.g. Font_Simple.ino
change

    uint16_t ID = tft.readID();
    if (ID == 0xD3D3) ID = 0x9481; //force ID if write-only display
    tft.begin(ID);

to

    uint16_t ID = tft.readID();
    if (ID == 0xD3D3) ID = 0x7796; //force ID if write-only display
    tft.begin(ID);

My apologies. Not every example checks for write-only. But it is a pretty simple fix that you can do. Note that regular Uno shields will read the correct ID anyway.

You are right of course no need to include any extra mcufriend_shield.h, could not find where it was included. So shield is working now with an arduino mega.

The calibration is not working : TouchScreen_Calibr_native gives an error:
Waiting for scroll, then unable to read the position, ... hardware issue

Touch_shield_new

Forcing to start with 0x7796

tft.reset();

ID = tft.readID();

ID = 0x7796;

tft.begin(ID);

Gives a screen with Please Calibrate Portrat values Left = (ECT)

Wiring is: ........

EXIT
Touch screen for loc

Dead screen

David any solution? Thanks!!!!
Rob

The Red Mega2560 Shield has an XPT2046 Touch Controller chip.
So you use XPT2046_TouchScreen.h instead of the TouchScreen.h (that is for bare Resistive Panels).

David.

david_prentice:
The Red Mega2560 Shield has an XPT2046 Touch Controller chip.
So you use XPT2046_TouchScreen.h instead of the TouchScreen.h (that is for bare Resistive Panels).

David.

Where can I find a working sample program to calibrate or see a sample of the working XPT2046_TouchScreen.h for the Red mega ST7796S with XPT2046 touch chip

Thanks for your patience with me,
Rob

Look at this message thread

You will have to configure for your hardware.

But seriously, you would install XPT2046_TouchScreen.h library and run any library examples.

If you have a problem, you can quote official library and quote example by name.

Likewise, if you want help with the programs that I attached.
Please remember that MCUFRIEND_kbv was designed for Mcufriend Uno Shields. Different hardware requires SPECIAL consideration.

David.

"I hope that they will run out of the box for you", well they do not. Changing to the setup ID to 0x7796, still white screen and almost no serial output.

You did buy the same 16bit parallel shieldboard a while ago I did read . I hoped you have figured it out how to use the touch with a suitable library for the arduino Mega. Well reading the SD with a arduino mega connection is a hassle too. Keep me busy this Xmas. Fine days David!!

Rob