I had a look at several TFT libraries and noticed almost all (including mine) combine graphic primitives with low-level I/O. When i created my library, i considered using Hennig Karlsen's UTFT library, but i abandoned the idea (at that time, i was still learning alot about C++). I knew another user already ported Hennig's library but it still was under development (i should have joined this instead of starting from scratch...). This is i a great library but, still, it combines graphic primitives and low-level code.

Even though it's great to have different higher level implementations, i think we should strive to keep it separate from low-level code.
Perhaps the Adafruit_GFX_MBED library is the way to go. Adding ellips/fillelipse functions to this lib would be great (did this in my lib - i searched for a decent/fast ellipse/circle lib that does a real fill).

Anyone has other/better ideas?

Edit : Besides, this is not the first time this topic emerged - see this one also (more than a year ago!!! - i should have posted there).

Most of the TFT libraries use the TextDisplay and GraphicsDisplay parent classes. If instead of everyone altering them slightly and adding their own version, there would be a single repository for these, I think it would be a good start.

The low level methods like writePixel and writeBlock should be separated. Derived classes can then implement these methods differently. Many high level methods such as drawing a horizontal line or filling a rectangle will be very slow when you use methods that write individual pixels by calling separate commands and datawrites. In these cases optimised blockwrite methods can help a lot. These should also be added to the low level lib by overriding the highlevel primitives. Unfortunately the optimised methods depend on the controller. Different controllers will also typically required some different initialisation. It is easier when you develop the lib for one family of controllers (eg ILxxxx) but still you will have to find a solution. The controllers will typically need writeCommand() and writeData() methods which may be implemented differently eg parallel or SPI.

The family tree could be: TextDisplay & GraphicsDisplay interface -> High level primitives (pixel, line, block etc) -> controller family (or type) providing init methods and optimised primitives implementation -> Parallel & SPI (writeCommand etc)

You should probably implement Parallel & SPI (writeCommand etc) as subclasses of a Controller base class because sometimes they are quite different between controllers. I have seen TextLCD controllers that use either 9, 10 or 24 bit SPI messages and either LSB first or MSB first.

I would assume that only the different draw/text commands would be shared (so circle, line, square, etc). If each specific controller overrides this or uses its own option will differ. But I don't think it is possible or a good idea to try to use shared code for the window-functions at least some controllers have.

I put the ILI9320 library rewrite on hold until we can get this sorted out a little more.

Erik has a point about TextDisplay and GraphicsDisplay, but aren't we starting all over again what has already been done?
I took a closer look at Adafruit's ILI9341 test and, unless i missed something, i believe most (if not all) of the proposed changes are in place. For instance, the low-level subclass can override drawLine, drawFastVLine, drawFastHLine, drawRect, fillRect, fillScreen and invertDisplay. If necessary, other functions can be added.

I do know it will be a real pain to adapt existing libraries, but in time, this will benefit to all.

At this very moment, the abundance of all doubles/forks is quite confusing (certainly for new users):
Here is a quick check i did on 2 display drivers, more to check at the relevant Components page.

• ILI9341 : Adafruit, Peter Drescher and forked libs - even the forks get forked...
• ILI9320/25/28 : Erik and me and Todor's UTFT port
• ....
  

About those Forks (a little off-topic) :
Even though this is a great feature, several forks should end in a pull request in order to keep the mbed codespace tidy.

Edit (something i forgot to mention) :
Perhaps we also need to consider this for the touchscreen libraries.

I agree on the forks, that issue is also on there on other libraries: If you fork to add something, please make a pull request next.

But what is the advantage of that Adafruit one compares to TextDisplay and GraphicsDisplay, don't they have those same lines? In principle I can imagine having it split in a text and graphics part can be useful.

Erik, you are right (i must have been sleeping). In fact, it's the other way around, Adafruit's lib is built the same way (only with additional functions). Perhaps some of these functions are worth adding.

As Simon Ford created the initial code, i sent him a pm asking him to create the TextDisplay/GraphicsDisplay repository or if he doesn't mind, someone of us can do this.

For starters, we need to add comments (and possibly, additional functions) and send pm's to all those who currently use these files.
I didn't check but i don't think many changes were made to the copies currently in use.

About ILI9341 forked-forked lib, because it has some wrong screen erase bug, I was debugging it but I was not trying to add any function(s). So as far as current function(s) are kept, my programs will be fine. But in sometime the erasing a wrong region bug should be taken care of... I hope...

moto

GraphicsDisplay repository and Team created. Feel free to join.
Please start future questions and discussions at the team and repository pages.

Hi all,

how is goin with this unified GraphicsDisplay? Is there already some beef on the grill on which i could mess a bit around? I'm not good in c++ class stuff, but if there is already some basic structure, maybe i could be in help. I agree with Wim Huiskamp, protocol(spi/par)->displaytype(LCD/TFT)->Graphics(line,circle,character..)->Text

This is what i'm thinking about

• custom or generic display: defines for init sequence, custom cmds for standard stuff, protocol to use, display type and size...
• protocol: lowlevel wr_cmd, wr_data, wr_databuf, rd_data
• display: framebuff for LCD, orientation, pixel, pixels(databuffer), readpixel, cls, locate, window (sw implemented raw/column auto-incr for LCD), scroll...
• graphics: line, circle, character...using pixels(databuffer) to speedup TFT, ex. font and fillrect
• text: as is

I've played with some TFT il9341,9481,9486, RM68042, spi and par16, basically i took Peter ili9241lib then messing around to have 2 libs, one for spi and one for par16, but it comes clear that they olny diff in the wr_cmd() and wr_dat() About different ic, they can be autodetected based on readID, resolution could also be autodetected using pixel and readpixel. Just using few standard cmds the display could work, most of the register values the supplier tells you to init, are not so much different from the ones already programmed in the otp.

Actually i'm playing with monochrome graphic LCD, took Peter c12832 lib and messed around, made it par8 and going to make it adaptable to various driver ic, just need some define about panel size and ic gram size, custom init cmd if any, nothing more.

As Frank mentioned it'd be best to move this conversation here https://developer.mbed.org/teams/GraphicsDisplay/community/ and use the team collaboration to see this come to life!