Peter van Merkerk
proportional_font.fnt (3602 bytes)

Hello world!

For a "Hello world!" program you need to:

  • Define mappings for the I/O pins as explained on the Porting page;
  • Include glcd.h
  • Include proportial_font.h
  • Implement the main() function:

    #include "glcd_io_your_mappings.h"
    #include "glcd.h"
    #include "proportional_font.h"
    int main()
       glcd_draw_text(3, 10, &proportional_font, "Hello world!");

A little more elaborate example can be found in the file demo.c which was used in this video.


The most important functions of the GLCD Library are:

Function Description
glcd_init() Initializes the display, this function must be called before any other function of the GLCD library.
glcd_clear_display() Clears all pixels on the entire display.
glcd_draw_pixel() Draw a single pixel.
glcd_draw_box() Draws a filled rectangle.
glcd_draw_frame() Draws a open rectangle.
glcd_draw_line() Draws a line between two pixel coordinates.
glcd_draw_text() Draws text stored in RAM memory.
glcd_draw_text_P() Draws text stored in program (flash) memory.

Other functions in the GLCD library are mainly intended for internal use.

Pixel coordinates

On a 100x48 display the upper left corner corresponds to pixel coordinate (0,0), the bottom right corner corresponds to pixel coordinate (99,47).

Page argument

In case of the text drawing functions the vertical position is specified by the page argument. A "page" in SED1531 speak is a row of 8 pixels high. On a 100x48 display there are 6 pages; the top row corresponds to page 0 and the bottom row corresponds to page 5. This implies that the vertical position of text is a multiple of 8.

Allowing text to be drawn at any arbitrary Y coordinate would significantly increase the memory footprint of the GLCD library, while at the same time would be a lot slower. Since the program memory of the micro-controller (ATtiny2313) used for development was nearly full support for text at an arbitrary vertical position was not added.

Color argument

Most drawing functions have a color argument. This argument can have one of the following values:

Value Description
0 Clear pixel(s)
1 Set pixel(s)
2 Invert pixel(s)


The GLCD library does not have a hard-coded build-in font. Instead you can provide your own, and if you so desire you may even use multiple fonts.

The code for the font data can be generated using the GLCD_FontGenerator utility.The GLCD_FontGenerator takes the font definitions from an ASCII file and produces a header file that is to be included:

GLCD_FontGenerator <font-definition-file> <header-file-name>

The proportional_font.fnt file is an example of a font definition file, its syntax is hopefully self-explanatory.

A character may be between 0 and 127 pixels wide and is always 8 pixels high. If you want higher characters you could define multiple fonts and draw the same text on two lines using one font for the upper line and for lower the lower line.

A font does not have to define all characters, to save memory you can choose to only define the characters you need.

The source code and a windows binary of GLCD_FontGenerator utility and proportional_font.fnt font definition file are included in the .zip file that can be downloaded here:

Naming convention

The GCLD library uses the following naming convention:

  • Function names are prefixed by glcd_ and are all lower case;
  • Macro names are prefixed by GLCD_ and are all upper case;
  • Typedefs are prefixed by glcd_ and postfixed by _t and are all lower case;
  • struct names are prefixed by glcd_ and postfixed by _s and are all lower case;
  • enum names are prefixed by glcd_ and postfixed by _e and are all lower case;
  • Function parameters and local variable names are not prefixed or postfixed and are all lower case;
  • In case an identifier (function name, type name, macro, variable name...etc) consists of multiple words the words are separated by an underscore ('_')

Hardware requirements

GLCD library requires that the interface between the display and the micro-controller supports reading data from the display. This requirement precludes some solutions that use shift registers between the micro-controller and the display to reduce the pin count on the micro-controller. The read-back capability is required because the SED1531 display controller stores multiple pixels in a single byte, which implies that setting or clearing a pixel involves a read-modify-write of the display data.

A workaround for not having a read-back capability would be to keep a copy of the display data in the RAM memory of micro-controller. However for a 100x48 display this would require 600 bytes for the display buffer alone. Since RAM memory is usually in short supply on 8-bit micro-controllers (the GLCD library was made to run on a ATtiny2313 with only 128 bytes of RAM) this approach was not chosen for the GLCD library.

Project Admins:


Wiki: Porting

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks