Overview
Embedded Linux has the characteristics of stable, expandability, and open original program code, compatible with multiple processors and hosts, widely used in various products and applications. However, cross-compilation, equipment driver development / extent, and smaller sizes require a serious challenge to embedded Linux developers. To address these challenges, dedicated tools developed by embedded Linux have emerged, and the development is very rapid.
However, many of these development tools are not compatible with non-X86 platforms, but also do not have a good archive file or integration. In other development environments, the high integration between components is not fully fulfilled. Therefore, you want to create a complete cross-platform development environment completely from these free software components, developers should realize that this will require a lot of investigations, implementation, training and maintenance.
Linux is a minority that can be performed on an embedded device or one of an operating system for the development environment. This feature allows developers to develop, degssion, and test applications and libraries on common hardware (such as X86 desktop systems) prior to the development system, thus reducing dependence on standard reference platforms and instruction sets. This technology is only available for applications and libraries, but it does not apply to device drivers because the latter is based on the Linux architecture.
Open Original Program Code Groups and Some Software Suppliers offer equipment driver development tools. Since the device driver is closer to the hardware than the standard application, their development is more difficult. Fortunately, the Linux desktop system can take advantage of some of the tools that Windows and other operating systems. Developers with sufficient experience to develop equipment drivers may have become accustomed to using Linux development systems.
The rapid development of Linux and the continuous emergence of its desktop programs have highlighted an important issue: How should the tool scheme do to execute on different Linux distributed systems? Do they depend on the software configuration of the host platform?
Some Linux tools provide an development environment that is independent of the host platform, including a range of applications, libraries, and utilities that support development tools. This approach almost completely separated the development environment with the host configuration, so the host can be any Linux distributed system, and any updates and modifications do not affect the development environment.
The main disadvantage of this method is to increase the requirements of storage space - about 200MB because it is actually equivalent to a mini Linux distributed system.
Available tools
Development of an embedded Linux product requires several phases, including configuring and constructing basic Linux OS; unligrated applications, libraries, core and device drivers / core modules; the best, testing, test, test And verification.
There are hundreds of open original program code development tools available. As long as the developer costs time and energy to investigate, implement and maintain a series of different tools, always find a complete solution to complete almost any development task.
figure 1
Developers must accurately take into account what functions that can provide a loose collection of these tools, and how much effort can be required to form a complete solution. "
In the LINUX application and the library, GNU Debugger (GDB) has a history of several years. It is a command line program that supports the front end of multiple different graphical user interfaces, each with a variety of ways to provide a defect control function. Although GDB is not a perfect solution, it is enough to respond to various defect missions and have been widely supported by the open original program code group.
The ligation of the Linux core or device driver is much more cumbersome than the application of the application.
In the case of surveys, the following aspects should pay special attention: What is the hardware to develop products? What core support program is needed? What other support procedures still need? How to use the error interface, how to use it? Does the tool need to deactivate the core module and handle virtual address conversion? What tools still need to provide a complete solution?
After further investigation, developers often discover tool A and tool B do not provide a fully consistent feature because they are developed independently of each other. As a result, developers must accurately take into account what functions that can provide the loose collection of these tools, and how much effort can also be made to form a complete solution. If the integration, availability, interoperability, and transplantability between different processor types are critical, developers should consider buying commercial development tools. This is mainly because it will develop a 'Free' program to consider it, and commercial development tools are not expensive.
Linux BSP
Linux systems have two major part: Linux core with device drivers; and root file systems, all support applications, services and libraries required for systems.
In addition to the OS components that reside on the target board, it is also necessary to make a cross-compilation environment consisting of GNU Compiler Collection, providing support for library and binary rules (binutils).
Although almost every component can be found online, it is difficult to collect too much information in hardware or device driver support, integrating test information, cross-compilation guide, or software compatibility. Although developers can download a variety of components from the Internet to configure embedded Linux operating systems, each component is required in the version, support, stability, and testing states. The developer needs to decide. Then, developers have to complete the last OS integration and testing, and provide lifetime Linux OS maintenance for the developed products.
On the other hand, the commercial Linux board support kits provided by embedded Linux suppliers are generally pre-installed and tested and supported and maintained. Other considerations include Linux desktop hosts will add different libraries and core functions, as well as long-term maintenance issues caused by developers in the organization.
The quality assurance department generally performs a series of strict verification and performance tests, including memory leak detection / correction, program code optimization and task tracking. Those who want to use open original program tools to develop embedded Linux product developers who are non-x86 platforms will find that this task is even more than choosing to open the original program code. Linux Trace Toolkit, Valgrind tools, and other memory analysis programs can complete partial testing and verification tasks. But in general, they lack key features, integrated functions and extensive hardware support. These open original program code analytics tools are basically the same as assessing the defective scheme.
The final analysis is that a developing environment designed to be able to supply commercial and open original program code two worlds have the best features: * Complete development capabilities; * Easy to use and integrate; * Coordination of large engineering organizations Control; * Quality and support guarantee; * continuity; * The ability to open the original program code according to your own judgment.
Author: David Beal, director of Embedded Linux Email: dbeal@metrowerks.com Metrowerks Company
