LCD driver library FAQ list

Is the LCD driver library compatible with the XXXX processor chip?

The LCD-driver library is specially designed for embedded use and in principle can be used with any processor size from 8-bit to embedded PCs.
The only requirements are:

• A standard-conforming C compiler for the processor family (see below).
• Sufficient memory (see the memory Q/As)
• The LCD controller can be connected to external bus or processor I/O ports (see single-chip Q/A)

Does the library support C-compiler YYYY?

The LCD-driver library is written in pure C, so it only requires a standard-conforming C, C++ or EC++ compiler. In practice, most embedded C compilers on the market can be used. For embedded PC's or systems using the 80x86 CPU family, the library can be compiled with Windows or DOS PC compilers.

Most library features only require a C89-standard-conforming compiler.
The only exception is if the wide-char text functions are used in connection with the use of extended character sets: in this case the compiler must support the wchar_t type defined in the newer C99 standard (ISO/IEC C standard 9899:1999 and later).
If your compiler does not support the new wchar_t type, extended characters can still be handled in normal C strings by using multi-byte characters.

Can my CodeVisionAVR compiler be used with library ?
It requires different pointer types for pointers to ROM and RAM objects.

Yes, no problem.
Although the use of a full C-standard-conformant compiler is recommended, the library can still be used with compilers that require the use of different intrinsic pointer types depending on whether the objects are located in ROM or RAM.

Such pointer limitations can be overcome by mapping the compiler's intrinsic memory type qualifiers to type qualifier names in the library. See Advanced FAQ list for more information.

What exactly is an LCD-controller "family"?
You support for instance the "KS07xx family".

LCD controllers that use the same basic command set and register layout are said to be members of the same "family", because they are equivalent from a software point of view.
The same LCD-driver software can be used with all variants in the LCD-controller family. The individual LCD controllers may come from different LCD-controller vendors.

Among the LCD-controller family members, there may be minor differences in the number of commands supported. However, such differences are mostly concerned with hardware-initialization features. These differences are either handled by the LCD-driver library via compiler-configuration switches or they may be ignored because they are not relevant for the internal library functionality.

If differences in, for instance, hardware initialization methods or data and register access methods, makes it inconvenient to use compilation switches, then the library may include separate initialization modules for different sub-groups of the LCD-controller family members.

Does the library support LCD-controller type ZZZZ? It is not mentioned on your web pages.

New LCD-controller variants are constantly being introduced on the market. To check whether a new LCD controller is supported by any of the existing libraries, you must compare the register layout and command set of LCD controller ZZZZ with the register layout and command sets of the LCD controllers already mentioned on the website.
Please feel free to ask us about a specific LCD controller if you are in any doubt.

Is it easy to change to a new display with another LCD controller?

Yes, it is extremely easy. Although the individual LCD driver library is highly optimized for a specific LCD controller family the high-level software interfaces are the same.
If fact, if the new LCD has the same pixel size as the old LCD your application source code can remain unchanged. This includes any graphic icons or custom fonts you may have created.

Our display uses the LCD-driver type ZZZZ?
What is the difference between an "LCD driver" and an "LCD controller"?

An "LCD driver" chip drives the SEGment and COMmon video scan lines connected to the LCD screen. The job of the driver is both to convert the normal logic signal levels used by the processor system to the signal voltage levels needed by the LCD screen, and to ease the update of a whole pixel matrix line at a time during the video scan operation.
"LCD drivers" normally interface to an "LCD-controller".
 
An "LCD-controller" holds the video image in RAM memory, and provides the normal data bus interface to the microprocessor.
The software libraries can only "see" I/O registers and video memory in the "LCD-controller". So it is the "LCD controller" type that determines which LCD driver library package is to be used.
 
Newer "LCD controllers" for smaller LCD screens usually have the "LCD driver" logic integrated on the chip. This is the case, for instance, for all LCD controller variants in the KS07xx family
 
With larger displays, it is common that only "LCD driver" chips are located on the display module.
The display module must then interface to a separate "LCD controller" in the target system via an "LCD display bus". The "LCD display bus" provides video scan data and scan clock signals to the "LCD driver" chips on the display module (for instance, 4-18-bit data bus, Frame-clock, Line-clock, Data-clock, etc.).
For instance, an "LCD display bus" interface is, for instance, provided by the LCD controllers SED1335, S1D13700, SSD1960,SSD1961,SSD1962,SSD1963,S1D13742,S1D13743, S1D13705, SSD1905, S1D13706, SDD1906, etc.

Some display module vendors have mounted a PCB board on their display module where "LCD-driver" chip(s) and a "LCD-controller" chip are integrated together. Then the display module has a normal external processor bus interface.

Our display module has VSYNC and HSYNC signals plus a data bus. Which library should I use?

Your display module has a "display bus interface" and must use an external "display controller", for instance SED1335, S1D13700 (B&W displays) or SSD1960,SSD1961,SSD1962,SSD1963,S1D13742,S1D13743 or similar (color displays), or use the Generic display driver library together with a processor which has an internal display controller.
For more details, read also the answers above and below

Our display has a "display bus" interface.
Can I connect it directly to processor I/O ports and make a software driver?

No, in general, processor I/O pins should not be used to emulate a "display bus" because the display module requires constant dynamic refreshing which will eat up all processor resources. Explanation:
A "display bus" interface operates much like a TV screen:
A pixel data clock signal clocks picture information on the display data bus into a line buffer on the display module. When the line buffer is full, the HSYNC signals latches the data so the video line become visible. Scan then moves to next line, etc.
When all lines have been clocked out and shown, the VSYNC (or frame) signal resets scan to the top of the screen and the process starts over again.
The VSYNC clock frequency is typically 50-75Hz in order to prevent visible screen "flickering". Depending on the display module pixel size and resolution, the pixel data clock will therefore typically be in the MHz range. This makes it unrealistic to make the "display bus" scan by using of software. An (external) display controller must therefore be used as a hardware interface to the display bus

We use your library with a B&W LCD. Is it easy to change to a Color LCD controller?

Yes, in fact you can just compile your existing black-and-white (B&W) application with the new color LCD library. The functionality of the color LCD libraries is a true superset of the B&W LCD libraries. You can add color functionality to your existing B&W application in any steps you like.

Is the library supplied with the source code?

Yes, in fact the LCD-driver library is only supplied as C-source code. The library source code is written in pure C, so it is processor-vendor and compiler-vendor independent. No assembler statements are used.

How is LCD register access done in the source code ?

All LCD register hardware access in the libraries is "standardized" at the C-source level by using the portable SG syntax. In practice, this makes the library portable to any embedded C compiler.
See www.ramtex.dk/standard/sgsyntax.htm for more details about the SG syntax.
(See also the Q/A below)

Can the library be used with single-chip processors?

Yes, the LCD-driver library can be used both when the LCD-controller bus is connected to an external processor bus (using 8080 or 6800 bus mode) and when the LCD-display controller bus is connected to processor I/O ports (single-chip mode). Selection between the two access modes is done with a compiler switch.

When LCD controller is connected to an external processor bus, the LCD controller registers are accessed directly. The LCD register addresses defined in the SG header file must be modified to fit the actual target hardware. (See also the answer above).

When the LCD controller is connected to processor I/O pins, LCD register read and write is done via two small access driver functions, which must be implemented by the user for the particular target system. An application note describes how these access functions should be created. Template read and write access functions are included with the library.

Do I have to reserve interrupts or any on-chip peripherals (e.g., timers) for the display driver?

No, the LCD driver library is system-independent. It does not use any (operating) system resources like timers or interrupts.

Is the LCD-driver library OS-prepared?

Yes, in the sense that no OS-specific features are required. No waiting points are taken, no interrupts are blocked, and no time-consuming polls are done in the library. The LCD-driver library is implemented as pure functions which return at once when completed.

Can my debug monitor use the LCD screen as well?

Yes, easily. You can use the 'screens' library feature and save all LCD driver software and LCD hardware states in a buffer for later restoring. This enables swapping of the LCD screen control between two independent applications running in the same target system, where each application has virtual owner ship over the full LCD screen and LCD hardware resources. An example would be swapping between the normal application and a monitor application.

Do I have to spend time regenerating the whole screen content from scratch when the power of my portable equipment is turned off and then on?

Not necessarily. With the 'screens' library feature, you can save the complete LCD driver software and hardware states in non-volatile memory (battery-RAM or disk) before system power-down. At power-up, the full LCD driver and hardware states can then be easily restored. The time it takes is typically a few hundred milliseconds, depending on the size of the LCD screen, the processor speed, and how fast data can be fetched from non-volatile memory.

Is it possible and easy to use the serial SPI interface of the LCD controller (rather than the parallel interface) with the KS07xx LCD-controller library?

Yes, both KS07xx parallel bus mode and serial mode are supported.
With serial bus mode, the compilation switch for "single-chip" mode is used. All LCD register access is then done via two small user-defined access-functions. You will only have to write an assess-driver function for your particular SPI-bus hardware. You can also use the template functions included with the library, which emulate an SPI-bus via software and I/O ports.

Please note that in serial bus mode it is not possible to do read-modify-write operations on the KS07xx screen content. The LCD-driver library must then be compiled for "buffered mode".

Is it possible to integrate Chinese or Arabic fonts?

Yes, extended character sets (like Unicode or ISO10646) are supported.

Are UTF-8 and UTF-16 encoded Unicode strings supported?

Yes.

What is the relationship between a character, a symbol, a font and a code-page?

Consider the following relationships:

• The data representation of a letter is a character ( e.g. 8-bit char or 16-bit wchar_t )
• The character 'A' = 0x41 is a data representation of a graphic pixel symbol showing A
• Graphic pixel symbols for the different characters can be combined in a table to make a font
• A code-page is a look-up table for conversion of a character to a font table index

Do Far-Eastern fonts take up much memory?

No, large national character sets do not necessarily take up a lot of ROM.

Font-handling in the LCD-driver libraries has been highly optimized for memory-constrained embedded systems. A special 'segmented code-page and font' feature in the library allows font reduction so that it only contains those glyphs (word icons or character symbols) actually used by the embedded application. This can save a huge amount of ROM memory, especially with far-eastern languages.

Best of all, this ROM memory optimization is done independently of the character representation used by the application in for instance C strings, so your application code will look the same. (The same ROM optimization is possible with ASCII, Unicode, and multi-byte character representations).

Can I use the hardware fonts in the T6963C, SED1335, and S1D13700 controllers?

Yes, hardware fonts in controllers like T6963, SED1335 and S1D13700 are fully supported, and can be used intermixed with the soft-font and graphic features in the library.

The only GUI-design consideration a programmer must take into account with hardware fonts is that text positions will be limited to those coordinates which match the hardware character size (i.e. x,y is modulo 8x8, 5x8, etc.).

Can hard-fonts be downloaded?

Yes, if the controller supports font download, like for instance T6963 and SED1335. This is easily done with the library function ghw_loadsym

Can soft-font symbols be downloaded at runtime?

Yes. Before compilation, soft fonts are just a C-source array of symbol data referred to with a font pointer.

You can choose to download fonts as binary data or, if you create a small interpreter which can recognize the C-array table format, directly as C-source code. The only requirement is that the binary footprint must be the same as that generated by your compiler when you compile a font C-source table.

Can proportional fonts be downloaded?

Yes. Proportional and mono-spaced fonts have the same memory footprint. The only difference from a mono-spaced font is in the header values which define the active look of a proportional symbol. See also the Q/A above.

Is there cursor support for the different fonts ?

Yes, the library has full cursor support for both soft-fonts and hard-fonts

When a soft font is selected: The cursor size is automatically scaled according to the size of the soft font. If the cursor blinking feature is used, it is controlled by the application by calling the library function gcursorblink with the appropriate intervals. Moreover, all LCD cursor handling is transparent for the application.

When a hard font is selected: For LCD controllers supporting hardware cursors (like SED1335 and T6963C) the hardware cursor support is used automatically when a hard font is selected. If cursor blinking is activated, it is controlled automatically by the LCD controller hardware. No software actions is needed.

How are fonts captured?
Is there a font-capture tool?
Are bit-mapped fonts supported?

The IconEdit tool can use Windows fonts as templates for new fonts. It can import both TrueType and bit-mapped fonts. The output from this tool is a set of C-source tables which can be directly compiled with the LCD-driver library.

We have a requirement for several different types of font. Do you have a product that will allow the character size to be entered (in pixels) from which a bitmap can be generated?

Yes, with the IconEdit program you can easily create your own fonts, by editing on the screen in a WYSIWYG-mode. The output from the program is a C-source table which can be directly included in the application and used with the LCD driver libraries. Our LCD-driver libraries support any pixel size for symbols and fonts.

The IconEdit program can also import and convert Windows TrueType font characters to bit maps. The automatic vector-to-bitmap conversion works well if the pixel height for the font is > 20-25 pixels.
However, if the font height is less than this, the character's "look" will be limited by the finite resolution of a pixel-matrix display, and some editing should be expected to be necessary to get a good "artistic look".

A number of different ready-made fonts are included with the libraries. Several can be seen by downloading and running one of the LCD driver demo applications from one of the display controller family pages, either one of the Color / Grey display drivers family demos or one of the B&W display drivers family demos.

What is the RAM requirement of your graphical library?

The LCD-driver libraries have been optimized for a low memory footprint. The exact RAM consumption depends both on the features used and the library configuration.

Typically, RAM consumption is approx. 100 bytes, depending on the configuration. Minimum RAM for global and static variables with one viewport can be as low as 32 bytes. (See also the buffered mode answer).

What is the average ROM requirement of your graphical library, when using only the basic text and graphic features?

The actual ROM consumption depends very much on how many, and which of the LCD library features your application will be using. A fair guess is anything from 8K for the basic features to 24K or more if most of the advanced features plus a number of soft fonts are used.

Does memory scale up or down depending on the features that I use?

Yes, you "only pay for what you use". The memory "scaling" on both file or function basis is done via the linker and via configuration switches in a header file where you can turn code generation for different features inside functions on and off at compile-time.

Hints:
If you compile the whole library after configuration and create a traditional lib file of *.obj modules, the linker will do the ROM-optimization automatically. The library is highly modular, so this ROM-size optimization works well even with older non-optimizing linkers.

Another method of optimizing the ROM footprint is to use the 'segmented font and code-page' features (see answer below).

Is it feasible with 100 bytes of RAM and about 16 Kbytes of ROM available in my target system?

The RAM is OK.
The ROM requirement will depend on how many and which of the library features you will be using.

Soft-font support is one of the most ROM-consuming parts of the LCD-driver library. In particular, soft-font tables can take up a lot of ROM. In many applications, however, you need only use a few soft-font tables and you can use code-page support to create segmented fonts optimized to contain only those character symbols actually used by the application. This approach can give a significant reduction in the amount of ROM used by soft fonts. Segmented fonts and code-pages can most easily be created using the IconEdit tool.

Do I need a RAM buffer to hold a ghost image of the entire display on the micro controller?

Not necessarily. As default all updates are done directly on the LCD-screen buffer to save RAM space.

However, if the library is compiled for buffered mode (necessary with some hardware configurations like the KS07xx serial mode), then the RAM buffer is updated first (using read-modify-write operations) before the changes are flushed to the display (using write operations only). See Buffered mode below for details.

What is "buffered mode"?

In non-buffered mode, all read-modify-write operations are done directly on the LCD-controller memory. (Library default configuration for optimized RAM consumption).

In buffered mode all read-modify-write operations are done on a RAM copy of the screen content. When all the updates have been completed by the high-level function, all the changed bytes are flushed to the LCD-controller memory by using write operations only.

The advantages of buffered mode are:

• The library can be used with LCD display hardware that only supports write operations (such as, the KS07xx serial bus mode).
• With most target systems, the update speed is faster because the hardware is updated only once at the end of each high-level function.
• Use of the library feature "delayed update" is enabled. When delayed update is activated, multiple high-level functions can be called in a row to draw complex pictures. When delayed update is released, the complete picture is flushed to the screen. This gives the visual impression of a much higher speed.

The main "cost" of buffered mode is a higher RAM consumption, because the size of the graphic buffer must be added to the basic library RAM consumption:

• For B&W displays, the graphic buffer size is approx. = (pixel_width*pixel_height)/8 bytes.
• For color displays, the graphic buffer size is approx. = (pixel_width*pixel_height)*(bits_pr_pixel/8) bytes.

Code generation for buffered mode is selected with a compiler switch.

How does the license work for the LCD-driver Library?

It is a site license for your company and can be used by any number of developers in the project team.

Can I use the library in multiple products under one license?

Yes, compiled source code can be used in any number of products developed by your company and produced in any number of units without any royalties.

If you (re-)distribute library source code to customers, fully or in part, then a license must be purchased for each of your customers.

How do I order an LCD-driver library?

The easiest method is to use our web shop to order the product.
You may also request a "proforma invoice" for use with bank transfer orders, or your company's internal ordering process

The procedure is as follows. From the product pages add the product variant to the shopping list, and follow the link to the order form. Here you select your country and the delivery method.
The full price, including freight costs, is then calculated automatically.

To place an order, you just continue to the ordering pages and fill in the form.
You can choose to make prepayment via credit card or bank transfer.
The shortest delivery time is on credit card orders.

Can I get a pro forma invoice before I do prepayment via bank transfer?

Yes certainly. The easiest way is to use the same web-based order procedure as described above, and then just select prepayment via bank transfer.