GDISP driver

[Badger]

I noticed that fontLarger has very narrow spaces (2 pixels I think). Can this be increased? the text looks very squashed together.

[inmarket]

I noticed that fontLarger has very narrow spaces (2 pixels I think). Can this be increased? the text looks very squashed together.

Yes. there is a charPadding field in the font header definition which is the number of pixels between characters. Most fonts have that set to zero currently. Just increase that.

[inmarket]

I used scalable fonts the day they were added. To be very frank, they did work, but the quality wasn't very good. It was as like we were having pixelation in images. Though that was expected.

Yes, these are just scaled fonts - not line drawn. I have found that the Narrow fonts are really nice. Twice the height but the same width as a normal font. These don't give the same pixelated appearance.

Inmarket,what's the status of VMT based low level drivers?

I currently have MULTITHREAD and ASYNC multithread going. I was hoping to have the VMT done last night but I got too tired to complete it. So, very close. I will post the 3 bits of functionality together.

One thing to think about with VMT is that I have changed the Init call to return a bool_t. For VMT, it chooses the driver to use by trying to initialise each display in order. The first to return TRUE is the one that gets used. At present none of the drivers have any hardware detection in them, they just assume that it is there. My first cut will also have the drivers just return TRUE so effectively it will always be the first driver that gets used. As I don't have anything but the Nokia display could those who understand the other two low level drivers have a think about what they need to do to verify the hardware is actually present.

[inmarket]

the quality wasn't very good. It was as like we were having pixelation in images.

For limited cases it may be possible to add anti-aliasing. I think it would require..

• The use of scaled fonts (obviously). No point antialiasing non-scaled fonts.
• Filled characters only (where a background color is specified) as few platforms support pixel readback and those that do would be too slow.
• Full character blitting algorithm (not the fill & draw or the single column blit)

The code would be added to the appropriate spot after the character has been generated but before it is blitted in gdisp_emulation.c and probably turned off and on via a define such as GDISP_NEED_TEXTALIASING.

I leave it as an exercise for the reader.

[Tectu]

Finally I am back from everything and I can keep working on the library daily.

I am still wondering that all of you can compile without any errors. I get this one, which seems to me like it is not depending on the lld driver you use:

Code: Select all

[tectu@mercur lcd]$ make -j5
Compiling main.c
In file included from main.c:3:0:
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:6: error: nested redefinition of 'enum orientation'
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:6: error: redeclaration of 'enum orientation'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:387:14: note: originally defined here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:19: error: redeclaration of enumerator 'portrait'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:387:27: note: previous definition of 'portrait' was here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:29: error: redeclaration of enumerator 'landscape'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:387:37: note: previous definition of 'landscape' was here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:40: error: redeclaration of enumerator 'portraitInv'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:387:48: note: previous definition of 'portraitInv' was here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:41:53: error: redeclaration of enumerator 'landscapeInv'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:387:61: note: previous definition of 'landscapeInv' was here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:44:6: error: nested redefinition of 'enum powermode'
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:44:6: error: redeclaration of 'enum powermode'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:391:14: note: originally defined here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:44:17: error: redeclaration of enumerator 'powerOff'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:391:25: note: previous definition of 'powerOff' was here
/home/tectu/projects/resources/chibios/os/halext/include/glcd.h:44:27: error: redeclaration of enumerator 'powerOn'
/home/tectu/projects/resources/chibios/os/halext/include/gdisp_lld.h:391:47: note: previous definition of 'powerOn' was here
main.c: In function 'Thread1':
main.c:18:1: warning: no return statement in function returning non-void [-Wreturn-type]
make: *** [build/obj/main.o] Error 1

I understand what that error means and where it does come from, but what is the propper way to solve it?


~ Tectu

[inmarket]

Which include files are you using?
It looks like main.c is including both glcd.h and gdisp.h

It should be either one or the other, either glcd.h if you are using the glcd API or gdisp.h if you are using the gdisp API.

If using the glcd API you have the choice of using the proper glcd project and its include file & makefile (which will then use the gdisp low level drivers); or alternatively you can use the glcd.h in the halext area if you want glcd emulation over true gdisp via the halext makefile (suitable if you are eventually planning on migrating API).

Hope that helps.

[Tectu]

Compiling worked with using gdisp.h instead of glcd.h. Thank you very much.

Would anybody mind if change the include path from the halext stuff from $(CHIBIOS)/os back to $(LCDLIB)/halext ?
I think it is really anyoing to delete and re-copy the halext directory to $(CHIBIOS)/os every time you pull the repository.

EDIT: Okay, I changed the makefile stuff now. Since glcd has no future and gdisp is going to be it, lcd.mk is now the main makefile. If somebody has a big problem with this, it can be rolled back easily.


~ Tectu

[inmarket]

Sorry, I see the possible problem now.
There are identical definitions for enum orientation and enum powerMode when using the glcd.h emulation under halext.
On my compiler it ignores them because the definitions are the same but not all compilers will (eg yours).

To fix: comment out the lines with enum orientation and enum powerMode in halext/include/glcd.h
I will add the fix in my next pull (and test it this time).

[Tectu]

Nothing to excuse about, sir. I am happy to hear that there are problems. I wouldn't ask otherwise as well

What for a compiler are you using? The current master state works very well for me. The only thing a user, in this case me, has to do in his main project Makefile is:

Code: Select all

LCDLIB = $(CHIBIOS)/ext/lcd
include $(LCDLIB)/lcd.mk
include $(LCDLIB)/halext/drivers/gdispSsd1289/gdisp_lld.mk

The first line is even optional. $(CHIBIOS)/ext/lcd is the default path, if no other is set.

Please send a pull request which fixes the issues that it works for everybody with every compiler. Protip: You can use the commit range on github's webinterface to just pull request your last commit. This way you don't 'loose' your current work on the library.


~ Tectu

[Abhishek]

I'll generate some more fonts for gdisp this weekend. If you want to request any fonts, welcome.

inmarket, Now thar the gdisp layer is almost becoming ready, Any sample of touchpad layer for gdisp? Or implementation ideas? It's as important as the gdisp for a good GUI layer.

I'll add to your ideas before we begin coding.

Abhishek