bit mapped fonts for lcd displays manufacturer

GLCDFont Editor/ Creator / Generator , Import and convert system fonts, edit and generate system or Editable fonts (up to 256 colors), create fonts from scratch

Easy settings for output of data array for C , Pascal, Basic or assembler codes, the development tool you use for your favorite embedded system.Whole Animation is converted to GLCD data in one single run.

4 different font categories are available : ANSI and Unicode international System fonts (installed on Windows) , the SVG fonts (for grayscale 256) based on vector graphics for a better anti-aliasing quality, and Freely Editable Font, for customized bitmap glyphs.

The Parameters in the green frame are separated for each DataStructure (1st Parameter of this list) These data are then present or not in the Descriptor blocs of the output data.

The Dot Factory is a small open source tool (MIT licensed) intended to generate the required C language information to store many fonts and images, as efficiently as possible, on a microcontroller. These fonts are then uploaded via the LCD driver (see the Drivers and Modules page for a few) to the actual dot matrix LCD. It is written in C# for Visual Studio 2008 and has been tested on Windows XP, 2003, Vista, 7 and Linux via Mono.

Working with dot matrix LCDs with microcontrollers, while not difficult, is tedious. The actual LCD controller allows us to upload simple visual data (dot on or dot off) into the LCD’s dot matrix, but not much else. It is up to our software to decide what to upload when we want to draw lines, circles and more importantly – text.

While there are software graphic libraries that allow us to generate a character “on the fly” using vector graphics (the character is described as a series of drawing commands that allow scaling and decoration) – these are much too complex and large to integrate in a microcontroller environment. Consequently, we must store the exact appearance of a character as a series of 1s and 0s, equivalent to a “dot on” “dot off” on the LCD, and upload this as a bitmap when we want to display text. While it is possible to generate this manually, it is desired to have a tool to do our grunt work by converting windows fonts (given a size and decoration) into a series of bitmaps.

TDF is comprised of two panes – the input pane on the left (what you want to generate) and the output pane on the right (the generated output, in C code). The input pane can accept either a font of your choice (for writing text to the LCD) or an image. When generating a font, you have the option of either generating all the available letters (by selecting “All” in the Insert Text box and clicking the plus button) or by typing in which letters, numbers or symbols you are actually using in your application (for example: 0123abcd). If you are writing a simple application that has only a few sentences, you can type them wholly in this box without fear of duplicating letters – TDF takes care of that by discarding any duplicates. This way only the letters you use will take up space.

Once you have completed setting up what it is you’d like to generate (be it an image or font), select the output method in the output pane. If you are using the LCD drivers on this website, you want it to generate an MSb first output, otherwise images will come out wrong. If you have a compiler that supports the “0b” binary specifier, you can select “binary” rather than “hex”. This will allow you to visually see the pixels you will set and allow for manual touch up by the user without having to calculate hex and experimentation. Click generate and your C code will be outputted to the text box below. Copy paste this into your application (it is recommended to put this in a separate module, not your LCD driver module, for organizational reasons).

Note that 5×7 and 5×8 fonts cannot be generated using this tool. While some TTF fonts can render characters this small they are usually distorted to the point of uselessness. You can download a ready made five by seven font here. I ripped this font from text file a while ago, so apologies to the uncredited author.

The character bitmap array: This holds the actual characters as a bitmap (only the characters selected in the input pane). Each byte represents a single vertical page sent to the LCD. All vertical padding is removed from the characters

The character descriptor array: Allows O(1) mapping between a character’s ASCII value and required meta information about the character – namely its width in bits and its offset into the character bitmap array. When the LCD driver needs to find where character X is located in the bitmap array, it will jump to index [X - font.startCharacter] in the descriptor array. The startCharacter is the first character (that is, the character with the lowest ASCII value) used for this font. By defining a startCharacter we can reduce the number of elements in the descriptor array.

The font information: This element is essentially the font descriptor for this font. It holds information regarding this font like the name of the character bitmap and descriptor arrays, the font start character and how many pixels wide a space character is for this font. The LCD driver will replace the space character with empty pixels (this saves both processing time, space in the character bitmap array and space in the character descriptor array – since the space is the first ASCII character and is commonly used).

The generated structures are generated with documentation, but you may want to see a sample bitmapDb header file for detailed info on the character descriptor array and font information structures. For image generation, only the image’s bitmap array and size descriptors are generated. Note that the height value is pixels (bits) and width values are in pages.

Version 0.1.2 (29may11): Fixed width/height being swapped. Added support for configuring image descriptor format (bits/bytes). Thanks geo for the heads up and suggestion

Version 0.1.1 (25may11): Added support for multiple descriptor arrays with a double lookup. Before this version TheDotFactory could generate Unicode characters but the lookup tables were usually too huge to be of any use. Using this feature, a double lookup is employed, allowing for fast lookups for characters residing at disparate ranges. See the video for an explanation (will be posted in the next few days). In addition to this, added support for specifying character ranges instead of inputing the actual characters. For example, <<100-120>> will generate characters for ASCII characters 100 to 120. Thanks a bunch to Archis Bhave for inputs and testing. Source is now distributed via github.

Version 0.1.0 (15dec10): Added support to format the generated variable names (thanks SpiralBrain), added end character indication to font information (thanks Nick Jensen), added the ability to save to clipboard from File menu and added the ability to save the source/header to file via file menu (don’t remember who, but someone wondered why this wasn’t in. I personally think all fonts should be in a single module and so I opted for copy/paste, but to each his own)

Version 0.0.7 (28may10): Added ability to select whether character descriptor array is to be created and which character will be used to visualize the font (thanks Christian Treczoks), syntax coloring automatically disabled when generating large amounts of text (will be fixed properly next version), properly handled bitmaps with no black pixels in them (displays error instead of a crash), some minor cosmetics

Version 0.0.6 (03mar10): Bug fix for image generation (tried to save a temporary file for debugging in a custom directory) – thanks to Nir Shemeshfor pointhing this out!

Version 0.0.5 (23dec09): Added support for rotation (90 degree increments), space character generation, width (bit/byte) selection of character width and font height, optional generation of character height/width and font height, structures are now generated with documention, input text and font is persisted throughout invokations of the application, persistent preset management – add, edit, delete output configuration presets

To run this executable, you must have the .NET framework installed. The stable binary has been in the wild for a month at least with no major bugs reported. Non stable binary contains new features and bug fixes (see revision history).

Currently I am working on the deluxe version of the data logger. This version has a LCD screen and capacitive buttons to control the software. The Adafruit library for the display is quite large and almost uses the whole RAM, because it is a pixel oriented library. My own implementation is a text only library using 8×8 pixel characters. This simplify everything and reduces the RAM costs.

To convert the bitmap font into bytes, I wrote a small application for OS X (minimum version 10.10). It accepts a PNG image with the characters in it and converts it into bytes with the correct bits set.

First you select the mode on the left side of the application window. In this example the mode is set to “8×8 Fixed Top-Down”. Select the output format in the bottom left corner of the window.

Here an example 8×8 pixel font file for the converter. The font converter ignores any transparent and light values. So you can use them on a second layer as a grid for the font.

You can use this font template for Adobe Photoshop if you plan to deign a own font. The template uses a grid on one layer, so you can draw the font information on the second layer.

The software is written in Swift 2 and is using many of the new features of this language. The code is extensible and you can easily add own converter and output formats. If you created useful additions, please let me know.

I am using a 3.5: TFT LCD display with an Arduino Uno and the library from the manufacturer, the KeDei TFT library. The library came with a bitmap font table that is huge for the small amount of memory of an Arduino Uno so I"ve been looking for alternatives.

What I am running into is that there doesn"t seem to be a standard representation and some of the bitmap font tables I"ve found work fine and others display as strange doodles and marks or they display upside down or they display with letters flipped. After writing a simple application to display some of the characters, I finally realized that different bitmaps use different character orientations.

What are the rules or standards or expected representations for the bit data for bitmap fonts? Why do there seem to be several different text character orientations used with bitmap fonts?

Are these due to different target devices such as a Windows display driver or a Linux display driver versus a bare metal Arduino TFT LCD display driver?

What is the criteria used to determine a particular bitmap font representation as a series of unsigned char values? Are different types of raster devices such as a TFT LCD display and its controller have a different sequence of bits when drawing on the display surface by setting pixel colors?

Is there some method other than the approach I"m using to determine what transformation is needed? I currently plug the bitmap font table into a test program and print out a set of characters to see how it looks and then fine tune the transformation by testing with the Arduino and the TFT LCD screen.

I"m not fully conversant with the standard descriptions of bitmap fonts however I think of this as being an 8x16 bitmap font in which each character is 8 pixels wide and 16 pixels in height or an 8x16 bitmap font.

With the size of this table and the small amount of memory on the Arduino Uno, I started hunting for other bitmap fonts that would be legible while also taking up less memory. See reducing memory required for KeDei TFT library used with 3.5" TFT display with Arduino

What I hoped to find was something around a 6x6 bitmap font so that the definition of the bitmap font table would change from const unsigned char font_table_16_col[96][16] = { to const unsigned char font_table_16_col[96][6] = { which would free up a significant amount of memory. And experiments with cutting the table down by removing lower case letters showed that helped as well.

Finding alternative bitmap fonts has been more difficult than I thought, envisioning someone with the motherlode of bitmap fonts in a GitHub repository somewhere, easily found with a search or two.

What I have run into is that while I have found several different examples of bitmap fonts not all seem to be compatible with my specific 3.5" TFT LCD display.

For instance here are representations of four different bitmap fonts showing the bits of the bitmaps for two characters, the exclamation point (!) and the double quote ("). The 5x8 seems to be rotated to the clockwise by 90 degrees. The 8x8 and the 16x8 seem to be oriented correctly and the 13x8 seems to be upside down.

The bitmap font representations in the image above, showing the differences in text character orientation, were generated by a simple Windows GUI and displayed with a dash (-) representing a bit value of zero and an asterisk (*) representing a bit value of 1. This is the output of a Microsoft Windows GUI application whose WM_PAINT message handler which draws the displayed image is as follows:

I have modified the code that displays text using the bitmap fonts so that for a particular bit map the character drawing logic will perform several different kinds of translations between the bitmap font representation as a series of hexadecimal digits and how the series of digits are used to determine which pixels to turn on and which to turn off.

The code for drawing a single line of a character is as follows. The outline of this function is to provide to the LCD controller a rectangle specifying the region of the display to be modified followed by a series of two 8 bit writes to set the two byte RGB565 color value of each of the pixels in the region.

static bool TFTLCD::draw_glyph(unsigned short x0, unsigned short y0, TftColor fg_color, TftColor bg_color, unsigned char bitMap, unsigned char bmWidth, unsigned char flags)

and the source code that uses the above function for drawing a complete characters is as follows. This code uses the drawGlyph() function to draw a series of slices of the text character from top to bottom. When a bitmap transformation is done depends on the bitmap representation.

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

TFTLCD::draw_glyph(Font::now_x, Font::now_y, Font::font_color, Font::txt_backcolor, Font::font_table.table[char_i_x + char_m], Font::font_table.nCols, glyphFlags);

There are a number of font specifications including rasterized bitmap type fonts. These specifications do not necessarily describe the glyph bitmaps used in application such as the KeDei TFT library but rather provide a device independent description of a bitmap font format.

Oracle in Solarix X Window System Developer"s Guide, Chapter 4 Font Support at https://docs.oracle.com/cd/E19253-01/816-0279/6m6pd1cvk/index.html has a table listing several different bitmap font formats and has this to say:

This page describes the SGX-120L"s fonts and instruction set. For hookup, configuration and specifications, please see the hardware reference. These instructions apply to SGX-120L, version 2.0 and later. For a summary of differences from the earlier versions, see the upgrade guide.

The SGX-120L is a 120x32-pixel graphics LCD with a 9600bps serial interface. It can store a customizable font and 15 full-screen bitmap images in its flash memory. The SGX has four font sizes that can be mixed on the screen, and can draw lines and plot points. This page describes the control codes that format text and the escape codes that download, draw and store graphics.

SGX-120Ls accept asynchronous serial at 9600bps, 8 data bits, no parity, 1 or more stop bit(s), often called "N81." They will accept RS-232 input, inverted TTL, or non-inverted TTL. Non-inverted TTL requires cutting the SPol jumper on the circuit board. See the hardware reference for further information.

SGX-120Ls accept character codes 32 to 191, with the lower codes (< 128) corresponding to the standard ASCII character set. Characters can be added or changed by editing the .BMP graphics stored in pages 0 and 1 of the display"s memory. (In the character set shown below, the higher codes, 128+, contain guidelines for designing your own characters). See here for more information on downloading bitmaps.

Any pair of stored bitmaps can be used as a font; the display controller selects a 6x8-pixel chunk of the selected bitmap according to the character code received and displays it on the screen in the current font size and position. See ESC-F in the Escape instructions below.

SGX-120L offers multiple font sizes, which can be freely mixed on the screen. The following screen layouts show position values for the various font sizes. Positioning (ctrl-P below) works in terms of the font-size in effect at the time. In the illustrations below, position = row + column.

SGX-120Ls understand a small set of control codes that format incoming text. Some are standard (carriage return, backspace, tab) and others are display-specific (position, right-align, backlight on/off). Codes not listed below (e.g., Null, 0) are ignored by the display.

For example, you clear the screen and send the text Hello— Hello appears at the upper left of the screen, in positions 0-4. Now you send ctrl-A, followed by J— Hello becomes Jello.

Screen positions are in terms of the font size in effect at the time, so the range is 0-79 for the 4x20 font and 0-19 for the 2x10 font. It"s not recommended for programming purposes, but you can also use a text number like "24" to specify ctrl-P position values. Text numbers must be followed by a throwaway character—like a space or a period—which will terminate the number but won"t be displayed.

Displays text (usually numeric) within a field 2 to 8 characters wide. The byte that follows ctrl-R is a text number from "2" to "8" (50-56 dec, 0x32-0x38 hex) that sets the field width. The text after that will be invisibly stored until one of the following is received:

These are multipart instructions that begin with the Escape character; 27 dec, 0x1B hex. Escape instructions work with graphics and/or memory: downloading/storing/recalling bitmaps, plotting points and lines, setting startup configuration.

Numbers Used in Escape Instructions:Many Escape instructions accept number(s) to specify coordinates, screen pages, etc. The standard way of specifying numbers is as a single byte set to 64+n, where n is the desired number. For example, the value 123 decimal (0x7B hex) is sent as a byte containing 123 + 64 = 187 decimal (0xBB hex). However, most numbers can also be sent as a text string such as "123." (i.e., four bytes set to the ASCII codes of the printable numbers and the period: 49 50 51 46 decimal (0x31 0x32 0x33 0x2E hex). This allows you to type instructions from a terminal program for demonstration purposes. It is not recommended for programming, as it uses multiple bytes when one would do. It is deprecated and may not be supported by future products.

Specify the screen address to be used by Escape B. ESC A (uppercase A; 65 dec, 0x41 hex) x y where x is 0-119 (the width of the screen) and y is 0-3 (height of the screen/8 bits). Both x and y are sent as a byte set to 64+n, where n is the coordinate value.

There are few practical applications for writing individual bytes to the screen. With instruction overhead, it"s very slow. A much better way to put a bitmap on the screen is to download it to the display (Escape D G), store it in flash memory (Escape X n) and either recall the entire screen using Escape E n, or set it as a font (Escape F n) and display 6-byte chunks using regular ASCII characters.

Download a bitmap graphic to the screen. ESC D (uppercase D; 68 dec, 0x44 hex) G (uppercase G; 71 decimal, 0x47 hex) followed by 480 bytes of data. These bytes map to the screen left to right and top to bottom. Byte values are 0-255 (0x00-0xFF hex). See here for more information on downloading bitmaps.

The bitmaps that the SGX uses to draw individual characters are stored as a pair of full-screen images. Each character occupies a 6x8-pixel block. An SGX font can have up to 160 characters corresponding to ASCII codes 32 to 191 decimal (0x20 to 0xBF hex). The default font is in screen pages 0 and 1, but using Escape F you can instruct the SGX to use other stored bitmaps as the font source. These alternative fonts don"t have to be letters and numbers— you can use them as 6x8-pixel graphical icons (or larger graphics by tiling multiple characters). Here are the font-source values:

To change the font size and font source, add the values together. For example, to use tall (6x16-pixel characters) from stored bitmaps at pages 4 and 5, you would use the value 2 + 8 + 64 (where 2 sets the size, 8 sets the font pages, and 64 is the magic number that"s added to most escape-code arguments).

Set the mode for points and lines to n — OR (0) or XOR (1). ESC M (uppercase M; 77 dec, 0x4D hex) n. Add 64 to n. In OR mode, dark pixels always print dark; in XOR mode, dark pixels print dark on a light background and light on a dark background. Light pixels always print light regardless of this setting.

You can highlight multiple lines by adding together the values of n from the table; for example, to highlight the top and bottom lines n=1+8 (+64, as usual). To eliminate all highlights, use n=0 (+64).

Draw a line from the end of the last line drawn to the specified x y position. ESC T (uppercase T; 84 dec, 0x54 hex) x y where x is 0-119 and y is 0-31 (add 64 to x and y). Line-to is a handy shortcut for drawing simple connect-the-dots graphics (e.g., boxes) or graphs.

Set the vertical origin to the top or bottom of the screen. ESC V (uppercase V; 86 dec, 0x56 hex) n, where n is 0 (+64 for top of screen) or 1 (+64 for bottom).

Write configuration settings that automatically take effect when the display is powered up. ESC W (uppercase W; 87 dec, 0x57 hex) n where n specifies the startup options from the table. Add 64 to n. See here for a Windows software tool that automates the configuration process.

You can combine settings by adding values of n from the table; for example, to have the display start with the backlight on and the large (tall and wide) font in effect n=1+8+16 (+64, as usual). To turn off all startup options, use n=0 (+64). Note that ESC W works only when the Dsu (Display setup) jumper is uncut. When the display is set up the way that you want it for long-term operation, cut the jumper to prevent accidental configuration changes.

Options written by ESC W replace previous settings, they do not add to them. For instance, if the SGX is currently set to start up with the backlight on and you want it to also show the page 2 bitmap, you must send an ESC-W instruction with both options (27 87 67 dec, 0x1B 0x57 0x43 hex).

Store the current screen to the specified page of flash memory. ESC X (uppercase X; 88 dec, 0x58 hex) n where n is the screen page 0-16 (+64). Once a screen is stored, it can be recalled to the screen using ESC E. Note that screen pages 0 and 1 are the display"s default font--if you store a non-font bitmap to these locations text will print as blocks of that bitmap, not as recognizable letters an numbers. For this reason, the display ships with pages 0 and 1 write-protected. You can undo this safeguard (to alter the font) using ESC W above.

To convert image from bitmap file (or other standard graphics file format) to data array select from File menu command "Load image". Next, select byte orientation (for example : vertical for KS0108, SED1520, SPLC0501C etc; horizontal for : T6963C, SED1335 etc). If in data array must be image size (width and height) select "Include size" checkbox and specify endianness of size (for example: Little endian for AVR; Big endian for ST7). Size are placed in two 16-bit variables at the begin of data array. Next, specify pixels/byte parameter. If display can support miscellaneous font size (displays with T6963C controller) image can be converted to array of bytes with specified amount of pixels in each byte. At last select from "File" menu command "Save output". Data array will be saved in specified file. Next, just include this file into project and use array name as parameter for function that displays bitmap on LCD. If you have trouble with use generating file, or program will generate wrong files please let me know.

When your project involves a bitmapped display, you will need fonts.  When you"ve gone beyond the old, reliable 2-line LCD (courtesy of the Hitachi HD44780 that powered my Twatch), you need fonts.  When you want something that looks good, you need fonts!

The ST Micro firmware library has a graphics library with a font importer.  However, the HTTP app I adapted for my clock doesn"t use the library.  I"m not sure what ST used to create the fonts in the original app, but I found a good app to create fonts.  The Dot Factory  is a small utility that is used to generate C source from TrueType and bitmapped fonts, and it can also be used to convert bitmaps to C source.

There are just a few more things to do.  We need to copy the font code file into the project directory, but first we need to put in an include to "fonts.h" and create a struct object that describes the font to the graphics API.

The only annoying part was counting the width and height in pixels for the sFONT struct.  That"s not done automatically.  If you get the height wrong (easy to do), the display will resemble an odometer, or a slot machine as the digits go out of alignment every time they"re drawn!

Here’s a neat little trick: take the jaggies out of scaled fonts on the fly! This technique is for use on graphic displays where you might want to scale your fonts up. Normally you’d just write a 2×2 block of pixels for every area where there would have been one pixel and boom, larger font. Problem is, that also multiplies each empty area and you end up with jagged edges in the transitions that really catch your eye.

The technique has been packaged up in a simple function that [David] wrote to play nicely in the Arduino ecosystem. However, the routine is straightforward and would be quick to implement no matter the language or controller. Keep this one in your back pocket!

Now if all you have on hand is an HD44780 character LCD, that one’s arguably even more fun to hack around on just because you’re so limited on going beyond the hard-coded font set. We’ve seen amazing things like using the custom character slots to play Tetris.

In a project I am currently working on I needed a font to embed in the ROM of an ARM Cortex micro-controller that could be used on one of these ChLCD modules from SparkFun. The display in my application is currently mounted in a landscape orientation, but I didn"t want to preclude using it the other way around, or changing the font. I"ve written a few bitmap font editors over the years for various graphical LCDs, VGA displays and LED matrix displays. They all have a common interface, a character being edited with oversized pixels and a preview of the entire font. I decided this time to do a "proper job" of the code and write a Python GUI app that should be cross-platform and allows saving and loading of fonts.

The basic application lets you create a font with up to 32x32 pixel characters and up to 65536 characters. You can select the fore ground and background colours although this only affects the UI at the moment. All of this can then be saved and loaded from a *.fnt file. (Note these aren"t Microsoft .fnt files they are unique to this program as they contain a python object.) The actual generation of a suitable file for inclusion in your micro-controller project is done as a separate stage using the "Export" dialogue. Currently there is only the exporter for generating the font file for my ARM project, although this is vanilla C code with one byte per character line. To make an exporter for your project you simply need to copy the arm_c.py file from the exporters directory, read the comments and edit the function and exporter name fields to generate the output format you need. I might get around to writing another couple of exporters for controllers/devices I own but it really is a pretty simple function call.

As ever my code is released as GPL, you will need a recent release of Python and PyGTK 2.6 or better, the code should be platform independent but has only been tested on Ubuntu 32 and 64 bit. Comments/suggestions/bugs will get to me most rapidly by email: nathan@nathandumont.com, make sure to put a sensible subject etc. as there"s a vicious spam filter on that account.

I"ve also updated the code. It now runs on Python 3 (tested 3.8.5) and uses the pygobject framework (package python3-gi on Ubuntu) so it should run happily on Ubuntu 20.04 and any other modern system. There"s also a new drag draw mode to speed things up a bit!

If your device has a LCD, chances are you can use our bitmap fonts, which have been licensed by our customers for consumer electronics, industrial, medical, fitness, and other applications. VersaFont™ offers

flexible commercial licensing terms & options – some of the world’s leading technology and manufacturing companies have licensed our fonts for their products

VersaFont™ has been widely used on a large number of devices such as mobile phones, digital cameras, printers, and medical equipment around the globe. The excellent proven track record of VersaFont™ means it can work for you, too! Free samples are available upon request.

We have worked closely with our customers on a variety of embedded applications and our experience can help your product development, especially when multilingual computing is required. Rest assured that you will be working with a US company every step of the way to ensure a proper integration and embed of our fonts into your product. Your satisfaction and success are our top priority.

Most of the pixel fonts have no gap between the pixels. You can easily make that yourself by adding some kind of grid on top. The method depends on which program you use and what you need it for.

In Photoshop, with a grid on top, some glow on the letters, some gradients, some noise and a slightly distorted perspective you should be able to copy that LCD look:

Here is a typical font table stored in CGROM memory that contains the character set. A two-dimensional array references the character within. The upper four bits of the byte select the column, and the lower four bits select the row. When you send a byte, consisting of four upper bits and four lower bits, to the WS0010 display RAM an automated function looks up the row and column in this font table and selects the character. Then another automated function called "Character Generator" reads the bitmap data and sets the dots on the physical LCD display according to the bitmap data.

If you want to display the character "A", you can see that the upper bits are LHLL, and the lower bits are LLLL, thus you would send the character code LHLLLLLL or binary "01000000" to the Display RAM. The great thing about this display is that you simply need to send it the character code byte, and the rest of the work of looking up the font table, reading the bitmap, and setting the dots on the display accordingly is performed automatically. This makes the programmers job much easier eliminating the task of manipulating the individual dots.

One of the reasons why people find this difficult to understand is because this is actually an array inside an array. The first array selects the desired character from the font table as shown above. The second array is the bitmap array describes the bitmap structure of the character. Once you have selected your desired character that you wish to display by sending the character code, an automated circuitry takes over and begins reading the second array, which is the bitmap array.

If you are using the factory installed character set in the CGROM, then it is no problem as you can see, however if you wish to use your own custom character set and fonts, then you will need to know the organisation of both arrays and how they link. This information helps to write the routines needed to load the CGRAM with your own custom font table. Luckily, the documentation shows a little of how that works, but very few understand.

I call this the Rosetta stone diagram :-) because there are three things happening here and if you can understand them then the whole thing will make sense. The column highlighted in red shows the contents of the DDRAM memory. As explained earlier, this memory stores only character codes. As explained earlier a character code consists of eight bits where the lower four bits indicate the row, and the upper four bits indicate the column of the font table.

As you can see, bit 3 is not used, which means there are only three bits for the lower part of the byte, and four bits for the upper. Hence, the lower three bits can address eight rows in the font table and upper four bits address 16 columns in the font table. Therefore, permitting 64 characters in a character set font table. This is why the datasheet states CGRAM memory to be organised as 64 × 8-bits.

For the second part of our Rosetta stone, this column describes the CGRAM address. The CGRAM stores the font table, and inside the font table there is the bitmap information of each character. The CGRAM addresses indicated in red are never stored anywhere because it is the same set of repeating numbers counted by the lower 3 bits. It acts like a counter mechanism for addressing purposes, and automated by internal circuitry. Hence, everything highlighted in red appears to be automatic.

The bitmap of each character in this example consists of eight rows, where row 8 is reserved space for the cursor. Since there are only eight rows, only three bits count them. The lower three bits are for the row counting / addressing. Bits 3, 4, 5 are not used at all and simply behave as an index. Each address value can therefore select a row of bit-mapped data. Hence, for example, binary address 000000 fetches the bitmap data for the first row for letter "R", which is "00011110". The address is automatically incremented to 000001, and then brings the second row of data and so forth up to row 7.

When displaying characters defined in the CGRAM, the addressing mechanism / counting is automatic just as it is was when using the CGROM memory; the programmer needs only to send the character code of the character he wishes to display. There is not much information available on how to load this part of the memory with a custom character set, or information on the data structure to use. Once you know the addressing and data are organisation, the same principle of addressing stores bitmap data within the CGRAM. I hope this was useful for anyone learning how to use a WS0010 based display panel.