Fonts in easyGUI
All 3 versions of our easyGUI packages come included with 18 different sizes, and styles of fonts. This makes easyGUI a fast tool to work with, even though you can develop your own fonts if you wish, here you have your basic staple of very usable fonts to choose from.
Font name/Size in pixels
ANSI 2 6×11
ANSI 2 bold 7×11
ANSI 2 condensed 5×11
ANSI 3 condensed 6×17
ANSI 4 7×12
ANSI 5 9×17
ANSI 5 condensed 8×17
ANSI 6 11×21
ANSI 7 17×31
ANSI 8 21×47
Unicode 14×14 16×18
Unicode 15×15 17×19
Unicode 16×16 18×20
Icon 16×16 16×16
Icon 32×32 32×32
Icon 48×48 48×48
Icon 72×72 72×72
Icon 202×48 202×48
easyGUI also has a font import function. Font creation is a difficult art to master. When importing Windows fonts into easyGUI (or other systems targeted at the embedded world) they must be converted from vector graphics to raster graphics. This process involves a number of pitfalls.
Some good advice to follow when importing vector fonts in easyGUI are mentioned in the easyGUI manual, TTF Import chapter. Import into an easyGUI font with plenty of space, it can later be trimmed down to the desired size. Furthermore, start by importing a subset of characters, in order to quickly get the settings correct. After an acceptable import has been accomplished for all desired characters it is time to move the characters into place (if needed), set PS marks, adjust minor imperfections, and so on. Observe that these operations can be made en bloc, on multiple characters at once.
Please observe that not all Windows vector fonts are usable for rasterization, especially in the smaller sizes. Windows faces the same problem, as any character written on a PC display must be reduced from vector format to raster format. Better Windows fonts add special raster corrections to the font when size go below approximately 12 point. The Windows character writing functionality is thus very complicated, and far beyond the possibilities in most embedded systems.
If you are in need of a different font or a specialty font, you can also order any font you wish from us. We will make it for you as a special order. Please contact us for more information.
Back to top
easyGUI supports any display / display controller combination which is graphical in nature, i.e. pixel based. The pixels must be individually addressable. All displays labeled “graphical display” falls under these rules. easyGUI doesn’t care about the display type, it can be LCD, vacuum fluorescent, plasma, OLED, etc. Custom made displays with segments, icons, etc. made specially for a specific project cannot be handled by easyGUI.
easyGUI distinguished between three main types of displays: Monochrome, grayscale and color. The following types are supported:
Monochrome mode with 1 bit/pixel. Pixels are either on or off.
Grayscale with 2, 4, 5 and 8 bits/pixel, i.e. 4, 16, 32 and 256 levels of gray.
Color via palette index with 4 and 8 bits entries, i.e. 16 and 256 colors. Each color value can be up to 24 bits in size.
Direct RGB color with 8, 12, 15, 16, 18 and 24 bits/pixel, i.e. 256, 4096, 32K, 64K, 262K and 16M colors.
Monochrome displays are supported by easyGUI Monochrome. For the other higher modes easyGUI Color is needed. easyGUI Unicode is equivalent to easyGUI Color in this regard.
easyGUI is configurable to any display size in pixels – there are no formal limits in easyGUI. Any aspect ratio (ratio between display width and height) is allowed. Any odd numbers for display dimensions are allowed.
If your preferred physical display mounting differs from the anticipated mounting by the display vendor, i.e. upside down, or rotated 90°, easyGUI helps you by allowing any of the four primary orientations to be selected. The easyGUI editing environment then adapts to the new display dimensions. No action is necessary in the target system code, as alternative display orientations are handled 100% transparent to the programmer.
The physical display size is irrelevant to easyGUI.
Back to top
We guarantee that easyGUI can be used with all sorts of µ-processors, provided that their C compiler is ANSI X3.159-1989 Standard C compliant. Unfortunately it is only a minority of embedded C compilers that can be said to be 100% ANSI compatible. easyGUI therefore contain flags which can be set for a number of non-compliant compilers, in order to handle their more or less non-standard behavior. All easyGUI functionality is unaffected by these settings.
easyGUI use only standard C code in its library, no C++ is used. It is however perfectly possible to use easyGUI in C++ projects. Our own PC simulator kits are examples of C++ projects.
The processor must of course have sufficient power to run the display in graphical mode, which is somewhat more demanding than the traditional old style alphanumeric modes.
One example is the AVR compiler used by many easyGUI customers. It is not strictly conforming to the ANSI standard, so a special “AVR” flag is thus present in the easyGUI setup section.
Texas TMS320 family controllers without support for 8 bit data types can still be used with easyGUI, but they will use a little more memory than normally.
The Metrowerks Code Warrior compiler is currently not supported, because of its very non-standard use of FAR data support.
Supported ANCI C Compilers
IAR, GNU-GCC, AVR Codevision C, Green Hills C, ARM RVDS / ADS, Keil C, ImageCraft ANSI C, Introl C, AVR CDK4AVR, VectorC, Metrowerks C/C++, ZDS II eZ80Acclaim, CodeWarrior Development Studio, Microtec C/C++, Mentor Graphics EDGE C/C++ , Borland C/C++, HighTec GCC, Blackbird HPEC, Microcross GCC, Cosmic ANSI C, WinAVR GCC, HI-TECH C, Algorithmics GCC, Tasking C/C++, Microware C, R-Stream ANSI C, Metaware High C/C++, NEC C, Intel C/C++, Wind Riwer Systems / Diab Data Compilers …
The above can never be a complete list, because of the dynamic behavior of the market. If your compiler is not listed you are advised to contact us at firstname.lastname@example.org. There is an overwhelming probability that it will function just fine with easyGUI.
Back to top
easyGUI can be used with all sorts of microcontrollers, provided that their C compiler is ANSI X3.159-1989 Standard C compliant.
easyGUI only uses standard C code in its library, no C++ is used.
The controller must of course have sufficient power to run the display in graphical mode, which is somewhat more demanding than old style alphanumeric modes.
easyGUI can be used with all operating systems / kernels, or without any, if desired.
easyGUI supports the following major microcontrollers:
Atmel ARM, AVR, Intel X86, X196, X296, X386, PENTIUM, I960-SERIES, XSCALE, Hitachi H8, H8/300, H8/300H, H8/500, H8S, SH, Infineon C166, TRICORE, XC800, STM ST10, MMDSP, Motorola 68K, COLDFIRE, M-CORE, POWERPC, NEC V20, V25, V25+, V30, V8XX, Philips XA, Zilog eZ80, MIPS, Freescale 56XXX, ETPU, SPARC, SPARCLITE, Renesas M32, SUPERH, STARCORE, Misubishi MELPS7700, Altera NIOS-II, PIC, Texas C5500, C6000, LSI ZSP 400, ZSP 500, Analog BLACKFIN, Ceva CEVA-X, OAK, TEAK, TEAKLITE, National 32000, Xilinx MICROBLAZE, and many more.
The above is only a selection of microcontrollers. It’s our experience that the microcontroller type seldom causes any compatibility problems.
The main issue is, that among other things easyGUI provides you with a full graphical user interface, which requires a relatively fast microcontroller.
We recommend that you use a microcontroller with a performance of at least 10 MIPS. If the performance is lower the display should be modest in size, and monochrome, or the demands for display refresh should be low.
Back to top
An easyGUI display driver consists of only two simple c functions, initialization and data transfer. It can easily be adapted to the hardware in question, meaning that the display hardware can use any connection method (bus, ports, I²C, SPI, etc.) supported by the display controller.
The initialization part of the display driver is not really easyGUI relevant, but merely sets up the display hardware for the required display mode, transfer method, etc., and make an initial clearing of the display. Display contrast control (if required), back lighting and other secondary tasks can also conveniently be placed here. Only drivers for palette based color modes contain easyGUI specific code in the initialization part, as the preferred palette must be transferred to the display controller.
The data transfer part of the display driver moves display data from the internal display buffer to the display controller RAM memory. Data transfer is intelligent, i.e. only necessary data is transferred, that is data changed since last data transfer. This ensures minimal data traffic to the (potentially slower) display controller.
Both the initialization and data transfer parts of the display driver are plain C functions of limited size, which can freely be modified to suit specific demands of the target system hardware. The driver system is thus very flexible and easy to maintain.
We will assist you in the initial task of getting the display driver up and running, if you should encounter problems with our driver.
Many display controllers support multiple setups regarding color depth, color mode, display orientation, etc. As the easyGUI display driver is so simple it is a trivial task to adapt it to the preferred display mode. Furthermore easyGUI can be set up to almost any color depth / mode currently found in display controllers.
Some easyGUI display drivers support more than one type of display controller. This is because a particular display controller architecture is often found in many incarnations, with different manufacturer names and product codes.
Microprocessors with build in display controllers, like e.g. some ARM controllers, are handled just like stand-alone display controllers.
As standard easyGUI uses an intermediate display buffer in ordinary RAM. The display image is created in the buffer by the easyGUI library, and then transferred to the display controller memory, using the method programmed in the display driver. It is however possible to bypass this internal display buffer if the display controller buffer is directly mapped into the microcontroller memory space. As the easyGUI internal display buffer is organized exactly as the display controller RAM it is possible to let the easyGUI library write directly into display controller RAM. The display driver update task is then left empty, as there is no longer any data to transfer from internal buffer to display controller buffer.
The reason for the intermediate buffer in easyGUI is two-fold. Both reasons are rooted in the fact that an easyGUI structure (collection of items to display) can consist of many parts, which more or less overlap, e.g. a box containing texts and other components. In fact, this is often the case. The reasons are:
Many display controllers are very slow to write to, either because of the display controller itself, or because of the way it is hooked to the micro controller (like e.g. port access). So, to speed up the system, the minimum amount of actual display writing is sought.
Writing overlapping parts directly to the display controller RAM will result in flickering, because partial display images will be visible (albeit for very short times).
The first reason is not that relevant with the newer color based, relatively high resolution, display controllers, which are far more efficient in moving around display data than older designs. The second reason is less important, if the speed of the embedded system is high.
Supported Display controllers
Right now easyGUI is compatible with most display controllers in production currently or in the past. We are continuously adding drivers to the system.
Many display controllers are marketed with multiple names and codes, so while it might not be listed below, we might still support it. Drivers for other display controllers can be delivered on request, please see our web shop, or contact us for more information.
List of controllers currently supported by easyGUI:
AT32AP7000, AT91RM9200, AT91SAM9261, AT91SAM9263
AX6108/AX6107, AX6120, AX6963
HX8312, HX8345, HX8346, HX8347, HX8347G, HX8352A
KS0108B/KS0107B, KS0708/KS0707, KS0713, KS0715, KS0717, KS0718, KS0719, KS0723, KS0724, KS0728, KS0741, KS0755, KS0759
LH155BA, LH75400, LH75401, LH75410, LH75411, LH7A400
LPC1787, LPC2478, LPC3230, LPC3250, LPC408X
NJU6450, NJU6450A, NJU6452, NJU6570, NJU6575, NJU6673, NJU6675, NJU6676, NJU6677, NJU6678, NJU6679
NT7501, NT7502, NT7508, NT7532, NT7534, NT75451
R61505, R61509, R61526
RA8803, RA8822, RA8835, RA8875
S1D10605, S1D10606, S1D10607, S1D10608, S1D10609, S1D13305, S1D13505, S1D13506, S1D13700, S1D13704, S1D13705, S1D13706, S1D13715, S1D13742, S1D13743, S1D13748, S1D13781, S1D13A04, S1D13A05
S1D15600, S1D15601, S1D15602, S1D15605, S1D15705, S1D15707, S1D15708, S1D15710, S1D15721
S6B0708/S6B0707, S6B0713, S6B0715, S6B0716, S6B0717, S6B0718, S6B0719, S6B0721, S6B0723, S6B0724, S6B0725, S6B0728, S6B0741, S6B0755, S6B0759
SED1335, SED1374, SED1375
SED1520, SED1530, SED1565
SSD1303, SSD1305, SSD1322, SSD1325, SSD1339
SSD1805, SSD1815, SSD1848, SSD1852, SSD1857, SSD1858, SSD1859
SSD1905, SSD1906, SSD1926, SSD1963
ST7529, ST7541, ST7561, ST7565, ST7565S, ST7567, ST7571, ST7586
UC1601, UC1606, UC1608, UC1610, UC1611, UC1611S, UC1617, UC1698