My compiler allocate two copies of the soft-font tables, one in RAM and one in ROM. How can I avoid the RAM copy?

Many embedded compilers require use of a special (intrinsic) memory specifier key word to place constant initialized data objects in ROM only. Typical memory type specifier keywords used are for instance: code, rom, program, const rom etc. Check your compiler manual what is required with your specific compiler, and then in the library configuration file gdispcfg.h map the GCODE, FCODE and PFCODE definitions to this memory type specifier keyword.

My CodeVisionAVR compiler make a copy font data in RAM.
How should I use this compiler so font data are located in ROM only ?

Compilers, which have the limitation that a pointer can only be used with either objects located in ROM or objects located RAM, can be used with with the library with very little impact on functionality.
In most typical embedded applications fonts are only read and never written.
Fonts can therefor be located in ROM via memory type qualifiers and accessed via pointers qualified only for access to ROM memory.

For the CodeVisionAVR compiler this is controlled via compiler specific memory type qualifiers. Such intrinsic type qualifer keywords can inserted in library code via the library configuration file (See QA above).
For CodeVisionAVR you may simply change the default memory type qualifier mapping in the library configuration file to this:

#define GCONSTP /* Nothing */
#define GCODE /* Nothing */
#define FCODE flash /* Fonts and constant tables in ROM-only */
#define PFCODE flash /* Font pointers points to ROM-only */
#define PGENERIC /* Nothing */


A similar C standard confomance issue exists with some compilers which (incorrectly) interpret, for instance, const *ptr to mean a pointer to ROM-only objects. With such compilers same solution method as above can be used.
(The issue is that in standard C a const qualified pointer is just a gurantee that the the object pointed to will not be modified through the pointer. The same pointer is allowed to be used both with objects located in ROM and objects located in RAM.
I.e. const object_type * qualifier is a just part of C's strong prototyping and says nothing about where the object itself is located)

More information is found in the firstaid.pdf document included with the library.

My display module use 8 bit for each R,G,B color.
How can I connect it to SSD1906 which use 6 bit pr color ?

Connect the MSB controller color bits to MSB display bits, and then repeat with MSB controller bits for the lower display module bits. In this way you get full color saturation in both intensity directions.
The same procedure can be used with other display controller types, like for instance S1D13706

The library worked without problems in my old target system. However, I have changed to a faster microcontroller (24MHz, before 12MHz), and now I have problems with my graphic-LCD using KS0108.
Is there anywhere in the LCD-driver-library where I can implement wait-states, or is there another way to solve the problem?

Such bus timings and similar hardware issues are normally outside the scope of the LCD software library.

If your display is connected directly to the processor bus, any timing problems must be solved in the target hardware or via the processor hardware configurations.

If your display is connected to I/O ports (single-chip mode), you can extend the E setup timing in the bussim.c functions by repeating some instructions. See the library application note for single-chip mode for further information.

Hints:
For KS0108, SED1520 controllers the critical timing is usually the R/W (read/write) and RS (register address select) setup times before start of the E clock rising edge. Check the relative signal timings with an oscilloscope and compare with the data sheets for the display module / LCD controller.

When connecting an LCD using a 6800 type bus (R/W Eclk) to a processor using a 8080 type bus (/RD /WR), critical timing issues can often be solved by connecting the LCD R/W signal to an address bus line instead, and then accessing the LCD read and write registers at different addresses.

My T6963C display shows random spots all over the display.

This symptom has been experienced as being a hardware problem typically caused by a weak ground connection with respect to high-frequency signals. (It is therefore not related to the LCD-driver library as such).

Hint:
The symptom has been seen in places where ferrite beads have been mounted on all cable lines to the display module in order to reduce EMC problems. Replacing the ferrite bead in the power ground line with a 0-ohm resistor (using the same PCB footprint) has often solved the problem. Ferrite beads in the other signal lines cause no problems.

My SED1335 display "flickers" during update.

This is typical for the SED1335 controller and caused by "bus contention" when the processor and the internal video scan logic in SED1335 are competing over access to the LCD video RAM.

Hint:
The problem is solved by not defining GHW_USE_FAST_UPDATE in the library configuration header file. The processor will then only update the display in between video line scans. See also comments in the library ghwinit.c module, and the hint below.

My S1D13700 display produce "sparkles" during area clear or fill operations.

This is typical for the S1D13700 controller and caused by "bus contention" when the processor and the internal video scan logic in S1D13700 are competing over access to the LCD video memory. It typically occurs when S1D13700 is configured for b&w mode with the internal hardware text font enabled

Hint:
The problem may be solved by defining GHW_NO_HDW_FONT in the library configuration header file. The default SYSFONT then become a software font so the build-in hardware font is not used. The clear area and fill area operations then do not need to clear the text memory page in S1D13700, reducing the risk of on chip bus contention.

Existing text or graphic on the display is distorted when new text or graphic is written nearby.

This normally indicates that there is a problem with reading the LCD-controller memory, typically when doing read-modify-write operations directly on the LCD controller video data.

Explanation: If the new drawing operation (ex. text output) does not cover a full memory byte, then the library will do a read of the old content (which fails in your system for some reason), add the new bits, and then write the content back to the LCD-controller memory. The result is that only the newest text is shown in the screen data byte or that random bits are added.

For LCD controllers using vertical data bytes (like KS07xx and SED1520), the symptom is typically seen when two horizontal drawing operations follow each other on the same byte. For instance, part of the existing text above or below is clipped.

For LCD controllers using horizontal data bytes (like T6963C, LC7981 and SED1335), the symptom is typically seen when two vertical drawing operations follow each other on the same byte. For instance, clipping parts of the previous character in the text line when soft fonts are used.

Hints:
- Check the bus hardware signals during LCD-controller read.
- Check that the address definitions for read-registers are correct.
- If single-chip mode is being used, check the functionality of the read-access driver. Is the direction of the LCD-bus switched properly?
- Do a work around by compiling the library for buffered mode. The LCD-driver memory is then only written, so the symptoms are masked. The "cost", however, is the increased RAM consumption of buffered mode. See your main manual for details about setting buffered mode.

How do I use the libray with Embedded Linux

The LCD driver library itself is Operating System independent. The only requrement is that the driver code is allowed to get direct access to the address range where the display controller chip is connected.

With Linux hardware access is usually done via a handle (a pointer) obtained via the mmap(..) function. Use this pointer as a base address and define all the display controller registers as indexes relative to this base.

Just compile the library for single chip mode so all read write access is done via the two small access functions in bussim.c. Then update the body of these functions so display controller register access are done via the base pointer optained with mmap(..).