Displays

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.

Display sizes

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.

Physical display

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

Compilers

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 sales@ibissolutions.com. There is an overwhelming probability that it will function just fine with easyGUI.
Back to top



Micro controllers

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

Display drivers

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.

Display buffer

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.

Back to top