Integration of Linux Graphics Component in an Intelligent Device
Total Page：16
File Type：pdf, Size：1020Kb
Integration of Linux Graphics Component in an Intelligent Device Magnus Erkenfelt M˚ansZigher Lund Institute of Technology Lund University November 9, 2007 ii Abstract In this thesis, a Linux graphics system is proposed, implemented, and dis- cussed. The most common graphics manager of Linux is called the X Server. It uses a server architecture that is not optimal when working with embedded systems, due to its memory footprint and unnecessary power consumption. The idea was to design the architecture so that the graphics system is a component of the operating system and fits into a simple C library. A direct interaction with the graphics hardware is configured and implemented on the system. The thesis introduces the concept of a graphics device called frame buffer as used to communicate with the hardware. It also describes the different modules needed to build a complete embedded Linux system. Using the pro- posed implementation, a fully operational system with a memory footprint under 5 MB can be achieved. iii iv Acknowledgements First of all, our thanks go to Mikrodidakt AB for giving us the opportunity to work on this thesis, especially to our supervisor P¨arL¨ofgrenwho always pushed us in the right direction. Also thanks to Pierre Nugues for ideas and support, and Jens Hellstr¨omfor his Linux expertise. v vi Contents 1 Introduction 1 1.1 The product . 1 1.2 Purpose of Thesis . 4 1.3 Problem Formulation . 4 1.4 Thesis Overview . 5 2 Background 7 2.1 Linux . 7 2.2 The Linux Kernel . 9 2.3 The Linux File System . 11 2.4 Libraries . 13 2.5 Linux Devices . 15 2.6 Linux Device Drivers . 15 2.7 Operational Environment . 16 2.8 The Bootloader . 18 2.9 Cross Compilation . 20 3 Embedded Graphics 23 3.1 The Graphics System . 23 3.2 The Linux Frame Buffer . 28 4 Hardware 31 vii 4.1 The ARM processor . 32 4.2 The 8051 processor . 33 4.3 LCD . 34 4.4 Touchscreen . 35 4.5 Memory Mapping . 36 5 System Setup 39 5.1 Cross Compilation Environment . 39 5.2 Network File System . 40 5.3 The Universal Bootloader . 42 5.4 Kernel Considerations . 43 5.5 Configuring Busybox . 46 6 Graphics Component 49 6.1 Initializing the Frame Buffer . 50 6.2 Pixel Rendering . 52 6.3 Shapes . 55 6.4 Interface Components . 56 6.5 Event Handling . 60 7 Evaluation 63 7.1 Size Comparison . 63 7.2 Cost Comparison . 65 7.3 Development and Testing . 66 7.4 Limitations . 66 8 Result & Discussion 67 8.1 Implementation Discussion . 67 8.2 Further Development . 67 Appendix 69 viii A Generic Frame Buffer Driver 71 B Busybox Defined Functions 77 C Linux File System 79 D Processor 81 E Memory Management 85 F Memory Footprint 89 F.1 Kernel . 89 F.2 Dynamic libraries . 89 F.3 Static libraries . 91 F.4 Smaller Footprint . 93 F.5 Conclusion . 94 G Abbreviations 95 ix x List of Figures 1.1 Mandometer unit and scale. 2 1.2 Graphical user interface of the Mandometer. 3 2.1 Architecture of a monolithic kernel. 11 2.2 The placement of Busybox in a software architecture. 17 2.3 The bootloader start-up sequence. 19 3.1 The different layers in a graphics system architecture. 24 3.2 The interaction between Xserver and its clients. 25 3.3 The different layers in the X toolkit architecture. 26 3.4 The Embedded Linux graphics system architecture. 29 4.1 Atmel eveluation board AT91SAM9261. 31 4.2 AT91SAM9261 Memory mapping. 36 5.1 The development system set up. 42 5.2 Ncurses-based kernel configuration. 44 5.3 QT-based kernel configuration. 45 6.1 Basic overview of the graphics handling. 49 6.2 Basic overview of the graphics handling. 56 6.3 Basic overview of the graphics handling. 59 6.4 Event handling flowchart. 61 xi D.1 The state in a stored-program digital computer. 81 D.2 von Neumann and Harvard architecture computers. 83 E.1 The cache in the memory system. 85 E.2 A virtually addressed memory system. 87 xii List of Tables 2.1 Different open source bootloaders for Linux. 20 3.1 Different RGB formats. 28 4.1 The Hardware . 32 7.1 Different graphics packages for embedded Linux. 64 7.2 A price list of the OS On Time RTOS-32. 65 F.1 The kernel size. 89 F.2 The file system with dynamic libraries. 90 F.3 The filesystem with static libraries. 92 F.4 The kernel size. 93 xiii xiv Chapter 1 Introduction 1.1 The product Mikrodidakt AB together with AB Mando has developed a device that can help people with eating disorders, e.g. anorexia and bulimia. The device is called Mandometer. A person with an eating disorder has an unhealthy relationship towards food. This is where the Mandometer might be able to help them. The patient is taught to eat right using the Mandometer. The device mainly consists of a computer and a scale, which communicate with each other. Figure 1.1 shows a picture of the Mandometer. The Mandometer system shows the rate at which the patient is eating and also the rate at which the patient should be eating. In addition, it displays the patients level of satiety, and compares that to normal levels. After a meal, the patients are placed in a warm room, this is to avoid panic attacks and anxiety. Patients like the warmth and often fall asleep during this period, thus keeping them from vomiting. Apart from the computer and the scale, the Mandometer is made up of an LCD display, an embedded MP3 player, and a USB connection. Through the LCD display, a graphical user interface (GUI) is displayed to communicate with the user. GUI pictures are shown in figure 1.2. The USB connection is used to connect the scale to the system, and to connect the Mandometer to a 1 1. Introduction Figure 1.1: Mandometer unit and scale. treatment terminal. Through the treatment terminal, results from meals can be stored in a database and a personalized treatment plan can be configured, and downloaded to the Mandometer. A case manager can view the result to see if the patient is improving or not. Depending on the results, a new treatment plan, or adjustments, can be made to suit the patient, and the patient's progress. In Figure 1.2, the first picture is the login window. The patient has to log in before each meal. After the login, the patient has to select a meal. This window is shown in the second picture. An empty plate is placed on the scale before each meal, so the Mandometer can run a scale calibration. After the calibration, the Mandometer asks the patient to put food on the plate. Depending on the chosen meal, a specific amount has to be placed on the plate before the meal can start. When the food portion is approved, the Mandometer asks the patient for which level of satiety s/he is feeling, shown in the third picture. During a meal the Mandometer will ask questions about how satiated the patient feels, and plot the response on a graph. The graph will display how the patient should eat in relation to how s/he is eating. If the patient is eating too fast or too slow, the Mandometer notifies the user with both text and sound. The graph window is shown in the fourth and 2 1.1 The product last picture in Figure 1.2. Figure 1.2: Graphical user interface of the Mandometer. The Mandometer software is coded in C language (flavor of Keil C51) and built using the µV ision development environment (Keil). There is no operating system or execution kernel involved. Instead execution is per- formed in simple computational loops. The executional structure consists of an initialization, the main loop, the mode loop, and interrupt routines. The initialization routine handles the initialization of the LCD controller, touch controller, the memory system, and the interrupts. The main loop distributes CPU time to several activities (tasks). This is done by con- tinuously performing each task. The mode loop selects one current task to receive CPU time depending on the current mode of the Mandometer. Possible modes are: 1. Logon 2. Mode selection - depending on log on identity. 3. Song - play MP3 files. 4. Meal - prepare meal, display while eating, and store when finished. 5. Meal history - show previously stored meals. 3 1. Introduction The interrupt routines are handling interrupts from the serial port, USB, audio, touch, and incrementation of timer. AB Mando has opened up Mandometer Clinics in Stockholm, Amster- dam, and San Diego, and is planning to open one in Sydney. According to results from these clinics, the success rate lies around 75% and has a 10% relapse rate. 1.2 Purpose of Thesis Mikrodidakt AB is a small company in the southern part of Sweden, and they have been developing embedded systems since 1980. During the years they have noticed that the cost of developing an embedded system has shifted from the hardware to the software. Software such as compilers, operating systems, and advanced debugging tools can each cost thousands of Euros. When developing embedded systems, it is common to design the device for one single purpose, e.g. a MP3 player, calculator, or a digital camera. Even though the different devices have different purposes, they can all use the same platform where the main difference actually is the GUI. The purpose of this thesis is to create a development platform with high versatility and a small memory footprint.