Arduino Forum

Community => Exhibition / Gallery => Topic started by: pYro_65 on Jan 01, 2013, 02:19 pm

Title: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 01, 2013, 02:19 pm
Hi all,

I'm currently in the process of building a graphics engine for the SSD1289 display, which at the moment it appears to be quite a popular screen on the forum chat. My main inspiration for leaving the standard libraries and trying to create my own is partly a desire to make an animated game, and also I've noticed a lot of people are very quick to judge the Arduino because its a 'learning tool' and  not 'powerful enough' for their students/needs.

The system I have created has been optimised from the ground up. It saves somewhere in the order of millions of instructions per second compared to an equivalent implementation using the UTFT library. Don't get me wrong, the UTFT is an excellent library, its just not suitable for my needs. For example, a fill screen operation with UTFT is ~560ms, my implementation is ~19.7ms, gradient fills are only a little more expensive.

I'm about to start a new line algorithm targeted directly to the hardware ( TFT ), which will save somewhere between 8, and 18 instructions per pixel when drawing diagonal lines.

Drawing lines and gradients are great tests, but I needed a real world test to give it a workout, so I created an app to benchmark my library's features and it has blown my expectations. I'm hoping that when I release my library over the next few months I can help raise the bar for Arduinos capabilities as a graphics processor.

For now here is a video of my test app running. I have some screen shots also, but the read code timing is slightly incorrect so there are a few misaligned pixels. It is an audio analyser running a 128 point FFT. I have yet to put in many features like text rendering and orientation rotation, but the core is running great.
Sorry about the video quality, we had eaten all the camcorders so I had to film this on a potato.

I will also sort out a .hex file soon for download if anybody with the display is interested.

www.youtube.com/watch?v=8beizVtMGrc

As you can see, it goes so fast the camera sees multiple lines.

(http://genx.biz/Images/Screen0.png)

(http://genx.biz/Images/Screen1.png)

(http://genx.biz/Images/Screen2.png)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: strykeroz on Jan 01, 2013, 02:34 pm
Wow those improvements are significant.  Have you hosted this project somewhere so we can follow along?

Sorry about the video quality, we had eaten all the camcorders so I had to film this on a potato.
I can see how that might have hindered your progress :)

All the best ! Geoff
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 01, 2013, 03:40 pm

Wow those improvements are significant.  Have you hosted this project somewhere so we can follow along?

Sorry about the video quality, we had eaten all the camcorders so I had to film this on a potato.
I can see how that might have hindered your progress :)

All the best ! Geoff


No, I haven't got a project anywhere yet, I'm thinking of maybe starting something to document it. A blog might be what I need, never done one though. Either way, I'll find some way of keeping people in the loop.

Cheers.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: 997_1 on Jan 01, 2013, 05:43 pm
Very impressive, please do keep us in the loop on progress!
I'm curious what hardware you are using?
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: robtillaart on Jan 01, 2013, 05:58 pm
Quote
A blog might be what I need, never done one though. Either way, I'll find some way of keeping people in the loop.

You can post beta versions of the lib just here in this thread giving people the opportunity to react, review code and help you writing test programs.

Are you using Bresenham's line algorithm?
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 01, 2013, 06:37 pm

Very impressive, please do keep us in the loop on progress!
I'm curious what hardware you are using?


The Arduino is the Mega 2560 (http://arduino.cc/en/Main/ArduinoBoardMega2560), I'm also using the sainsmart shield kit for the SSD1289 display driver, I don't want to link or advertise, but it made the whole process significantly easier.

The display is a 240RGB X 320 3.2" TFT LCD driven by an SSD1289 (http://www.solomon-systech.com/en/product/display-ic/smart-tft-lcd-driver-controller/ssd1289/) chip.

I managed to take screen shots by using the information found in this thread (http://arduino.cc/forum/index.php/topic,135848.0.html) to modify the shield.

Not hardware related, but this thread helped me get the screen shots off the modified board: http://arduino.cc/forum/index.php/topic,139663.0.html.

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 01, 2013, 06:45 pm

Quote
A blog might be what I need, never done one though. Either way, I'll find some way of keeping people in the loop.

You can post beta versions of the lib just here in this thread giving people the opportunity to react, review code and help you writing test programs.

Are you using Bresenham's line algorithm?


No, at the moment it uses an algorithm that digests lines into vertical and horizontal components. The hardware can draw runs very fast compared to per pixel manipulation. These displays have a very mild hardware accelleration. The next algorithm I've planned uses diagonal runs; combined with the TFT instruction set, diagonal lines should be a minimum of 2 - 4 times faster depending on their length.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: guix on Jan 01, 2013, 07:08 pm
Want!
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 02, 2013, 05:05 pm
I have a copy my app in progress ready for a view if anyone is interested.

This is the hardware I'm using: (http://www.sainsmart.com/media/catalog/product/cache/1/image/265x265/b97a0c6c1d16e76f7464abfcbb6a0a8d/0/3/03_10.jpg) (http://www.sainsmart.com/arduino-compatibles/sainsmart-kit-1/sainsmart-mega2560-board-3-5-tft-lcd-module-display-shield-kit-for-atmel-atmega-avr-16au-atmega8u2.html)

If you use the screen without a shield, this link here has images of the pinouts: http://arduino.cc/forum/index.php/topic,135848.0.html
The web also has lots of info.

Read is disabled, if you have it usable ( not by default on TFT shield ), simply tie it to 5v through a 10k resistor.
The touch screen is set to my default, so it will be interesting to see if the touch screens behave the same.

The hex can be uploaded using avrdude, Arduino IDE gives the paths during an upload stage. My output looks like this:
Quote
D:\arduino-1.5.1r2/hardware/tools/avr/bin/avrdude -CD:\arduino-1.5.1r2/hardware/tools/avr/etc/avrdude.conf -q -q -patmega2560 -cwiring -PCOM4 -b115200 -D -Uflash:w:C:\Users\Chris\AppData\Local\Temp\build6011674283074080745.tmp/Test.cpp.hex:i


The serial port and location of the hex file need to be set ( Arduino should be using the right port hopefully if you copy the paths out. )

If I was using the E drive to store my hex, I would modify the path like:
Quote
D:\arduino-1.5.1r2/hardware/tools/avr/bin/avrdude -CD:\arduino-1.5.1r2/hardware/tools/avr/etc/avrdude.conf -q -q -patmega2560 -cwiring -PCOM4 -b115200 -D -Uflash:w:E:\AudioScope.hex:i


I have windows, so I run cmd.exe then copy in the above text and hit enter.

You need to be logged in to see the files, I'll put all my stuff up on a separate server one day.

Edit: forgot to mention, the input is analog pin '0'
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: guix on Jan 02, 2013, 07:08 pm
pYro I don't really care about an oscillator (or whatever it is), I'm more interested about testing your fast library and see the differences (in the code) between it and UTFT. I'm stuck converting what I can read from the SSD1289 datasheet to a C++ code (timing, etc)...Your lib will teach me a lot, I think :)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: CrisEg on Jan 02, 2013, 09:53 pm
Great! Could you please release sources?
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 03, 2013, 05:38 am
Quote
Great! Could you please release sources?


Yeah hopefully in the next two or three weeks I'll have something ready for sharing. The library is large and not very Arduino friendly at the moment. I want to release the library with a set of simple examples in the download, this means my interface needs some a lot of work. I also want to have a look at all the different GNU licences that are available for use.

Quote
pYro I don't really care about an oscillator (or whatever it is), I'm more interested about testing your fast library and see the differences (in the code) between it and UTFT. I'm stuck converting what I can read from the SSD1289 datasheet to a C++ code (timing, etc)...Your lib will teach me a lot, I think


I'm sure you will find it interesting. There is a lot I have to do yet, the read code I was working on from your thread (http://arduino.cc/forum/index.php/topic,135848.0.html) helped me solve a problem why my gradients where incorrect. It didn't solve the read code, however the same fix can be applied to vertical and horizontal lines. I'm working on this now and it should remove between 16 and 32 instructions per line.

My clear screen suffers the same bug, in fact all the functions drawing bulk amounts of pixels can be sped up. This is important as they all where drawing to few or too many pixels.

The reason my code works now is the write window prevents pixels drawing out of bounds, so I simply added extra pixels to the write, the window would overflow and the extra pixels would fill the missing areas at the start of the write operation. This hindered the gradient as the start line had some of the end colour written on to it, so I made the gradients 1px larger and made them all overlap hiding the first line of each gradient.

So to end a short story, long; I still have a lot of nit picking to do...
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vasco on Jan 10, 2013, 05:09 pm
I use the same screen in my project so I'm watching with interest!
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: CrisEg on Jan 12, 2013, 01:36 am
I can't wait to see the sources.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: jake1981 on Jan 14, 2013, 10:24 pm
Great results. Anxious here too..
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 15, 2013, 12:30 am
I've only just finished some major improvements, and started tidying up the source. I have to work today, but over the next 2-3 days I'll try and have the first version ready. I have just embedded Henning Karlsens UTouch library into it, with a few speedups via port mapping and an additional control mode.

I'm almost finished adding rotation to the code ( why utouch was embedded, it needs to rotate as well ). By using the building blocks I've provided, it will be easy to control orientation with an accelerometer for instance, like android.

I'm going to focus on text rendering now so there is a more 'complete' release for everyone to try. But regardless of completion, I'll post something by Thursday night.

Cheers.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: jake1981 on Jan 15, 2013, 10:47 am
Sounds great. How are you going to handle text rendering? I guess you are not going for truetype fonts.. Then maybe use utft fonts, just because they already exist and there are couple of fonts already available..
Or are you planning on going with a slimmer design for that too?
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Jan 15, 2013, 06:24 pm
Quote
Sounds great. How are you going to handle text rendering? I guess you are not going for truetype fonts.. Then maybe use utft fonts, just because they already exist and there are couple of fonts already available..


Yes, For now I'm going to take the easiest route for font data, utft and u8glib are my first choice for this. My main focus is getting pixels to the display as fast as possible. I've been thinking about a vector style font which would be my own interpretation of a truetype font just without control point distortion hints, or very limited hints. Even still, having a pixel map decompressed from program memory might possibly be faster.

From observation, vector style fonts may be faster for larger font sizes, as a new line algorithm that is suitable for the display can calculate multiple pixel runs, but will need a transformation to screen space. Whereas pixel maps don't need calculating but may not be able to benefit from runs.

Quote
Or are you planning on going with a slimmer design for that too?


Maybe if suitable, slimmer/smaller isn't really my goal, the design aspects of my library are selected on how well they perform. If a handful of extra bytes will increase performance dramatically, then I'll go for the larger. But don't worry, I have plans for a full config where you can select what parts are small ( code reuse ) and what parts are allowed to trade off size for speed ( specific routines for different drawing functionality).

And on a note for the future,
I also dug out my second display, which turns out to be a HX8347A?? ( TFT_320QVT ). Once the ball is rolling I may look into supporting a few other displays, however this may be an unrealistic move as my library is tailored to the SSD1289. It really seems like a few manufacturers have the monopoly on TFT production like the TV market. Same screens, different firmware/driver.

I'm gonna hit post now as lack of sleep will cause me to keep rambling on for pages. Its nice to see a lot of interest, I'm keen to see what creations people will cook up.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pdwyer on Jan 20, 2013, 08:04 pm
I'm learning the DUE and I have just obtained a SainSmart 3.2" 320x240 TFT (with the SSD1289 driver).  Have you (or anyone) done anything with porting/testing your graphics library to the DUE from the Mega 2560?  I would guess that your code should work with a DUE without too much change.  Any code that I could download and get started with?  Thanks!

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: SirNickity on Jan 23, 2013, 02:37 am
Similar note -- is this Arduino (library) specific, or would it work in GNU AVR world too?  I've put some graphic-LCD projects on the back burner because performance has always been a bit of a hindrance.  Tenfold improvements are a cool drink of water sir.

Well, well done.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Jan 27, 2013, 12:18 am
really waiting to get handle and to test that !  8)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Jan 31, 2013, 04:19 pm
Hi all,
I'm also eager to see the version of pYro_65.

In the meantime, here is a simple method for optimizing (a little bit) the current version: First download the latest version from the site "henningkarlsen" which dates from January 2013 and contains some optimizations,
then remove all the tests on display_transfer_mode especially in methods such as LCD_Writ_Bus or LCD_Write_COM.
For example, my LCD_Writ_Bus method :

void UTFT::LCD_Writ_Bus(char VH,char VL)
{   
  PORTA = VH;
  PORTC = VL;
  pulse_low(P_WR, B_WR);
}

With this modification, some methods are twice as fast : drawpixel (100µs instead of 200µs), print, DrawBitmap, DrawLine, etc.
Of course my TFT version only works with screen SSD1289 but no problem since it is the only one I have.
This is far from what announces pYro_65 but in the meantime it helps.

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Jan 31, 2013, 05:01 pm
hi mael,

already done on my side to clean all the unnecessary code in UTFT  :D

but still far of what this post promise .
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: blackmaster on Feb 08, 2013, 05:47 am
news?
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: blackmaster on Feb 14, 2013, 04:51 am

news?


Some news ????

I'm waiting for this "Library Mod" !!  8)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Rivinoo on Feb 28, 2013, 05:15 pm
dead
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: guix on Mar 11, 2013, 04:03 am
pYro, you gave up, or.. ? ^_^
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 26, 2013, 06:00 pm

hi mael,

already done on my side to clean all the unnecessary code in UTFT  :D

but still far of what this post promise .

Hi Vincent13,
I coded a workbench to compare my optimizations with the original version.
Here are my results :
Code: [Select]

start...
Initial version time - optimized version time - opération
724576 us     - 37248 us   : clrScr
200 us        - 24 us      : DrawPixel
2020 us       - 232 us     : DrawPixel x 10
4 us          - 4          : SetColor
4 us          - 4          : SetBackColor
19856 us      - 5804 us    : FillRoundRect 40x40
2652 us       - 636 us     : DrawRoundRect 40x40
4928 us       - 916 us     : drawLine 40x40
604 us        - 152 us     : draw Vertical Line 40
612 us        - 144 us     : draw Horizontal Line 40
27836 us      - 1480 us    : FillRect 40x40
8 us          - 8          : SetSmallFont
7764 us       - 2300 us    : Print 001
7640 us       - 2300 us    : Print Abc
7892 us       - 2580 us    : printNumI(123)
8 us          - 8          : SetBigFont
14912 us      - 4332 us    : Print 001
15048 us      - 4424 us    : printNumI(123)
11668 us      - 2412 us    : draw bitmap 32x32

Do you have better results ? (do you want my WorkBench sketch ?)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: robtillaart on Mar 26, 2013, 06:38 pm
Quite impressive numbers here!   Well done!
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Mar 26, 2013, 06:40 pm
yep why not compare ;)

give me access to your bench code using mp  :smiley-sweat:
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: guix on Mar 27, 2013, 06:22 am
Mael hello, can you share your optimised library please? ^_^
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 27, 2013, 11:38 am
This is my bench sketch :

Code: [Select]

//Bench.ino
//Maël - 01/03/2013
//Mesure le temps de différentes methodes des lib UTFT et UTouch et envoi les temps sur le port Serie (115200 bauds)

#include <UTFT.h>
#include <UTouch.h>

#include "icon.h"

// Declare which fonts we will be using
extern uint8_t SmallFont[];
extern uint8_t BigFont[];
extern uint8_t SevenSegNumFont[];

// Tft, touchscreen for Arduino Mega
UTFT myGLCD(ITDB32S,38,39,40,41);  
UTouch myTouch(6,5,4,3,2);

extern unsigned int icon[0x400];

//pointeur de fonction simple
typedef void TFunction(void);

typedef struct  
{
 TFunction * process; //pointeur sur la methode à chronometrer
 String text;         //nom du test (apparaitra sur la console)
} TProcessInfo;

void InitTFT()
{
// Setup the LCD, touch screen
 myGLCD.InitLCD(LANDSCAPE);
 myTouch.InitTouch(LANDSCAPE);
 myTouch.setPrecision(PREC_LOW); //PREC_MEDIUM
 
 myGLCD.clrScr();
}

void MeasureDrawPixel(void)
{
 myGLCD.drawPixel(0,0);
}

void MeasureDraw10Pixels(void)
{
 for (int i = 0; i < 10; i++)
   myGLCD.drawPixel(i,i);
}

void MeasureSetColor()
{
 myGLCD.setColor(255, 255, 255);
}

void MeasureSetBackColor()
{
 myGLCD.setBackColor(64, 64, 64);
}

void MeasureFillRoundRect()
{
 myGLCD.fillRoundRect(10, 10, 50, 50);
}

void MeasureDrawRoundRect()
{
 myGLCD.drawRoundRect(110, 10, 150, 50);
}

void MeasureDrawLine()
{
 myGLCD.drawLine(210, 10, 250, 50);
}

void MeasureDrawVLine()
{
 myGLCD.drawLine(270, 10, 270, 50);
}

void MeasureDrawHLine()
{
 myGLCD.drawLine(230, 20, 270, 20);
}

void MeasureFillRect()
{
 myGLCD.fillRect(100, 100, 50, 150);
}

void MeasureSetSmallFont()
{
 myGLCD.setFont(SmallFont);
}

void MeasurePrintText()
{
 myGLCD.print("001", 1, 1);    
}

void MeasurePrintTextAbc()
{
 myGLCD.print("Abc", 1, 1);    
}

void MeasureSetBigFont()
{
 myGLCD.setFont(BigFont);
}

void MeasureclrScr()
{
 myGLCD.clrScr();
}

void MeasureBitmap()
{
myGLCD.drawBitmap (200, 10, 32, 32, icon);
}

void MeasurePrintNum()
{
 int num = 123;
 myGLCD.printNumI(num, 200, 100);
}

void MeasureTouch_dataAvailable()
{
 boolean b = myTouch.dataAvailable();
}

void MeasureTouch_read()
{
 myTouch.read();
}

void MeasureTouch_getxy()
{
 int x=myTouch.getX();
 int y=myTouch.getY();
}

//Liste des méthodes à mesurer
#define LIST_COUNT 22
TProcessInfo ListOfMeasures[LIST_COUNT] = {
 { MeasureclrScr, "clrScr" },
 { MeasureDrawPixel, "DrawPixel" },
 { MeasureDraw10Pixels, "DrawPixel x 10" },
 { MeasureSetColor, "SetColor" },
 { MeasureSetBackColor, "SetBackColor" },
 { MeasureFillRoundRect, "FillRoundRect 40x40" },
 { MeasureDrawRoundRect, "DrawRoundRect 40x40" },
 { MeasureDrawLine, "drawLine 40x40" },
 { MeasureDrawVLine, "draw Vertical Line 40" },
 { MeasureDrawHLine, "draw Horizontal Line 40" },
 { MeasureFillRect, "FillRect 40x40" },
 { MeasureSetSmallFont, "SetSmallFont" },
 { MeasurePrintText, "Print 001" },
 { MeasurePrintTextAbc, "Print Abc" },
 { MeasurePrintNum, "printNumI(123)" },
 { MeasureSetBigFont, "SetBigFont" },
 { MeasurePrintText, "Print 001" },
 { MeasurePrintNum, "printNumI(123)" },
 { MeasureBitmap, "draw bitmap 32x32" },
 //Mesure des optimisations sur UTouch (en debogage)
 { MeasureTouch_dataAvailable, "Touch Screen DataAvailable"},
 { MeasureTouch_read, "Touch Screen Read"},
 { MeasureTouch_getxy, "Touch Screen getX, getY"}
 };

void Measure()
{
 Serial.println("start...");
 unsigned long ChronoAll = micros();
 for (int i = 0; i < LIST_COUNT; i++)
 {
   if ( ListOfMeasures[i].process != NULL)
   {
     unsigned long ChronoOne = micros();
     ListOfMeasures[i].process();
     ChronoOne = micros() - ChronoOne;
     Serial.print(ChronoOne, DEC);
     Serial.print(" us : ");
     Serial.println(ListOfMeasures[i].text);
   }
 }
 ChronoAll = micros() - ChronoAll;
 Serial.print("finish in ");
 Serial.print(ChronoAll, DEC);
 Serial.println(" us.");
}

void setup()
{
 Serial.begin(115200);
 Serial.println("ready.");
 InitTFT();
 
 Measure();
}

void loop()
{
}


Maël.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 27, 2013, 11:42 am
this is Icon.h

And I'm preparing a zip archive of my UTFT version.
Maël.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 27, 2013, 03:11 pm
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 :

Code: [Select]

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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Mar 27, 2013, 07:06 pm
Hi meal,

french too ;)
To run successfully, I need icon.h also ;)



Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Mar 27, 2013, 07:20 pm
your the best Mael,

t'es le meilleur ;)

ready.
start...
531340 us : clrScr
96 us : DrawPixel
884 us : DrawPixel x 10
4 us : SetColor
4 us : SetBackColor
8388 us : FillRoundRect 40x40
1128 us : DrawRoundRect 40x40
2776 us : drawLine 40x40
256 us : draw Vertical Line 40
256 us : draw Horizontal Line 40
11524 us : FillRect 40x40
8 us : SetSmallFont
4772 us : Print 001
4648 us : Print Abc
4900 us : printNumI(123)
8 us : SetBigFont
9592 us : Print 001
9724 us : printNumI(123)
6416 us : draw bitmap 32x32
28 us : Touch Screen DataAvailable
960 us : Touch Screen Read
116 us : Touch Screen getX, getY
finish in 611364 us
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Mar 27, 2013, 09:24 pm
original lib scores :

ready.
start...
114588 us : clrScr
212 us : DrawPixel
2064 us : DrawPixel x 10
12 us : SetColor
8 us : SetBackColor
14408 us : FillRoundRect 40x40
2240 us : DrawRoundRect 40x40
4160 us : drawLine 40x40
468 us : draw Vertical Line 40
464 us : draw Horizontal Line 40
4364 us : FillRect 40x40
8 us : SetSmallFont
7396 us : Print 001
7212 us : Print Abc
7464 us : printNumI(123)
8 us : SetBigFont
13552 us : Print 001
13676 us : printNumI(123)
12040 us : draw bitmap 32x32
20 us : Touch Screen DataAvailable
968 us : Touch Screen Read
120 us : Touch Screen getX, getY
finish in 218352 us.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 28, 2013, 10:27 am
Salut Vincent,
Les forums internationaux sont souvent plus intéressant et riches, en plus ils nous font bosser notre anglais ;)

I've the same result than you before I replace macros. Now I can't optimize more.
pYro_65 certainly has the best results.
pYro_65, what do you think about these times ? have you try the bench ? Are you here ? :)
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Rivinoo on Mar 28, 2013, 10:39 am
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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 28, 2013, 11:27 am
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 :
Code: [Select]

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

by it :
Code: [Select]

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

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Rivinoo on Mar 28, 2013, 12:05 pm
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:[table border=1]
Original UTFT:  Mael modification:
21218 us13207 us


Thank you!
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Mael on Mar 28, 2013, 04:02 pm
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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: MichaelMeissner on Mar 28, 2013, 05:15 pm

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:

Code: [Select]

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


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

Code: [Select]

__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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: vincent13 on Mar 28, 2013, 06:58 pm
we are looking for pyro  :smiley-sleep:
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: cyclegadget on Mar 30, 2013, 03:37 am

It is nice to see all the work being put to this screen! Thanks!
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: kyildirim on Jun 07, 2013, 08:56 am
hi there pYro_65,
are you following this topic, do you plan to share your results as you wrote?
regards,
K
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: loctite on Jan 25, 2014, 08:01 pm
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
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Hernexto on Mar 09, 2014, 06:19 pm
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...
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: pYro_65 on Mar 10, 2014, 06:29 am
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.

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Deltoz on Mar 23, 2014, 12:04 am

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 :

Code: [Select]

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  :*
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Hernexto on Mar 29, 2014, 02:43 am
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 :)

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

Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: robtillaart on Mar 29, 2014, 10:00 am

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

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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: MichaelMeissner on Mar 29, 2014, 10:10 pm
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).
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: robtillaart on Mar 30, 2014, 11:48 am
agree, but imho part of the Arduino fun is to get "most" speed from a "slow" processor
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: hampf on May 14, 2014, 07:56 pm
@Hernexto: Are you sure that you used the right init for the TFT?

I had to replace
Code: [Select]
UTFT myGLCD(0);
with
Code: [Select]
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:

Code: [Select]
#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
Code: [Select]
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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: Duiker on Oct 10, 2014, 07:04 pm
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.
Title: Re: High speed vector graphics engine. 3.2" TFT Lcd screen.
Post by: rolfdegen on Nov 06, 2015, 11:41 am
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 https://www.youtube.com/watch?v=T4p6Wr_8Pcc

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

New video without disturbance:
https://www.youtube.com/watch?v=VXPNqAjtjhM&feature=youtu.be

Old video with disturbance:
https://www.youtube.com/watch?v=gpzXowpXnCU#t=37

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