GLCD and Touchpad Library

[Abhishek]

Hi inmarket,

Thanks once again for your suggestions!

I'll be getting back on this shortly. With my comments. Maybe by editing this one or making another post.

[Abhishek]

OK, so here are my comments. It took me so long to write.

Include the low level driver header using a generic name near the top of the high level header file. This is similiar to the other CibiOS drivers. The make system determines which low level driver & header is actually included.

A very valid Point, we'll consider it in the next LLD revision. I'll talk about it in a new topic.

Define a few macros that handle the PIXEL types and format conversions...

I've used the Nokia 6610 LCD and I know about RGB444P and RGB332=8bpp. I guess we'll define a color_t datatype, and replace it everywhere we have uint16_t. The LLD will define the alias for color_t, RGB332 would use uint8_t, RGB444P and RGB565 would be using uint16_t, and a macro RGB(r,g,b) accordingly to convert from RGB888 to the particular BPP instead of hardcoding. Then the LCDs we're using also support an 18-bit mode - RGB666. This, along with RGB888 (24-bit format) will expand color_t to uint32_t.

Then all standard colors can be mapped using a RGB Macro e.g. RED => RGB(255, 0, 0) , and so on. It'll be considered in the LLD revision I talked about.

Define a bunch of GLCD_NEED_XXX macros ...

If I'm not using a worker thread, only those functions will be linked which are being used. The ChibiOS makefile has option of -function sections and data sections per function and variable. This way the linker can clean up dead code. Similarly for the fonts. If you're not using some font in code, you'll be sure that it'll not be linked into the final file [try it out and see].

However, in case you're using a worker, this will fail. So in that case, we may use switches. [However, considering that in the current state a lcd set pixel takes, say, 1us, and messaging will lead to two context switches, increasing the time to 3us (Context Switch in ChibiOS is around ~1us @ 72MHz)]. So I think concept of workers might not be useful at the lowest level for simple applications. Badger has said, he'll implement it. So issue is somewhat sorted.

For graphics algorithms, as of now, I don't know exactly which algorithm are we using for circle, ellipse, and lines. But it could be useful at a later stage, if not now. I would leave it as it is for now.

About character LCDs, I don't know why you would like to use them with an ARM processor, when you can easily use a color LCD. Secondly, the data accesses to those LCDs will involve blocking the processor for several microseconds or even milliseconds for the write to complete, which is considerable amount of clock cycles for ARM processors, which will be going waste [of course an RTOS may help in this case, but still, will require some effort in driver design, maybe something like a queue]. So I don't think they'll be supported. Dot matrix graphics displays might be supported, but at a very very late stage.

However even at some point I raised a point of separating the text rendering functions from the main lib. We'll see. Also, agreed to the proposal of making the setWindow LLD.

To be very frank, when I (or Tectu) started working this lib, our aim was just to write a lib for our particular LCDs which we use. Then Tectu thought it might be a better idea to create a shared codebase so that anybody wanting to use those LCDs (they're pretty popular on eBay) wouldn't have to reinvent the wheel when they get themselves one. So came the low-level drivers for SSD1289, S6D1121, (SSD1963 is under development, @mobyfab: what's the status? ). And gradually we'll genericise the whole thing for different LCDs and resolutions, it's a kind of top-down approach as compared to a bottom-up approach [so that the lib is usable even at this stage, but can get much better], so we're always looking for ideas or suggestions to improve this lib and make it more generic and universal.

So I think that's all I can say right now, the coding will follow hereafter. If anyone [Badger, Tectu, Giovanni, and others on this forum] would like to point out/differ in opinion in something in this, most welcome.

Best Regards
Abhishek

[inmarket]

Fantastic feedback. Thanks. I'm a happy little beaver now - coding away. I'll upload as soon as I have something useful.

[mobyfab]

Working on it, currently playing with the FSMC timings but it looks pretty good.

[Abhishek]

Nice to know that, mobyfab

BTW, I just studied on the net about scalable fonts, with our current approach, unfortunately, it looks like it will be more difficult to implement.

However, as a workaround, I can generate a table for each font and size separately, say, 8px, 10px, ... You may include fonts you like, and the code size will change dynamically as you use/not use the fonts as I mentioned earlier. Maximum size of each character = 16px only (not pt, as we generally use).

And AA (anti aliasing,smooth) Line drawing looks interesting, will give it a try and post soon.

[mobyfab]

okay, it looks ugly but I got something on the screen

fixing it should not take too long

edit: it's working, LCD is initialised but the controller crashes instantly...
I had the same issue last time with GPIO.

[Tectu]

Of course we can make different font tables, but it would be lovely to have fonts bigger than 16px many many times!
I know that there are limitations because of uint32_t, but of course it is possible to implement somehow. We/you would just have to bring up a fancy, smart, small and fast solution


~ Tectu

[inmarket]

Just did pull request for restructured code.

As the changes are major the restructured version is in a different 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.

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. No low level drivers yet exist except for a stub one. I'll start porting the existing low level drivers over the next few days although I'll need someone else to test them as I do not have a ST32 board.

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]

This is very impressive work. Thank you very much!

I couldn't take a closer look yet, but I will do that over the next 24 hours. But from what I have seen so far, it looks very very good.
I would be very happy and thankful, when you could edit/recreate the wikipages matching the new code here: http://www.chibios.org/dokuwiki/doku.ph ... :community


~ Tectu

[inmarket]

How do I create a login so I can update the wiki? It appears the forum login is does not work.