lcd panel font factory

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.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.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

Fonts4Free.net is a font repository that offers over 10.000 freeware and shareware TrueType (.ttf) or OpenType (.otf) fonts with a live custom phrase preview option. The fonts presented on this website are their authors" property, and are either freeware, shareware, demo versions or public domain. For correct licensing, please contact the designer of the font.All fonts at Fonts4Free can be downloaded freely, we do not sell any fonts in our archive. A downloaded file contains typeface file, readme file, license aggrement and normal, italic, bold versions of the font if available.

Yes, display fonts are generally better for logos, though of course you can use any font that fits your brand and delivers the functionality you need. However, display fonts are designed for bold, standalone usage, whether it’s a headline, advertisement, or logo. What distinguishes a display font is not its appearance but rather its usability at large sizes. Display fonts include an enormous range of aesthetics, from the very understated to the wild and eccentric, so designers have a wide range of moods and stylistic choices available to them.

Display fonts are not designed for reading per se, but most will be good for online reading insofar as you can use them on websites and mobile devices. Display fonts are meant for standalone usage like headlines, advertisements, and logos. If you’re using a display font for headings on a website, you will want to make sure it renders well at smaller sizes so the usability of your website isn’t compromised on smartphone screens, for example. Display fonts with a lot of embellishment may lose their integrity on small screens.

You can use display fonts in any short-form or large-format application, such as billboards, posters, logos; headlines or headings in magazines or websites, and book covers. You should not really use display fonts for long-form text either in print or online, UX copy, or fine print. Display fonts are best thought of as complimentary, in that they work alongside other fonts within a type system to deliver emphasis, attract attention, and give your design some personality.

The character code is essentially an address that selects the character that you want to display. Every character has a unique character code one byte long. Understanding how this number maps with the font table is important.

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.

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.

I do want to encourage you. Ahh, this brings back so many happy memories of my childhod, learning to program. This was before the days of the internet of course, so practically everything had to be invented on the fly. One of the things I figured out how to do was handle tiny bitmapped fonts. Then I realised that, if I gave each character as much space as an M needed, then the "i" would look kind of lost in there. So I had to invent kerning, and how to implement it. It"s actually quite easy, so don"t let any people put you off.

You didn"t say what kind of format you want the font it, so I won"t go into that area. Firstly, choose a font. There"s a bunch of nice ones on DaFont.

Here I have drawn 8x8mm grey squares behind each character, just to show you the spacing. There"s no need to have them there really. Each character is left justified. Next, you write a program to import the image, and search through each 8x8 square to find the width of the character. This program converts each character into the binary format that most suits your application, and also stores the width of each character along with the data. When you come to render the characters on the LCD screen, you"ll be able to use the width data to position each character right next to the previous one (+1 pixel for a little space).

This kind of very basic kerning is really all you need when you"re working with fonts of this size. It"s certainly all you need for that particular font, where all of the characters are pretty square.

In fact, you"ll be hard pushed to even find a tiny font that needs real kerning. There were none on the first 14 pages of that DaFont link above. Finally, on page 15, I found the ISL Onyx font.

How to do real kerning on a tiny font? This time, when your program scans each character, it will need to measure the distance between the character and the left and right edges, for each row of pixels:

Graphical displays provide complete freedom to display whatever we want, so long as we provide a program for it. Currently we deal with 128x64 Pixel Displays and divide this area into ~5 Lines with ~22 columns. So we need monospace fonts with a bounding box of about 6x10. Until now we’ve been using a custom Marlin font similar to ISO10646-1 but with special symbols at the end, which made ‘ü’ and ‘ä’ inaccessible at 6x10 size.

The Japanese translator dealt with two scripts, introducing a special font for Graphical Displays and making use of the Japanese extended character displays. Thus he ended up with two pretty unreadable language.h files full of ‘\xxx’ definitions. Other languages either tried to avoid words that included special symbols or just used the basic symbols without the accents, dots… whatever.

On a full-featured desktop system like Windows or Linux we could install unifont.ttf and some library code and we’d be done. But embedded systems have very limited resources! So we must find ways to limit the space used (unifont.ttf alone is ~12MB!), requiring some compromise.

Make output functions that count the number of chars written and switch the font to Marlin symbols and back when needed. (ultralcd_impl_DOGM.h) (ultralcd_impl_HD44780.h)

Make three fonts to simulate the HD44780 charsets on dogm-displays. With these fonts the translator can check how the translation will look on character-based displays.

Make ISO fonts for Cyrillic and Katakana - because they don’t need a mapping table, are faster to deal with, and have a better charset than the HD44780 fonts. (Less compromise!)

Split ‘dogm_font_data_Marlin.h’ into separate fonts and delete. (+dogm_font_data_6x9_marlin.h, +dogm_font_data_Marlin_symbols.h, -dogm_font_data_Marlin.h)

Direct HD44780 Translation Symbols outside the normal ASCII-range (32-128) are written as “\xxx” and point directly into the font of the hardware declared in Configuration.h.

The mapper_tables do their best to find a similar symbol in the HD44780fonts (for example, replacing small letters with the matching capital letters). But they may fail to find a match and will output a ‘?’. There are combinations of language and display which simply have no corresponding symbols - like Cyrillic on a Japanese display or _vice-versa. In those cases the compiler will throw an error.

In short: Choose a mapper that works with the symbols you want to use. Use only symbols matching the mapper. On Full Graphic Displays all symbols should be fine. Using the graphical display, you can test for bad substitutions or question-marks that would appear on character displays by defining SIMULATE_ROMFONT and trying the different variants.

Mappers together with an ISO10646_* font are the second-best choice in terms of speed and memory consumption. Only a few more decisions are made per-character.

In this file specify the mapper (e.g., MAPPER_NON) and font (e.g., DISPLAY_CHARSET_ISO10646_1) and translate some of the strings defined in language_en.h. (Remove #ifndef #endif from the defines.)

Provide a bitmap font containing the symbols in the right size (5x9 to 6x10 recommended). Normal ASCII characters should occupy 1 to 127, and the upper 128 places should be populated with your special characters.

If you discover enough useful symbols in one of the HD44780 fonts you can provide a mapping table. For example WESTERN contains ‘alpha’, ‘beta’, ‘pi’, ‘Sigma’, ‘omega’ ‘My’ - which is not enough to make USEFUL table - I think.

The length of strings (for menu titles, edit labels, etc.) is limited. “17 characters” was a crude rule of thumb. Obviously 17 is too long for a 16x2 display. So, language files are free to check the LCD width and provide shorter strings in the following manner:

To find out which character set your hardware uses, set #define LCD_LANGUAGE test and compile Marlin. In the menu you’ll see two lines from the upper half of the character set: JAPANESE displays “バパヒビピフブプヘベペホボポマミ”

If you get an error message about “missing mappers” during compilation - lie about your display’s hardware font to see at least some garbage, or select another language.

LCD_LANGUAGE: The LCD language and encoding to compile in. For example, pt-br_utf8 specifies Portuguese (Brazil) in UTF-8 format with a mapper. For a faster, lighter, but non-accented translation you might choose pt-br instead.

SIMULATE_ROMFONT: Languages can opt to use the HD44780 ROM font special characters on graphical display. This method can be used for accented Western, Katakana, and Cyrillic if they don’t supply their own fonts, or just for testing character-based mappers on a graphical display.

DISPLAY_CHARSET_ISO10646_1: To support a graphical display, a language file must specify either SIMULATE_ROMFONT or a display character set. This specific option selects the Western font for use on graphical display. Others include ISO10646_5, ISO10646_KANA, ISO10646_GREEK, ISO10646_CN, ISO10646_TR, and ISO10646_PL. If no character set is specified, Marlin assumes ISO10646_1.

MAPPER_ONE_TO_ONE: Most character sets on graphical displays (including SIMULATE_ROMFONT) map the character index directly to its position in the upper half of the font. This is possible for character sets that have only 2 contiguous pages of Unicode containing all the special characters. Other mappers use logic or a lookup table to locate the glyph.

LCD stands for Liquid Crystal Display, the information display technology used in products such as digital watches and clocks. An appropriate choice when a futuristic, high-tech looking font is desired.

LCD is trademark of Esselte Letraset Ltd., 1990-1997, which may be registered in certain jurisdiction. All rights reserved. Portions: Copyright (c) Microsoft Corporation. All rights reserved.

The LCD BoosterPack Text example is an application that demonstrates the use of the Kentec QVGA BoosterPack to display text on an LCD screen with a variety of different styling configurations. The user has the ability to display a variable text message of their choice and change the font size, font color, text position, and background color. This code example leverages the MSP432 Graphics Library that is shipped with the SimpleLink MSP432 SDK.

The LCD BoosterPack Text code example requires the standard configuration of an MSP-EXP432P401R LaunchPad with an attached BOOSTXL-CC2650 BoosterPack. Additionally, a Kentec QVGA BoosterPack must be stacked on top of the CC2650 BoosterPack. This hardware configuration is shown in the below image:

Once the LCD BoosterPack Text code example starts, the LCD will turn to a black background with the text “Simplelink MSP432 SDK Bluetooth Plugin” displayed on the screen.

By default, this code example starts with BLE advertisement enabled indefinitely. Using your BLE client of choice, search for the “MSP432 LCD” device and connect:

The text string characteristic will change the value of the text that is displayed on the screen. From your client application, write any desired string value to this characteristic and the displayed text on the LCD will change:

The text color characteristic is a three byte value that controls the RGB value of the font display. The byte order is in the format of BB GG RR. For example, writing a value of 0000FF to the characteristic would change the text color to full red.

The X Position characteristic is the position of the beginning of the text string starting from the left side of the screen. The position is limited by the X resolution of the LCD screen (320) and a value from 0 to 320 can be used. A value of 160 will roughly put the text in the horizontal center of the screen.

The Y Position characteristic is the position of the top of the text starting from the top side of the screen. This value is limited by the Y resolution of the LCD screen (240) and a value from 0 to 240 can be used. A value of 120 will roughly put the text in the vertical center of the screen.

The text size characteristic changes the font size of the text on the screen. This code example has a total of eighteen different fonts (0 being the smallest, 17 being the largest). Changing the value of this characteristic will change the font size of the displayed string:

The last characteristic controls the background color of the LCD. The format of this characteristic is identical to the format of the text color characteristic (six byte BB GG RR value). Write to this value to change the background color:

Updating the firmware on the CC2650 BoosterPack uses the SBL libraries to invoke the CC2650’s bootloader and transfer the new firmware over serial. For LCD BoosterPack Text, the method to trigger this invocation is to hold down both S1 and S2 buttons on the LaunchPad for a duration of at least three seconds. Note that in order to trigger the firmware update, no active BLE device can be connected. Once S1 and S2 are held down for two seconds, LED2 on the LaunchPad will toggle bright blue to signal the BSL start: