GDISP driver

[inmarket]

The new GDISP driver is an architecture independant rewrite of the GLCD interface. This new architecture independance should allow many new low level drivers to be easily added and has many new features.

It may be found at https://github.com/Tectu/ChibiOS-LCD-Driver under the halext directory.

A glcd.h compatability file has been included that allow applications written to use the existing GLCD driver to use the GDISP driver with little or no change.

Major changes:

• It fixes architecture things like big-endian and word alignment issues in the font code.
• Support for many different pixel formats in an easily extendable manner.
• Allows low-level driver hardware accelerated drawing routines while providing a software emulation if the low level driver can not provide it.
• A basic low level driver now only requires 2 routines to be written (init and setpixel).
• Allows a low level driver to choose between different software emulation algorithms.
• It is written in the ChibiOS style with ChibiOS style includes and documentation.
• Types are abstracted so that you can do things like change the definition of a font column from uint16 to uint32 to allow supersized characters. Existing font tables will work seamlessly without code alteration if the type is changed. (This is also partly how multiple pixel formats has been implemented).
• Sections of functionality can be turned off with a resultant reduction in code size and/or improvement in performance. Eg. Don't need text or multi-thread support then turn them off.
• It is encapsulated into a "halext" structure with appropriate readme's that allow for easy inclusion in any ChibiOS project. This structure can be seamlessly added to as new driver types (non GDISP) are added. It also supports low level drivers that are neither platform or board specific (although they can be).

ToDo (not necessarily in order):

• Backport existing low level drivers
• Complete code for multi-thread support
• Complete code for packed pixel formats
• Write new low level driver for my own display
• Port things like console to the new format

[Tectu]

Okay, this sounds very very awesome. Thank you very much for your great work.

I couldn't check every single point yet, but here's a queston:

A basic low level driver now only requires 2 routines to be written (init and setpixel).

We also need to be able to read back from the LCD. This feature is already used, for example in the console stuff. But I guess it is easy to add?


~ Tectu

[Badger]

Thanks for your work, I am testing now.

We also need to be able to read back from the LCD. This feature is already used, for example in the console stuff. But I guess it is easy to add?

we could have some macros that only enable those features if the lld supports it. Being able to turn off features for basic lcds could be very useful.

[inmarket]

The low level driver does support adding a pixel read-back.

It is already one of the predefined but optional low level driver routines. It needs to be optional as not all displays support pixel read-back.

If your application (or console) code requires pixel read-back you can set GDISP_NEED_PIXELREAD to TRUE and you will get a compiler #error if the low level driver does not provide one. There is a similar macro for hardware scrolling.

These two are the only two functions that can't be software emulated if the low level driver doesn't support it.

Have a look at gdisp.h for a list of GDISP_NEED_XXX macros that tell the code your application needs support for a particular function.
Have a look at gdisp_lld_config.h for a list of GDISP_HARDWARE_XXX that tells the system what hardware support is provided by the low level driver.

To create a new low level driver:

• Take a copy of the code in the templates directory and put it into a drivers/yourdevice directory.
• Modify your new gdisp_lld.mk to point to your new directory
• Modify gdisp_lld_config.h to specify what hardware support your driver provides
• Modify gdisp_lld.c with your driver implementation
• Read the halext readme on how to add it to your project.

The only mandatory routines for a low level driver are init and setpixel. This snables a new driver to be written very quickly.
Once your display is working it is a good idea to also add fillarea and blitarea for performance reasons (if your hardware supports it).

Read-pixel and hardware scrolling would complete the picture.

[Tectu]

This sounds good. I will definitly port the SSD1289 driver.

But how is it going with the different interfaces, GPIO, FSMC and SPI now? Will we create a new driver file for each interface type?


~ Tectu

[Giovanni]

Interfaces could be configured in the low level driver. It is something highly specific of the controller.

Giovanni

[Abhishek]

Whoa inmarket! Awesome!

If you're interested, i've a working lib for the nokia 6610 / 6100 LCD for the STM32, using hard SPI and 1 soft bit. Would you like to have it?

However, how did you restructure the text rendering code? Did you write some sort of script?

I guess your code requires a new repo.

Best Regards
Abhishek

[Tectu]

I guess your code requires a new repo.

How do you come to that idea?! This code definitly belongs to the entire GLCD project. I will port the SSD1299 and badger will do the S6D1121 to the "new driver interface". After that, we won't have any other choices than using this awesomeness.


~ Tectu

[Abhishek]

I said that because of the magnitude of changes, or say, complete rewrite of the lib, it didn't belong with the old code.

Anyways, no offence intended. Once you're done, I'll do the S6D1121 GPIO part.

[Tectu]

If you find time to port the S6D1121 driver, this would be nice. I guess Badger can only check the FSMC stuff. Therefore you could verify that the GPIO stuff is working as well. I guess I have to ask Badger if he can check the FSMC for SSD1289 as well.


~ Tectu