next topic »

[on:]

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.



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

[Reply #1 on:]

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

[Reply #2 on:]

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.

[Reply #3 on:]

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

[Reply #4 on:]

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?

[Reply #5 on:]

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, 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 chip.

I managed to take screen shots by using the information found in this thread 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.

 

[Reply #6 on:]

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.

[Reply #7 on:]

Want!

[Reply #8 on:]

I have a copy my app in progress ready for a view if anyone is interested.

This is the hardware I'm using:

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:

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:

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'

[Reply #9 on:]

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

[Reply #10 on:]

Great! Could you please release sources?

[Reply #11 on:]

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.

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 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...

[Reply #12 on:]

I use the same screen in my project so I'm watching with interest!

[Reply #13 on:]

I can't wait to see the sources.

[Reply #14 on:]

Great results. Anxious here too..