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

The LCD-driver library is specially designed for embedded use and can in principle be used with any processor size from 8-bit to embedded PC's.
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 and therefore 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.
Only if the wide-char text functions are used in connection with use of extended character sets then 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 then extended characters can still be handled in normal C strings by use of multi-byte characters.

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

Yes no problem.
Although use of a full C standard conformant compiler is recommended, then the library can still be used with such compilers which require use of different intrinsic pointer types dependent on wether the objects is located in ROM and RAM.

Such pointer limitations can be overcomed by mapping the compilers intrinsic memory type qualifers to type qualifer names in the library. See Advanced FAQ list for more information.

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

All LCD controllers which 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.

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

New LCD-controller variants are constantly introduced on the market. To check if 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 command and register set of the LCD controllers already mentioned on the web page.
Please feel free to ask us about a specific LCD controller if you are in any doubt.

It is 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 then the high-level software interfaces is 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 use the LCD-driver type ZZZZ?
What is the difference between a "LCD driver" and a "LCD controller"?

A "LCD driver" chip drives the SEGment and COMmon video scan lines connected to the LCD screen. The job for the driver is partly to convert the normal logic signal levels used by the processor system to the signal voltage levels needed by the LCD screen, and partly to ease update of a whole pixel matrix line at at time during the video scan operation.
"LCD drivers" normally interface to a "LCD-controller".
 
A "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". Therefore it is the "LCD controller" type which decide which LCD driver library package to be used.
 
Newer "LCD controllers" for smaller LCD screens usually have the "LCD driver" logic integrated on the chip. For instance all LCD controller variants in the KS07xx family.
 
With larger displays it is common that only the "LCD drivers" are located on the display module.
The display module must then interface to a seperate "LCD controller" in the target system via a "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).
A "LCD display bus" interface is, for instance, provided by the LCD controllers SED1335, S1D13700, S1D13705, SSD1905, S1D13706, SDD1906 etc.

Our display module has VSYNC and HSYNC signals plus a databus. 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 S1D13705, SSD1905, S1D13706, SDD1906 (b&w, grey-scale or color displays). For more details read also the answer 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 require constant dynamic refresh which will eat up all processor ressources. Explanation:
A "display bus" interface operates much like the TV screen:
A pixel data clock signal clocks picture information on the display databus 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 has 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 50-75Hz typical in order to prevent visible screen "flickering". Denpending on the display module pixel size and resolution the pixel data clock will therefore typically be in the MHz range. This makes it unrelistics to make the "display bus" scan by use of software. An (external) display controller must therefore be used as 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 registers 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 is 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 enable swapping of the LCD screen control between two independent applications running in the same target system, where each application have virtual owner ship over the full LCD screen and LCD hardware resources. For instance swapping between the normal application and a monitor application.

Do I have to spend time regenerate 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 easily be restored. The time it takes is a few hundred milliseconds typically, 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 relations between a character, a symbol, a font and a codepage?

Consider the following relationships:

• The data representation of a letter is a character ( ex 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 a font
• A codepage 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 codepage 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 multibyte character representations).

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

Yes, hardware fonts in controllers like T6963 and SED1335 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 monospaced fonts have the same memory footprint. The only difference from a monospaced font is in the header values which define the active look of a proportional symbol. See also the Q/A above.

Are 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. Beside this 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 the hard font is selected. If the 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, the character "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 the LCD driver demo application.

What is the RAM requirement of your graphical library?

The LCD-driver libraries have been optimized for 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 which, and how many, of the LCD library features your application will be using. A fair guess is anything from 8K for the basic features growing 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" is done both on file or function basis 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, then 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, for instance, to use the 'segmented font and codepage' 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 which and how many of the library features you will be using.

Soft-font support is one of the most ROM-consuming part 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 codepage 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 codepages 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.

Only 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 (by use of 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 which only supports write operations (like for instance, 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 "cost" of buffered mode is primarily 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 a LCD-driver library?

The easiest method is to use our web-based order-form generator and send a faxed order.
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. You can select to make prepayment via credit card, bank transfer or check. The shortest delivery time is on credit card orders.
To place an order, you just fill out the form, print it out, add your signature and fax it to +45 45505390.

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

Did you find an answer to your question here ?
If you need further information, please feel free to send us your questions by email, or call RAMTEX at +45 4550 5357.