Embedded system and how to construct an Embedded System

Article Title: embedded system and how to construct an embedded system. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Most Linux systems run on PC platforms, but Linux can also work reliably in embedded systems. This paper describes the overview of embedded systems and demonstrates the application of Linux to commercial embedded systems.
　　
Embedded Systems-older than Moses
Computers used to control devices, or embedded systems, appear around us almost as early as computers themselves.
　　
In the field of communication, these embedded systems were used to control the electronic mechanical exchange of telephones as early as 1960s and were called the "storage program-controlled" system "Computer" word which was not common at that time; the so-called storage program refers to the memory with program and route information. Storing these control logics instead of using hardware is a real breakthrough in concept. Today, we have taken this mechanism for granted.
　　
To adapt to every application, these computers are customized (in short, these computers are application-oriented ). according to today's standards, they have strange dedicated commands and I/O devices integrated with major computing engines, just like a group of abrupt mutations.
　　
The microprocessor has changed this situation by providing a small and low-cost CPU engine that can be used in large systems like building blocks; it uses a strict hardware architecture built based on different peripherals mounted together by a bus and provides a general purpose programming model that simplifies programming.
　　
Together with hardware, software has also been developed. initially, only some simple development tools were available for creating and debugging software. the running software of each project is usually compiled by graffiti. since the compiler often has many errors and lacks the like debugger, these software is almost always written in assembly or macro language. the idea of adopting software building blocks and standard libraries was not popular until the middle of 1970s.
　　
Operating Systems (OS) used for embedded systems that are not related to "shelve" began to appear in the late 1970s S. many of them are written in assembly languages and can only be used for their microprocessors. when these processors become obsolete, the operating systems they use are also doomed. it can only run on a new processor once. today, many of these early systems are just vague memories. Can someone remember MTOS? When the C language appears, the OS can be written in an efficient, stable, and portable way. this method is directly attractive for use and operation, because it carries the hope that people can protect their software investment when the microprocessor is deprecated. it sounds like a legend in commercial marketing. writing OS with C has become a standard until today. in short, software reusability has been accepted and is playing a good role.
　　
In the early 1980s s, my favorite OS was the Wendon operating system. It was about $150 to get its C source code library. it is a development kit, and people can build their own OS by selecting some components-the whole process is like ordering food from the Chinese menu. for example, you can select a task scheduling algorithm and memory management solution from the list of multiple feasible options in the database.
　　
Many commercial operating systems used for embedded systems were booming in 1980s. (Wendon) This original stew has developed into a modern stew of commercial operating systems. today, several dozen commercial operating systems are available. many competing products have emerged, such as VxWorks, pSOS, Neculeus, and WindowsCE.
　　
Many embedded systems have no operating systems at all, but they only have a control ring. this may be sufficient for a very simple embedded system. however, as the complexity of embedded systems increases, an operating system becomes more important, because otherwise, the complexity of (Control) software becomes extremely unreasonable. sadly, in reality there are indeed some complicated embedded systems, and they become complicated because their designers insist that their systems do not need an operating system.
　　
Gradually, more embedded systems need to be connected to some networks. Therefore, there must be a network protocol stack (supported) in the embedded system ); even the door handles in many hotels have a network-connected microprocessor.
　　
The complexity of adding a network stack to a simple embedded system that only uses a control ring can arouse people's desire for an operating system.
　　
In addition to a variety of commercial operating systems, there are also a variety of private operating systems. many of them are written in graffiti, such as Cisco IOS. some are due to the rewriting of other operating systems. For example, many network products are derived from the same version of Berkeley UNIX, because the latter has complete network support capabilities; there are also some operating systems based on the public domain. For example, KA9Q is derived from PhilKarn.
　　
As a candidate embedded operating system, LINUX has some notable advantages: it can be transplanted to multiple CPU and hardware platforms with different structures, with good stability and performance Upgrading capabilities, it is easier to develop ..
　　
Development tools-Break the obstacles of traditional Simulators
One of the most critical aspects in developing embedded systems is the availability of various tools. like any industry, good tools can help you complete tasks quickly and satisfactorily. Different tools may be used at different stages of embedded system development.
　　
Traditionally, the first tool for developing embedded systems is a simulator. This is an expensive device, which is usually inserted into the circuit between the microprocessor and its bus, so that developers can monitor and control all input and output microprocessor activities and behaviors. in assembly, there may be some difficulties, and they may cause unstable performance after installation due to their intrusion; however, they can give a clear picture of what is happening to a system at the bus level, aside from a lot of speculation at the bottom of hardware and software interfaces.
　　
In the past, some projects relied on it-often at various stages of the development cycle-as the main debugging tool. however, once the software has the ability to support a string port, a lot of debugging can be done without using ICE. similarly, most of the new generation embedded systems adopt a recipe-like microprocessor design. the startup code of communication work is often available to make the string port work as soon as possible, this means that developers can make good progress without using ICE, removing ICE, thus reducing development costs. once the string port can work, it can be used to support the related (software) layers of those increasingly complex development tools.
　　
LINUX is based on the gnu c compiler. The latter is part of the GNU tool set and works with the source code-level Debugger gdb, it provides all the software tools required to develop an embedded LINUX system. below are the sequences and steps of the typical debugging tools used to develop a new embedded LINUX system for a new hardware:
　　
1: write or transplant a startup Code (which will be discussed later );
　　
2: write a piece of code to output a string on the string port, like "Hello, World! "(In fact, I prefer the first sentence" Watson, come here I need you "after the phone is invented by humans ");
　　
3: port the gdb target code so that it can work on the string port. this will allow session to another LINUX host that is running the gdb program; you just need to tell gdb to debug the target program through the string port; gdb uses the string port to talk to the gdb target code on your test computer and provides debugging information for all C source code levels. you can also use this communication capability to download additional code to RAM or flash.
　　
4: Execute the remaining initialization code of all hardware and software until the Linux kernel begins to take over.
　　
5: Once the LINUX kernel is started, the above serial port becomes the Console port of LINUX and can be used for subsequent development. then use the gdb kernel debugging version kgdb. this step is often not necessary. if you have a network connection, for example, 10 BaseT, you may want it to work immediately.
　　
6: If the Linux kernel running on your target platform is fully functional (that is, it has not been deleted), you can use gdb or its graphical alternatives such as xgdb to debug your application process.
　　
Real-time -- is that true?
Rashly, not most systems. Embedded systems are often mistakenly called real-time systems, but most of them do not have real-time features. Real-time performance is only relative. Real-time strictly defined as hard real-time: ability to respond within a very short time (within milliseconds) and handle events in a certain way. Nowadays, many hard real-time functions are gradually concentrated in DSP or ASIC design, through some appropriate hardware, such as FIFO, DMA or other dedicated hardware.
　　
For most systems, one to five milliseconds of real-time response time should be enough. Of course, another loose requirement is acceptable, for example:
　　
Windows 98 processing monitor crashes the screen interruption, must be processed within 4 microseconds, accounting for 98% of all situations; and within 20 microseconds, processing accounts for 100% of all situations.
　　
These relaxed real-time requirements can be easily met. Some Discussions are involved in implementing these features, including on-site switching, interrupt latency, task optimization, and scheduling.
　　
On-site switching once became a hot topic in the operating system field. However, because most of the CPUs are satisfactory at this point and the CPU speed has become fast enough, field switching is no longer a major concern.
　　
Real-time rigor requirements should usually be handled by an interrupt routine or an on-site driver function in the kernel to ensure behavior consistency. when an interruption occurs, the time used to handle the interruption, that is, the interruption delay, is largely determined by the interruption priority and other software that can temporarily block the interruption.
　　
(In real-time systems) interruptions must be efficiently designed and arranged to meet time requirements, as in other operating systems. in the Intel X86 processor series, this work can be well processed by Linux with extended real-time performance. (Real-Time Linux, that is: RTLinux, see http://www.rtlinux.org /). essentially, it provides an interrupt handling scheduler that uses Linux as its background task. (This essentially provides an interrupt processing scheduler that runs Linux as its background task) some key (critical) interruptions can get the service (processing) not known to other parts of Linux. Therefore, you have control over the critical time. this approach provides an interface between the real-time and time-restrictive basic Linux levels. it also provides a real-time processing framework similar to other embedded operating systems. fundamentally speaking, to meet real-time requirements, the key (critical) code segments of real-time performance are isolated for efficient arrangement, then the processing result of the code segment is further processed in a more general way (perhaps at the process level.
　　
Embedded System-Definition
One idea is that if an application does not have a user interface and users cannot directly interact with it, it is an embedded system. this is too simple. the elevator control system is an embedded system, but there is a user interface: select the button on the floor and the indicator that shows the elevator is reaching several layers. for embedded systems connected to the network, if the system contains a web server for monitoring and control, the differences on the interface are even more vague. A good definition should emphasize the important functions or main purposes of the system.
　　
Linux provides a basic kernel used to execute the embedded function and a variety of user interface elements you want. Therefore, Linux has a strong general feature.