Graphics Library?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

I was wondering if ATMEL had a graphics library, that I can use with one of my micro controllers (2561, 2560) and talk to various size TFT displays (1.8, 2.2, 2.8, etc.)
So far I found AVR481/2/3 which has some information about a graphics library, but I see support for one driver. I'll keep searching, but I figured why not ask the experts. :)

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First pick and identify the graphic LCD you are talking about. Is it KS0108 or something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The different TFT's have different drivers:

1.8 = S6D0144 driver = NewHavenDisplay's NHD-1.8-128160YF-CTXI display

2.2 = S6D0139 driver = DisplayTech's SDT022TFT display

2.8 = SPFD5408 driver = Microtips MTF-TQ28NN741 display.

For now I would love to get the 1.8 LCD to display pictures and text.

Edit:
I wasn't able to find any TFT's without drivers that are smaller than 3.5 in.

TY for the rapid response.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a difference between a driver (on the panel) and a controller. I don't use any of those displays, but the typical TFT display looks more like a CRT display than not.

The average display needs digital data, and then drive pulses equivalent to horizontal and vertical sync (and a dot clock).

Display controllers (hardware) provide the master timing signals, writing to (perhaps onboard) memory, and a CPU interface. Epson makes a series of chips that do this, as do others.

Software wise, you would have a series of definitions used by your program to tell the software what pins are connected to what. You'd also need a hardware driver program that provides read and write to the controller chip, initialization, and a few other things that implement whatever built in hardware functions the chip has (set dot, clear dot, etc).

Above that, you'd need the graphics library which has code that is hardware ignorant, it doesn't know how the hardware is connected, but does know the size of the display. It calls the hardware driver routines to make the display chip do things, which then affects the picture.

The drivers you have listed sound like the row and column drivers on the display. All they do is make the pixels light up when the right signals are connected. They are not programmable. They're more like the sweep circuits in a computer monitor.

Apologies if you already knew this.

Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The drivers you have listed sound like the row and column drivers on the display.

Are you sure about that? I only looked at the PDF for S6D0144 but it talked about ~300,000 bits of "graphics RAM" and seemed to offer functions to address/write that - to me that's an intelligent controller rather than a simplistic row/column driver. In fact it's usually the onboard presence of "display RAM" that sets apart the raw panels from the intelligent ones. If there's RAM then you can pretty much rely on the fact that panel refresh timing will be done by an onboard timing generator. If it isn't then on an AVR8 you are in deep weeds as it's quite an overhead to have the AVR do it (just like VGA generation in fact - doable but not much time for anything else)

As these small displays come from mobile phones where the main CPU wants to hand-off the boring work of display refresh I'm guessing they are all intelligent controllers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies guys, I also agree with Clawson on the fact that they carry ram and have initialization routines, timings, etc. etc. What I wanted to know is if Atmel had a graphic library that can handle that driver. Just as you metioned Harvey, the graphics library im in search for should have routines for dealing with this driver (writing text, drawing boxes, etc.)

Again, thanks for the help so far. I'll keep searching in the mean time.

I can't seem to find anything from atmel that can handle it, so I'm going to look for a third party graphics library.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's unlikely that Atmel themselves would have drivers for hardware they do not make a profit from but the chances are that someone, somewhere in Internet land *has* attached one of these to some form of micro (more than likely a PIC in fact) so your best bet would be to search that out and as long as it's written in C not Asm then it should be fairly easy to adapt to AVR use. (that might be possible with Asm routines as well but clearly it'd be more work)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've spent quite a bit of time writing one. I'd love for you to let our little company bid on doing some hw/sw work for you. Send an email.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bootloadernoob wrote:
I can't seem to find anything from atmel that can handle it, so I'm going to look for a third party graphics library.

I've been looking for some GUI-library in the past as well, and then I ran across theese guys: http://www.ramtex.dk/products/prodgui.htm
(we're not in any way affiliated with them). However, I never got around to actually test it so don't know how it performs in real world, but on paper their specs and design actually look pretty good.

Very good hardware support too, almost all the "usual suspects" controller-wise seems to be listed. Seems to be reasonably priced & licensing arrangements as well.

As said, I don't actually know how they'd perform but compared to wing your own GUI-lib from scratch it certainly seems like a good start. If you do use them, or find someone else even better, I'd certainly be interested if you'd let us know.

As far at Atmel goes, have you looked at the "DB101" application board? http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=4221
While it's certainly not using your particular controllers, there is at least a high-level GUI-framework implemented (e.g. pop-up "windows", text-writing routines, scroll-bars and menu system etc). Would still be some (alot?) work to tailor it to your needs but perhaps easier than starting from absolute scratch.

Edit: Sorry I read now that you already found the DB101 appnotes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks letcat, ramtex has everyone! but they don't have support for my smaller LCD.

I also found out that microchip has a free graphics library, theres also http://www.micrium.com/products/...
and
http://www.segger.com/emwingsc_d...

None still don't support the S6D0144 driver, I wonder if it is just too small.

I'll keep searching and i'll post my findings in case anyone else needs the information.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I rolled my own graphics library, so that's another matter.

Since the displays have RAM and a controller on them, you might just start with the drivers for the display chip. Not familiar with the S6D0144, but am familiar with the T6963 and the S1D13706 epson chip. Note: just looked up the S6D0144.

With a properly written set of drivers, you can just swap display drivers and keep the higher level graphics routines intact. Things like "set color" and such for a color display just return "true" if you want.
You want at a minimum set and reset dot, so depending on how the atmel notes are written, you may be able to just do that easily.

The higher level graphics routines have the line draw, square, etc. Triangle and higher sided geometric figures are all in the "draw polygon" routine. Give it a radius, center, and number of sides and you're set. (circles are approximated). You can add radii to the figure and plot M of N sides, you can also rotate the beginning part of the figure. All that's in the high level routines.

As long as the graphics library is in C, you're fine. You might also want to see what the maker of your graphics chip has to say. They often have a graphics library included or available.

Splitting up the functions into hardware and hardware agnostic may even allow a pic libary to be useful.

Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply,

I am currently trying to change up the pic library so that it can use the graphics library. As for new haven they have sample code on using it, but no actual graphics library. Looks like it's something I may have to write on my own.

If you have any more suggestions please let me know.

Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd look at what functions "commercial" graphics libraries have, and decide if they're useful.

I'd definitely split everything up into hardware driver and hardware agnostic. Your programs never call the hardware driver ever. The hardware agnostic section calls the harware driver only. Keep the names for the hardware driver section constant between different chips (when needed) and you should be well off. YMMV, of course.

Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote driver fo S1D19105, you can find sources here: http://idom.svn.sourceforge.net/ in directory LCDGUI, files LCDDriver.h and LCDDriver.c.
It's very simple to write your own driver for SxDxxx controlers as they are very simple framebuffers without any advanced logic. My driver only provides methods for setting point, drawing lines or rectangles, but in other files you can find more functions – font rendering procedures and so on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the late reply. I will check that out TFrancuz. Ty for posting it.