High speed vector graphics engine. 3.2" TFT Lcd screen.

Hi Mael, I have Sainsmart kit (Arduino mega2560 + TFT Shield + 3.2" TFT Lcd screen). I replace original UTFT with yours optimized library, but it doesn't work fine.

Hi Rivinoo,

With the original lib, do you use this constructor "UTFT myGLCD(ITDB32S,38,39,40,41);" ?
Youre screen is really ITDB32S compatible ?

If it's, I think it's a timming problem.
Try this :
Edit HW_AVR_defines.h
change this line :

#define pulse_low_WR PORTG &= ~(1<<2); __asm__("nop\n\t"); __asm__("nop\n\t"); __asm__("nop\n\t"); PORTG |= (1<<2)

by it :

#define pulse_low_WR PORTG &= ~(1<<2); delayMicroseconds(1); PORTG |= (1<<2)

Yes my screen is ITDB32S.
I change that line and now works very fine!

I try "UTFT_Demo_320x240" without delay(2000);

This is my result:Original UTFT: Mael modification:21218 us13207 us

Thank you!

And you can optimize :
Replace "delayMicroseconds(1);" by many "asm("nop\n\t");"
try until it's work. I need 3 nop, perhaps for you it's 4 or 5.

Mael:
And you can optimize :
Replace "delayMicroseconds(1);" by many "asm("nop\n\t");"
try until it's work. I need 3 nop, perhaps for you it's 4 or 5.

You don't need the trailing \n\t on the asm. While it is implied in the asm with no arguments, I always prefer to be explicit and use things like asm volatile ("nop"); to be clear that you don't want the compiler to optimize around the asm's. You can group multiple nops together:

__asm__ volatile ("nop\n\tnop\n\tnop\n\tnop");

Or, I tend to prefer to have instructions on separate lines:

__asm__ volatile ("nop\n\t"
                              "nop\n\t"
                              "nop\n\t"
                              "nop");

This uses the string token pasting feature that was first added in the C 1989 standard.

we are looking for pyro :sleeping:

It is nice to see all the work being put to this screen! Thanks!

hi there pYro_65,
are you following this topic, do you plan to share your results as you wrote?
regards,
K

hi i tried the above library it is much faster wow but.
i do have a problem i use 2 interupts pin 18 and 19 for my speedometer and rev counter

,the code and pins work fine with hennings library , is there anyway to fix this again .
please would be great to use the extra speed i am making a trip computer , for a car ,
i use hall sensors to get trigger from wheel and camshaft , via interupts ,

also i sense inject pulse via a optocoupler , i had all this working on my 128x64 glcd but decided i wanted touch and touch start ,

please please any ideas thanks

Hi,

I know this topic is a bit old, but... has the pyro_65 work been lost or with mäel optimization is just 'enough' improvement?

I see pyro_65 is still quite (a lot) active in the forum...

No, my work isn't lost. Its just unfinished on an old hard drive. I have lots of things happening at the moment however I do want to put the parts I did finish up on my website one day.

I'll have to dig out the hard drive, however there were some problems with the library. It only works on certain SSD1289 displays. Some versions use different resistors in the COG panel and cannot use some of its features. I have a few programs using the library now, so it is not lost yet.

Mael:
Here is my UTFT version with optimizations speed of execution and ROM space used.

BE CAREFUL : It's work only with SSD1289 screen on Arduino Mega.
Screen : SainSmart 3.2" TFT LCD Display+Touch Panel+PCB adapter SD Slot for Arduino 2560,
Shield : SainSmart TFT LCD Adjustable Shield for Arduino Mega 2560 R3 1280 A082 Plug.

To optimize I examined the most frequently used functions.
For example:
drawPixel calls SetXY, SetXY makes a test on the target screen and calls LCD_Write_COM, it calls LCD_Write_COM and LCD_Write_DATA, they test the type of transfer and call LCD_Writ_Bus. LCD_Writ_Bus tests the type of target screen and then writes the data to the destination ports of the screen !!!
LCDxxx methods are called very often then it is they need to optimize.
I remove the tests "switch (mode)" or "if (display_transfer_mode! = 1)", which become useless if I still have the same screen.
I'm simplifying and removing cascades calls are expensive (passing parameters to the stack, context switching, etc.).

In the zip archive, I put a new example : Bench.ino (use this one to test), I removed some tools.

I also made a mode "x terminal" which sending display information to the serial port.
I wrote a program (in C #) that runs on the PC, he receives display information and draws on the PC screen: this is a simulator screen.
I left this feature in the code archive. It is off by a compiler directive (so this code is disabled).
Example :

void UTFT::drawPixel(int x, int y)

{
//don't worry about this code. this code is not compiled (Terminal_x not defined)
#ifdef TERMINAL_X
 //terminal x
 //0x81 [ID], [size], [datas]  
 uint8_t Trame[7];
 Trame[0] = 0x81; //ID de Terminal X
 Trame[1] = sizeof(Trame)-1; //taille de la sous-trame (à partir de cet endroit, on compte la size mais pas l'ID termX
 Trame[2] = TX_DRAWPIXEL; //ID ordre d'aff pixel
 Trame[3] = x >> 8; //MSB x1
 Trame[4] = x; //LSB x1
 Trame[5] = y >> 8;
 Trame[6] = y;
 Serial.write(Trame, sizeof(Trame));
 //return;
#endif
...




If anyone is interested, I can share my C # program...
I preferred share code in the current state, because if I take the time to clean it before, it will never be perfect and finally I will send nothing ;)

Finally, Perhaps the best is make a depot GIT.
I hope that pYro_65 will could give us his optimizations or ideas for a common version. :)

*(Sorry if I speak bad English, I took lessons ;) )*

bye.
Maël.

hello Mael, I am using your optimized library and I congratulate you because it's really fast.
But I have a problem, with the original UTFT I used also libraries UTFT_tinyFAT and UTFT_Geometry while your library can not use them, it gives me an error. You probably need to be changed.
Can you help me somehow?
Or is there someone else who can help me?
thanks
Excuse me for my LITTLE English :*

I just tried Mael library version but... just... white screen, nothing more. I think my LCD is the same as yours. Any help?

Anyway I got those results (As I cannot see anything drawn I'm not sure if they can be trusted):
ready.
start...
37252 us : clrScr
24 us : DrawPixel
228 us : DrawPixel x 10
8 us : SetColor
8 us : SetBackColor
5800 us : FillRoundRect 40x40
636 us : DrawRoundRect 40x40
916 us : drawLine 40x40
152 us : draw Vertical Line 40
144 us : draw Horizontal Line 40
1484 us : FillRect 40x40
8 us : SetSmallFont
2300 us : Print 001
2300 us : Print Abc
2584 us : printNumI(123)
12 us : SetBigFont
4336 us : Print 001
4420 us : printNumI(123)
2416 us : draw bitmap 32x32
16 us : Touch Screen DataAvailable
40 us : Touch Screen Read
16 us : Touch Screen getX, getY
finish in 84308 us.

With the original library:

ready.
start...
114588 us : clrScr
212 us : DrawPixel
2064 us : DrawPixel x 10
12 us : SetColor
8 us : SetBackColor
14500 us : FillRoundRect 40x40
2244 us : DrawRoundRect 40x40
4160 us : drawLine 40x40
472 us : draw Vertical Line 40
472 us : draw Horizontal Line 40
4368 us : FillRect 40x40
16 us : SetSmallFont
7396 us : Print 001
7212 us : Print Abc
7468 us : printNumI(123)
8 us : SetBigFont
13552 us : Print 001
13676 us : printNumI(123)
11084 us : draw bitmap 32x32
16 us : Touch Screen DataAvailable
40 us : Touch Screen Read
16 us : Touch Screen getX, getY
finish in 217392 us.

pYro_65, I would like you to consider to just post your library as it is. You/We can always improve it later :slight_smile:

by the way... has anybody seen this? Seems very related: http://gizmogarage.net/c-vs-assembler-performance-on-avr/

Hernexto:
I just tried Mael library version but... just... white screen, nothing more. I think my LCD is the same as yours. Any help?

Anyway I got those results (As I cannot see anything drawn I'm not sure if they can be trusted):
...
pYro_65, I would like you to consider to just post your library as it is. You/We can always improve it later :slight_smile:

by the way... has anybody seen this? Seems very related: http://gizmogarage.net/c-vs-assembler-performance-on-avr/

factor 2.5 is not bad, pity it didn't show anything.
imho you can trust these numbers (90% confidence) as they are not that extreme faster (even one slower)

Bookmarked that gizmogarage video. (awesome)
But as the author says it is generic code versus optimized dedicated code.
Really useful when you have a need for speed!
thanks for that link.

I dunno, if you have a need for speed, the first thing you should do is move up to a faster processor. You can get Arm processors that support the Arduino libraries that run 4-8 times faster than a Mega (Teensy 3.1 runs at 96Mhz compared to 16Mhz for the Mega, and given the Teensy is a 32-bit processor, it means it does things in fewer cycles, which gives you an additional boost in speed).

Then if you are willing to change platforms, the Linux SBC's (single board computer) will run much, much faster, and they have hardware floating point in case you need it (Beaglebone Black runs at 1Ghz, Rasberry Pi at 700Mhz).

agree, but imho part of the Arduino fun is to get "most" speed from a "slow" processor

@Hernexto: Are you sure that you used the right init for the TFT?

I had to replace

UTFT myGLCD(0);

with

UTFT myGLCD(ITDB32S,38,39,40,41);

to get it working. I also had to add one "nop" in HW_AVR_defines.h to remove some unwanted glitch:

#define pulse_low_WR PORTG &= ~(1<<2); __asm__ volatile ("nop"); __asm__ volatile ("nop"); __asm__ volatile ("nop"); __asm__ volatile ("nop"); PORTG |= (1<<2)

BTW: I have tried to merge Maels extensions with the 2.75 version of Henning Karlsens UTFT to get UTFT_tinyFAT working and so that I can use

myGLCD.setBackColor(VGA_TRANSPARENT);

I have tested my result with Hennings "UTFT_Demo_320x240", Maels "Bench" and my own little Demo that uses SD card access with UTFT_tinyFAT and UTouch as well as UTFT. My attached version includes the additional "nop" already. Works fine for me, maybe you find it useful as well.

Maels "Bench" runs in 91720 usec instead of 217292 usec.

UTFT_optimised_275.zip (2.61 MB)

hampf,

I tested your UTFT_optimised_275 library. This are my results with the "Bench" test.

ready.
start...
209900 us : clrScr
24 us : DrawPixel
196 us : DrawPixel x 10
12 us : SetColor
8 us : SetBackColor
5848 us : FillRoundRect 40x40
628 us : DrawRoundRect 40x40
800 us : drawLine 40x40
148 us : draw Vertical Line 40
144 us : draw Horizontal Line 40
1648 us : FillRect 40x40
8 us : SetSmallFont
2372 us : Print 001
2380 us : Print Abc
2652 us : printNumI(123)
8 us : SetBigFont
4552 us : Print 001
4648 us : printNumI(123)
2368 us : draw bitmap 32x32
16 us : Touch Screen DataAvailable
32 us : Touch Screen Read
16 us : Touch Screen getX, getY
finish in 257644 us.

I am most interested in the clrScr function. It is a lot faster as before. But your Bench test says the clrScr function is about 37252 us. That is a lot faster as here. I use a ATMEGA 2560 board.

Is there something i can do to speed this up?

Leon.

Hallo friends..

I use the Library with an ATmega128 and a TFT 3.2 SainSmart. It is very fast but I have short disturbances on screen in landscape mode. See not filled circles in video.

Youtube SainSmart TFT 3.2 Fast Draw - YouTube

The cause is an incorrect xy values in SSD1298 registry for landscape mode:

//*************************************************************************
// init SainSmart 3.2 TFT
//*************************************************************************
void init_LCD(void)
{

// set LCD Reset and CS
SET_RESET;
_delay_ms(10);
CLR_RESET;
_delay_ms(30);
SET_RESET;
_delay_ms(30);

CLR_CS;

// write command and data
write_com_data(0x00, 0x0001); // OSCEN
_delay_us(1);
write_com_data(0x03, 0xA8A4); // Powercontrol
_delay_us(1);
write_com_data(0x0C, 0x0000); // Powercontrol 2 // 5,1V
_delay_us(1);
write_com_data(0x0D, 0x080C); // Powercontrol 3 // Vref 2.0 * 2.5
_delay_us(1);
write_com_data(0x0E, 0x2B00); // Powercontrol 4
_delay_us(1);
write_com_data(0x1E, 0x00B7); // Powercontrol 5
_delay_us(1);

// cange X side
//write_com_data(0x01, 0x293F); // 240x320 Potrait mode
write_com_data(0x01, 0x2B3F); // 320x240 Landscape mode
_delay_us(1);

write_com_data(0x02, 0x0600); // LCD Driving Waveform Control
_delay_us(1);
write_com_data(0x10, 0x0000); // Sleepmode
_delay_us(1);

// cange Y side
//write_com_data(0x11, 0x6070); //
//write_com_data(0x11, 0x6078); // 240x320 Portrait mode
write_com_data(0x11, 0x6838); // 320x240 Landscape mode
_delay_us(1);

write_com_data(0x05, 0x0000); // Compare register
_delay_us(1);
write_com_data(0x06, 0x0000); // Compare register
_delay_us(1);
write_com_data(0x16, 0xEF1C); // Horizontal Porch
_delay_us(1);
write_com_data(0x17, 0x0003); // Vertical Porch
_delay_us(1);
write_com_data(0x07, 0x0230); // Display Control (display off)
_delay_us(1);
write_com_data(0x0B, 0x0000); // Frame Cycle Control
_delay_us(1);
write_com_data(0x0F, 0x0000); // Gate Scan Position
_delay_us(1);
write_com_data(0x41, 0x0000);
_delay_us(1);
write_com_data(0x42, 0x0000);
_delay_us(1);
write_com_data(0x48, 0x0000);
_delay_us(1);
write_com_data(0x49, 0x013F);
_delay_us(1);
write_com_data(0x4A, 0x0000);
_delay_us(1);
write_com_data(0x4B, 0x0000);
_delay_us(1);
write_com_data(0x44, 0xEF00);
_delay_us(1);
write_com_data(0x45, 0x0000);
_delay_us(1);
write_com_data(0x46, 0x013F);
_delay_us(1);
write_com_data(0x30, 0x0707);
_delay_us(1);
write_com_data(0x31, 0x0204);
_delay_us(1);
write_com_data(0x32, 0x0204);
_delay_us(1);
write_com_data(0x33, 0x0502);
_delay_us(1);
write_com_data(0x34, 0x0507);
_delay_us(1);
write_com_data(0x35, 0x0204);
_delay_us(1);
write_com_data(0x36, 0x0204);
_delay_us(1);
write_com_data(0x37, 0x0502);
_delay_us(1);
write_com_data(0x3A, 0x0302);
_delay_us(1);
write_com_data(0x3B, 0x0302);
_delay_us(1);
write_com_data(0x23, 0x0000);
_delay_us(1);
write_com_data(0x24, 0x0000);
_delay_us(1);
write_com_data(0x25, 0x8000);
_delay_us(1);
write_com_data(0x4F, 0x0000); // set GDDRAM Y address
_delay_us(1);
write_com_data(0x4E, 0x0000); // set GDDRAM X address
_delay_us(1);
write_com(0x22);
_delay_us(1);

// draw black screen
fillrectangle(0,0,320,240,color_black);
// set display on
write_com_data(0x07, 0x0233); // Display Control (first display)
_delay_us(1);
write_com(0x22);
_delay_us(1);
}

//*************************************************************************
// set cursor for SainSmart 3.2 TFT
//*************************************************************************
void set_Cursor(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2)
{

// swap XY for landscape mode 320x240

uint16_t temp = x1;
x1 = y1;
y1 = temp;
temp = x2;
x2 = y2;
y2 = temp;
y1 = 319-y1;
y2 = 319-y2;
temp = y1;
y1 = y2;
y2 = temp;

//write_com_data(0x44, ( x2 << 8 ) + x1) ; // disruptions caused in screen

write_com_data(0x44, ( x2 << 8 ) ) ; no disruptions
write_com_data(0x45, y1);
write_com_data(0x46, y2);

write_com_data(0x4E, x1);
write_com_data(0x4F, y1);
write_com(0x22);

}

MiniScope function in my DIY Synthesizer its function now without disturbance :slight_smile:

New video without disturbance:

Old video with disturbance:

My synthesizer project in german:
http://www.cczwei-forum.de/cc2/thread.php?postid=88884#post88884

My synthesizer project in english:
http://mutable-instruments.net/forum/discussion/2504/shruthi-synthesizer-and-my-wave-1#Item_893

Greetings from germany. Rolf