Consolidation of all LLD and interface logic

[Abhishek]

With three different QVGA and bigger LCD controllers for ChibiOS/GFX (as of now - S6D1121, SSD1963 and SSD1289) and two interfaces for each LCD - GPIO and FSMC, it has become hard to maintain uniformity across all three LLDs, and also the system is turning out to be inflexible for custom hardware, whose settings do not match the ones that have been followed.

It certainly follows that the LLD abstraction has to be reworked. Badger has been pushing this idea some time ago, and I decided to give it a shot.

Basically, my plan is to abstract the 8080-style interface that each of them follows, and move the interface logic into a separate interface_aaa_bbb.c file [aaa: interface, bbb: platform e.g. STM32 - F1, F2 & F4, and so on], which will be linked accordingly with the LLD at compile time. Or maybe included and compiled into the LLD file itself. Each interface has a separate file i.e. FSMC, 8-bit GPIO and 16-bit GPIO logic would be separate files. No interblending and defines, since it gets very troublesome.

We would provide sample interface files, but in the end, it will be the responsibility of the end user to either copy-paste one of the sample files into his own interface.c, without having to touch the library sources.

A sample interface.c I created is here: https://gist.github.com/aa6a7c45a94143762277

So here I start the discussion. Feel free to propose changes or conceptual modifications. It has to be done in the right manner so that we can support many more drivers and be customizable as well.

Best Regards
Abhishek

[Tectu]

I guess I don't have to say that I'd really like to see an interface in ChibiOS/GFX which allows the user to use the library without creating a forum thread to tell us that it dosen't work
I didn't think of how it should be done deeply yet. There is a lot of work I have to do in the background. But of course - as always - I'd welcome any kind of contribution.
The example you posted dosen't look that bad for a first "try". The only thing that I'd like to mention at this point is that I'd really like to go with gdisp instead of lcd. Also, maybe there is some ChibiOS/RT naming convention which we could borrow. I already adjusted the prototype names of the gdisp GPIO and touchpad calibration storage interface to meet the ChibiOS/RT standards.

Also, there's another thing which might be good to keep in mind at this point: There are certain (mostly industrial) LCD modules out there, which do not only have a simple display controller on it. For example, badger has a module, where the touchpad data gets send over the FSMC as well, while I have one here, which dosen't have any touchpad controller at all where you have to read out the resistance of the touchpad yourself. Therefore, it might be useful to not only create drivers, but also modules. ChibiOS/RT does it a very similar way: There are files which "describe" the MUC (for us the driver) and there are files which describe an entire board (for us a module).


~ Tectu

[E-B Felix]

Good idea

but we should add also think about the SPI interface.
I would like to port my driver for the Watterot MIO283QT to ChibiOS/GFX. As a controller the MIO283QT use a HX8347D and ADS7846.

The SPI driver could use the same interface, but initialization would be different since we have to pass the information about the SPI interface towards the driver (similar as for the TP driver).

Code: Select all

   gdispInit(&LCDSPI);
   tpInit(&TOUCHPADD1);


Or we use a setup function the pass the SPI interface to gdisp.

I am just start working with ChibiOS/GFX therfore my knowledge on the concepts/interfaces is not so high.

Regards
Felix

[Tectu]

Using SPI to interface an LCD is possible without any problems. There are already the macros for that in some drivers (like SSD1289).
I guess it's really the best idea to go back to a config struct which will be passed to gdispInit() like it was in an early state of the library. This would give a very flexible but yet understandable way of configuration.

But of course this topic here and Abhishek's suggestion is LLD related - nothing that the user of the library should care of.


~ Tectu

[Abhishek]

Since it is highly unlikely that the interface of the LCD is to be changed at compile time, the fixing of the interface shall be done at compile time only. However configuration of the LCD is to be left to the user, i.e. the user has to alter the defines in his own interface.c file.

We will come up with a structure soon.

Abhishek

[Badger]

I don't think the SPI interface will need consolidation as there are already chibios SPI drivers that do the abstraction.

Really this topic is about abstraction of an 8080 parallel interface to work with GPIO, FSMC etc. It will need to support 8/16bit data bus, changing of polarity for RS, specification of RS for FSMC and all pins for GPIO

[inmarket]

It has been solved by extending the board level interface used in the Nokia6610 driver to the other display drivers.

[Tectu]

That's correct!

related:

• http://chibios-gfx.com/blog/140-introduction-of-the-new-gdisp-driver-interface
• http://chibios-gfx.com/write-driver
• http://chibios-gfx.com/documentation/gdisp/interface

~Tectu