ucos-II GUI.pdf-资料库

第1页 / 共15页

第2页 / 共15页

第3页 / 共15页

第4页 / 共15页

第5页 / 共15页

第6页 / 共15页

第7页 / 共15页

第8页 / 共15页

Micriµm, Inc. Using a GUI in an Embedded System Application Note AN-5000 Christian E. Legare Christian.Legare@Micrium.com Jean J. Labrosse Jean.Labrosse@Micrium.com www.Micrium.com

Introduction 1.00 Introducing a new product requires the designer to think about the product differentiators. Designing a user-friendly product, considering all other features are equivalent, will help increase the product acceptance and sales. A good User Interface is definitively one of these differentiators. In many instances, a Graphical User Interface (GUI) is the best approach. For examples, consider these popular products: Industrial Controls • Cell phones • Digital Cameras • • GPS Instrumentation • Military / F.L.I.R. Applications • • Wireless Devices Internet Appliances • Copiers • MP3 Players • Medical Devices • Handheld Computers • Printers • Set-top Boxes • Web Browsers Other hardware issues are the choice of LCD displays and LCD controllers. A good combination of display and controller will reduce the load on the CPU and ROM/RAM and at the same time provide a high quality GUI. Also, products can be designed using either ‘Black and White’ (B&W), ‘Gray Scales’ (GS) or ‘Color’ displays. Any product requires some form of feedback from the user. When a GUI is used, the user feedback is reflected on the display. An embedded GUI needs to support one of the following input devices: Users expect a product with a graphical display that looks familiar – similar to the de facto standard Microsoft Windows Graphical User Interface, as well as color displays because the information content is higher. As a developer, you quickly realize that these expectations have a strong impact on the cost of the product. In addition, you might want to make your product as universal as possible by adding multi-lingual support – mix Latin, Cyrillic, Han, Katakana, Hiragana etc. in a single application with JIS and UNICODE formats. The language support on the display also has a high toll on an embedded system. Character sets are generally stored in memory. Embedded systems often have scarce memory resources. The use of a GUI will allow you to use very large character sets in memory-limited systems. An embedded system has limitations that a PC desktop does not have. These limitations are often in conflict with the user expectations of a “Windows like” interface, because this type of interface is resource hungry. The two major constrains that a designer has to work with when considering implementing a GUI are: a. Code space (ROM) / Data space (RAM) Requirements: Most embedded systems have low ROM/RAM. High performance combined with low resource usage has always been a major design consideration. Depending on which modules are being used, even single-chip systems with less than 64Kb ROM and 2Kb RAM (Yes K , this is not a typo) can be supported by an embedded GUI. The actual performance and resource usage depends on many factors (CPU, compiler, memory model, optimization, configuration, interface to LCD controller, etc.). b. Low CPU overhead: Most of the drawing is done by the embedded CPU which does not run as fast as current desktop computers. One is lucky if he can have a 32-bit CPU running at 100 MHz, 20 to 100 times slower than desktops. In fact, embedded GUIs should run on 8/16/32-bit CPUs.

Input device A keyboard with limited number of keys Soft Keys supports "membrane keys" placed GUI support A Touch screen or light pen A tracking device (mouse, track pad, joystick, track ball or track point, etc...) around the perimeter of the display screen The GUI will provide assistance by interacting directly with input hardware, maximizing throughput. In this case the GUI will help by providing support for software cursors. Table 1 – Input devices

2.00 How do you select a GUI? When designing a product with a GUI, you may be tempted to write your own from scratch. This is generally a mistake because of the time involved. C++ is becoming more and more popular as embedded CPU resources increase, but C++ has not established itself yet, as the language of choice in the embedded world. C is still the predominant language used in embedded systems. Companies are working towards code re-use and are thus protecting their investment. An embedded GUI needs to be portable to different processors. A designer would like to find a library that conforms to the C standard and that is highly portable by abstracting all hardware-dependent functionality. A library strictly following the ANSI C Standard would assure this portability. It's unusual for a desktop GUI to be provided in source form. For an embedded system, it's almost mandatory since it protects the end user from the GUI provider. It's not sufficient to provide source code - the code must be clean, consistent and well documented. Over 50% of the embedded systems designed today have some sort of real-time operating system, whether commercial or designed in-house. The GUI must be designed to work with just about any of them while at the same time allow multiple tasks to access the display as needed. For the other 50%, the GUI should also be able to run in standalone mode - the entire application running in one big loop. Interrupts must be used for real time parts of the software since no real time kernel is used. The architecture of an embedded GUI can be represented by the diagram of Figure 1. The selection of your GUI must be based on the availability of each modules and the quality of their implementation.

Embedded System Your product application Tools Changing the behavior of your product Input devices •Touch screen •Mouse •Touch pad •Keyboard •Buttonsa Software Optional Modules Hardware Window Manager Widgets/Dialogs Memory devices Basic GUI Antialiasing LCD Driver Bitmaps Fonts Resources Bitmap Converter Font Converter LCD Controller LCD Any resolution Black & White Gray scale Color Figure 1 – Embedded System The examples in the following sections are taken from µC/GUI, a commercial portable embedded Graphical User Interface software package.

3.00 Window Management Support? One decision that has a major influence on your GUI implementation is the choice to use or not a Window Management module. The selection criteria can be summarized as: • User interface look and feel. • Code and data space requirement • Complexity or simplicity 1. Because your user is expecting a look and feel he is familiar with, you may want to provide him with the versatility of a Window Management module. 2. If you choose to include a Window Management module, you have to be ready to pay the price in memory space required. Using windows, widgets (controls) and dialogs requires more resources. A typical example with µC/GUI: Without Window Manager: • RAM: 100 bytes • Stack: 500 bytes • ROM: 10-25 KB (depending on the functionality used) With Window Manager, widgets (controls) and dialogs: • RAM: 2KB and more as you add windows (typically 6KB) • Stack: 1.2KB • ROM: 30KB and more depending on the number of windows and different widgets used. Note that ROM requirements will increase if your application also uses many fonts. 3. You would use a Window management module as soon as you application gets more complex, for example displaying alarms on top of other information and having to redraw the display. As a last note, the use of a Window Management module generally does not have a significant impact on the CPU load.

3.01 Without Window Management If you cannot afford the extra resources needed by windowing, the GUI still need to offer a minimum set of functions to provide an embellished product such as: • Text and Number display • Multiple fonts • Lines, polygons, arcs, circles, ellipses • Boxes In µC/GUI, some of Text and Number display 3.01.01 Only a few routines are required to allow you to write any text, using any available font, at any location on these routines are GUI_DispChar(), GUI_DispString(), the display. GUI_DispStringAt() and GUI_GotoXY(). Instead of using standard C library functions, embedded GUIs generally come with more efficient built-in functions to display values anywhere on the screen. In addition, most of these display functions do not require the use of time consuming floating-point library and are thus optimized for both speed and size. 3.01.02 Multiple fonts An embedded GUI generally only needs to support a few fonts. Because memory is scarce in an embedded system, these fonts are usually coded as bitmaps. The fonts are stored in either C files, object files or libraries. The font files are linked with your application but the font declarations are contained in header files. In general, 2 types of fonts are required: monospaced bitmap fonts and proportional bitmap fonts. In high- end system, you will also find proportional bitmap fonts with antialiasing (described later) information. To be as universal as possible the GUI should support ASCII, ISO 8859-1 and Unicode. It is generally recommended to compile all available fonts and link them as library modules or putting all of the font object files in a library which you can link with your application. This gives the opportunity to the linker to keep only the fonts which are needed by your application. 3.01.03 As a minimum, your GUI library needs to include 2-D graphic routines to draw points, lines, polygons, arcs, circles and ellipses which should be sufficient for a lot of applications. Since these routines are called frequently in most applications, they must be optimized for speed. For example, the horizontal and vertical line functions do not require the use of single-dot routines. 3.01.04 Bitmaps are important in any GUI application. Everybody wants to have its logo on the display. For example, bitmaps which can be used with µC/GUI are normally defined as GUI_BITMAP structures in C. The structures -- or rather the picture data which is referenced by these structures -- can be quite large. For images that you plan to re-use (i.e. a company logo) it is very efficient to define them as GUI_BITMAP structures that can be used directly. Lines, Polygons, Arcs, Circles, Ellipses Bitmaps

On the other hand, for application that continuously references new images, such as bitmaps downloaded by the user, the GUI should also provide a mean to download and display these images. µC/GUI provides two functions for these situations: • For bitmaps defined at compile time: • For bitmaps downloaded at run time: GUI_DrawBitmap() GUI_BmpDraw() It is time-consuming and inefficient to generate these bitmaps manually, especially if you are dealing with sizable images and multiple shades of gray or colors. For this reason, µC/GUI comes with a Bitmap Converter. The µC/GUI Bitmap Converter can convert any bitmap into C. It supports palette conversion for different LCDs. For efficiency, bitmaps may also be saved without palette data and in compressed form. Figure 2 – Bitmap Converter example 3.02 To Window Window management is generally built using some of the functionality described in the previous section. 3.02.01 Window Manager A minimum Window Management option should include a set of routines which allow you to easily create, move, resize, and otherwise manipulate any number of windows. The GUI should also provide lower-level support by managing the layering of windows on the display and by alerting your application to display changes that affect its windows. 3.02.02 Widgets Widgets are windows with object-type properties; they are called controls in the Microsoft Windows world and make up the elements of the user interface. They can react automatically to certain events; for example, a button can appear in a different state if it is pressed. Widgets need to be created, have properties which may be changed at any time during their existence and are then typically deleted when they are no longer needed. Once a widget is created, it is treated just like any other window; the Window Manager module ensures that it is properly displayed (and redrawn) whenever necessary. Widgets are not required when writing an application or a user interface, but they can make programming much easier. Below are examples of some of the widgets supported by µC/GUI.

资料库

ucos-II GUI.pdf

相关推荐

最新资料