Linux embedded system and how to develop your own Embedded System

Linux embedded system and how to develop your own embedded system-Linux general technology-Linux programming and kernel information. The following is a detailed description. Most Linux systems run on PC platforms, but Linux is also very stable as an embedded system. This article depicts an overview of an embedded system and shows how embedded system products use Linux.

The story of an embedded system older than Moses

The history of computers used to control devices or embedded systems is almost as long as that of computers. In the field of communication, computers were used in electronic telephone switches in the late 1960s S, known as the "storage program control" system. The term "computer" was not universal at that time, and the storage program refers to the memory containing program and routine information. Storage control logic, rather than curing it in hardware, was indeed a breakthrough at the time. Today, we think it should have been so.

At that time, the computers were customized for every application. According to today's standards, they were some abnormal and integrated into a computer by strange special commands and I/O devices.

The microprocessor has changed all of this by providing small, low-cost, and CPU engines for building large system modules. It proposes a fixed hardware architecture connected by peripherals through a bus and a general programming model called programming.

The software is also proposed with the hardware. Initially, writing and testing software only had simple programming and development tools. The actual running software of each project usually comes from the modification of the draft. Programming is commonly used in assembly or macro languages, because the compiler often has defects and lacks complete debugging tools. Software building modules and standardized libraries were only popular in 1970s.

The commercialized Operating System of embedded systems emerged in the late 1970 s. Many of them were written in assembly languages and can only be used for specific microprocessors. When the microprocessor is eliminated, its operating system will be eliminated unless it is rewritten as a new processor. Today, many of these early systems have become vague memories. Does anyone remember MTOS? When the C language appears, the efficiency, stability, and portability of the operating system are greatly improved. This is immediately manifested in management, and it brings hope to protect software investment when the microprocessor is eliminated. This is good news for the market. Operating systems written in C language are becoming more and more common today. In general, reusable software has become dominant and the better it is.

In the early 1980s s, my favorite operating system was Wendon, which offered me a C source code library for about $150. It is a package. you can create your own operating system by selecting components, similar to ordering on the menu. For example, you can set a job schedule and a memory management solution on the library list. The commercial operating systems of many embedded systems emerged in 1980s. This boom has continued until now, and today there are many feasible commercial operating systems to choose from. Some bosses have appeared, such as VxWorks, pSOS, Neculeus, and Windows CE.

Many embedded systems do not have an operating system at all, and they only have loop control. This is sufficient for some simple devices, but as the system becomes more complex, the operating system becomes necessary or the software becomes incredibly complex. Unfortunately, some complicated and terrible embedded systems are only as complicated as designers insist on not operating systems.

Gradually, more embedded systems need to be connected to various types of networks, so network functions are required. Even the hotel's door handle is embedded with a microprocessor connected to the network. For embedded systems that only require code control loops, adding network functions will increase the complexity of the system and require the operating system.

In addition to commercialized operating systems, there are also a large number of dedicated operating systems. Most of them come from drafts, such as cisco ios, and are derived from other operating systems. For example, Many operating systems are derived from the same version of Berkeley Unix because they have full network functionality. Others are based on major operating systems such as KA9Q from Phil Karn.

Linux, as an embedded system, is a new member with many advantages. It is portable, stable, powerful, and easy to develop for many CPU and hardware platforms.

The toolkit breaks the ICE Obstacle

The key to developing embedded systems is the available toolkit. Good tools make work faster and better, just like any job. Different tools are required at different stages of development.

Traditionally, the tool used to develop embedded systems is an internal circuit simulator (ICE), which is a relatively expensive component used to implant the circuit between the microprocessor and the bus, allows users to monitor and control all the signals from the microprocessor. This is a bit difficult because it is an external type and may cause instability. However, it provides a clear picture of the work of the bus, avoiding a lot of speculation about the underlying work of the hardware software.

In the past, some work relied on ICE as the main debugging tool for the entire development process. However, if the initialization software has good support for the serial port, most debugging operations can be performed without using ICE instead of other methods. Newer embedded systems use very clear microprocessor design. Sometimes, the corresponding initial code can quickly obtain the serial port. This means that people can work easily without ICE. It saves ICE and reduces development costs. Once the serial port starts to work, it can support a variety of professional development tools.

Linux is a GNU-Based C compiler. As part of the GNU tool chain, it works with the gdb source debugger. It provides all the software tools for developing embedded Linux systems. This is a typical debugging tool used to develop embedded Linux systems on new hardware.

1. Write or implant the Boot Code

2. Print the string encoding to the serial port, such as "Hello World" (In fact, I prefer "Watson, Come hre I need you", the first word commonly used on the phone .)

3. implant the gdb target code into the working serial port, which can be used to talk to another Linux host system running the gdb program. Just tell gdb to debug the program through a serial port. It communicates with the gdb target code of the test machine through the serial port. You can debug the C source code, or use this function to load more codes into RAM or Flash Memory.

4. Use gdb to enable the hardware and software initialization code to work during Linux kernel startup.

5. Once the Linux kernel is started, the serial port becomes the Linux control port and can be used for subsequent development. With kgdb, the kernel debugging version of gdb, this step is often not required. If you connect to the network, such as 10 BaseT, you may need to start it next.

6. If you run the complete Linux Kernel on your target hardware, You can debug your application process. Use other gdb or overwrite gdb images, such as xgdb.

What is a real-time system?

Embedded systems are often mistakenly divided into real-time systems, although most systems generally do not require real-time functions. Real-time is a relative term, which is often strictly defined by the purser as a response to an event in a predetermined manner in a very short time, such as microseconds, strict real-time functions within such a short interval are implemented on a dedicated DSP chip or ASIC. This requirement is required only when the underlying hardware FIFO, distributed/clustered DMA engine, and customized hardware are designed.

Many designers are anxious about real-time requirements due to a clear understanding of real requirements. For most systems, the approximate real-time response in one to five microseconds is sufficient. Soft requirements are also acceptable. For example, if Windows 98 has crashed, the interruption must be handled within 4 milliseconds (± 98%) or 20 milliseconds (± 0.

Such soft requirements are easily met, including the Environment conversion time, interrupt wait time, task priority, and sorting. Environment conversion time was a hot topic in the operating system. In short, most of the CPU requirements are well handled, and the CPU speed is now much faster, this problem is not important.

Strict real-time requirements are usually handled by interrupt routines or other kernel environment driver functions to ensure stable performance, waiting time, the time required for a request to request a service depends largely on the priority of the interruption and other software that can temporarily mask the interruption.

Interruptions must be handled and managed to ensure time requirements are met, just like many other operating systems. In the IntelX86 processor, this work can easily be extended by Linux in real time. This provides a way to run Linux interrupt handling Scheduling for subsequent tasks. Critical interrupt responses do not need to be notified to Linux. Therefore, we can get a lot of control over the key clock. Interfaces are provided between the real-time control level and the basic Linux level with loose time limit, which provides a real-time framework similar to other embedded operating systems. Therefore, real-time key code is separated and "designed" to meet requirements. The result of code processing is in a more general way, maybe only at the application task level.

Embedded system definition

One idea is that if an application does not have a user interface, it must be embedded because the user cannot directly interact with it. Of course, this is simplified. An elevator-controlled computer is considered embedded: press the button to select the floor indicator to display the elevator stop layer. For networked embedded systems, if the system contains a web browser for monitoring and control, this boundary is even more vague. Better definitions focus on the centralized functions and main objectives of the system.

Linux provides the basic kernel for embedding and all the user interfaces you need. It can process embedded tasks and user interfaces. Linux is regarded as a continuous unity. It supports all file systems and network services from a microkernel with memory management, task switching, Time Service and its splitting to a complete server.

A small embedded Linux system only requires the following three basic elements:

Guide tool

The Linux microkernel consists of memory management, process management, and transaction processing.

Initialization Process

If you want it to do something and keep it small, you need to add:

Hardware driver

One or more applications that provide the required features.

To add more features, you may need these

A file system (maybe in ROM or RAM)

TCP/IP network stack

Disks used to store semi-transition data and exchange data.

Hardware Platform

Choosing the best hardware is a complex job that is full of politics, prejudice, and traditions of other projects in the company, and lacks complete or accurate information. Cost is often a key issue. When you consider the cost, make sure that you are considering the overall cost of the product, not just the CPU. Sometimes, once a fast and cheap CPU is added with bus logic and latency, it can work with peripherals and become an expensive dog product. If you are looking for software, first, the hardware already has products. If you are a system designer, it is up to you to decide whether the real-time budget and hardware work are satisfactory.

In reality, how fast the CPU is needed to complete a job, and then zoom in three times. It's strange that the theoretical speed of the CPU is the same as that in reality. Don't forget that the application will make full use of the cache.

Imagine how fast the bus needs to be, if there are other bus such as the PCI bus, included. A slow bus or a bus with DMA blocking will reduce the CPU speed and cause congestion. It is good to have the CPU of the Integrated Device, because only a few devices need to be debugged, and drivers that support general CPU are usually easy to obtain. In my project, the connection between chips and peripherals often fails or does not meet the compatibility we need. Because peripherals are integrated, don't think it will be cheap.

Add a-pound Linux to a bag containing only 5.

A common understanding of Linux is that it is amazing to use it in embedded systems. This may not be true. Linux on a typical PC has many functions for PC users.

For beginners, the kernel and task can be separated. The standard Linux kernel usually reside in the memory, and every application is migrated from the disk to the memory for execution. When the program ends, the memory occupied by it is released and the program is downloaded.

In an embedded system, there may be no disks. There are two ways to eliminate disk dependencies, depending on system complexity and hardware design.

In a simple system, after the system is started, the kernel and all applications are in the memory. This is the operating mode of most traditional embedded systems, which can also be supported by Linux.

With Linux, there is a second possibility. Because Linux has the ability to "LOAD" and "Uninstall" programs, an embedded system can use it to save memory. Imagine a typical Flash that includes about 8 MB to 16 MB

Memory and 8 MB Memory. Flash Memory can be used as a file system. Flash Memory driver used to connect to Flash

Memory and file system. Flash Disk can be used as an alternative. This Flash part uses software to simulate the disk. One example is the DiskOnChip of M-Systems, which can reach 160 MB. Http://www.m-systems.com ). All programs are stored in Flash files as files, and the memory can be loaded as needed. This dynamic and "load as needed" capability is an important feature that supports a series of other functions:

It releases the initialization code after system boot. Linux also has many utilities running outside the kernel. These programs run once during initialization and will not run any more. In addition, these utilities can run in sequence one by one in a way they share one another. In this way, the same memory space can be repeatedly used to "call" every program, just like system boot. This can indeed save memory, especially those network stacks that will not be changed once after configuration. If Linux can load modules, including the functions in the kernel, drivers and applications can be loaded. It can check the hardware environment and install corresponding software for the hardware. This eliminates the use of a program to occupy a lot of Flash

Memory is used to handle the complexity of multiple types of hardware.

Software upgrades are more modular. You can upgrade the application and load the driver on Flash when the system is running.

Configuration Information and running time parameters can be stored as data files in Flash.

Non-Virtual Memory

Another pending feature of standard Linux is the capability of virtual memory. This magical feature allows application programmers to write code with no consequence, no matter how large the program is. The program overflows to the disk swap area. In an embedded system without disks, this is usually not the case.

This powerful function is not required in embedded systems. In fact, you may not want it to be in real-time critical systems, because it will lead to uncontrollable time factors. This software must be designed to fit the physical memory on the market, just like other embedded systems.

Note that for CPU reasons, it is wise to save the Virtual Memory code in Linux, because it is very troublesome to clear it. Another reason is that it supports sharing text so that many programs can share a piece of software. Without this, every program must have its own library, just like printf.

The virtual memory transfer-in function can be disabled, as long as the swap space is set to zero. Then, if the program you write is larger than the actual memory, the system will use up swap space for processing as you run; this program will not run, or malloc will fail.

On many CPUs, the memory management provided by the virtual memory can separate different programs to prevent them from being written to the space of other addresses. This is usually not possible in an embedded system because it only supports a simple and flat address space. This feature of Linux is helpful for its development. It reduces the possibility of system crashes caused by random programming. Many embedded systems consciously use the "Global" data that can be shared between programs based on efficiency reasons. This can also be supported through the Linux shared memory function, which only shares the specified memory.

File System

Many embedded systems do not have disks or file systems. Linux can run without them. As mentioned above, application tasks can be written together with the kernel and loaded as an image during boot. This is enough for a simple system. However, it lacks the flexibility mentioned above.

In fact, many commercial embedded systems provide file systems as an option. Many are dedicated file systems or MS-DOS-Compatible file systems. Linux provides the MS-DOS-Compatible file system and multiple other options. Other options are provided because they are more powerful and fault tolerant. Linux also provides inspection and maintenance functions, which are often not provided by commercial vendors. This is especially important for Flash systems because it is updated through the network. If the system loses its capacity during the upgrade process, it will be useless. Maintenance functions can usually solve such problems.

File systems can be placed on traditional disk drives, Flash Memory, or other such media. In addition, a small ramdisk is enough for saving files temporarily. Flash Memories is split into blocks. These blocks may include a boot block containing the initial software that runs when the CPU starts. This may include the Linux boot code. The remaining Flash files can be used as file systems. The Linux kernel can be copied from Flash to RAM through boot code, or another option is available. The kernel can be stored in an independent part of Flash and executed directly from there.

Another interesting option for some systems is to include a cheap CD-ROM. This is cheaper than Flash Memory and supports Simple upgrades by switching CD-ROM. With this, Linux just needs to boot from the CD-ROM and get all the programs from the CD-ROM as from the hard disk.

Finally, Linux supports Network File System (NFS) for networked embedded systems ). This opens the door for realizing many value-added functions of the networked system. First, it allows applications to be loaded over the network. This is the basis for controlling software modifications, because software in every embedded system can be loaded on a common server. It can also be used to input or output a large amount of data, configuration, and status information during running. This is a very powerful function for user monitoring and control. For example, an embedded system can create a small RAM disk, which contains content that is synchronized with the current status information. Other systems can simply set this RAM disk as a network-based remote disk and access status files in the air. This allows the Web server on another machine to access status information through a simple CGI Script. Other application packages running on other computers can easily access data. For more complex monitoring, application packages such as Matlab (http://www.mathworks.com/products/matlab/) can be used to provide graphical representations of system operation in the operator's PC or workstation.

Guide LILO and BIOS

When a microprocessor is started for the first time, it starts to execute commands on the preset address. There are usually some read-only memory, including initialization or boot code. On PC, this is BIOS. It executes some low-level CPU initialization and other hardware configurations. The BIOS continues to identify which disk has an operating system, copies the operating system to RAM, and redirects to it. In fact, this is very complicated, but it is also very important for our goals. Linux running on a PC relies on the pc bios to provide these configurations and OS loading functions.

This BIOS is often not used in an embedded system. In this way, you must provide the same startup code. Fortunately, embedded systems do not require the flexibility of the pc bios boot program, because they usually only need to handle a hardware configuration. This code is simpler and boring. It is just a command list that inserts fixed numbers into hardware registers. However, this is the key code, because these values must be consistent with your hardware and in a specific order. Therefore, in most cases, a minimum power-on self-check module can check the normal operation of the memory, flash the LED, and drive other required hardware to enable and run the main Linux OS. These startup codes are completely determined by hardware and cannot be moved at will.

Fortunately, many systems have menu-based hardware designed for the core microprocessor and memory. Typically, the chip manufacturer has a sample motherboard which can be used as a reference for design more or less the same as the new design. Generally, the startup code of these menu designs can be obtained, and it can be easily modified according to your needs. In a few cases, the startup code needs to be rewritten. To test the code, you can use a built-in simulator that contains the 'analog memory 'circuit, which can replace the target memory. You can install the code on the simulator and debug it through the simulator. If this does not work, you can skip this step, but it takes a longer debugging cycle.

This code will eventually run on a relatively stable memory, usually Flash or EPROM chip. You need to use some methods to put the code on the chip. How to do this depends on the "target" hardware and tools.

A popular method is to insert Flash or EPROM chip into an EPROM or Flash burner. This will "burn" your program into the chip. Then, insert the chip into the socket of your target board and turn on the power. This method requires a socket on the board, but some devices cannot be equipped with a socket. Another method is to use a JTAG interface. Some chips have a JTAG interface that can be used to program the chips. This is the most convenient method. The chip can always be welded to the motherboard. A small cable is the JTAG connector on the board, usually a PC Card, connected to the JTAG interface. The following are some common programs required to run the JTAG interface on the PC. This device can also be used for a small amount of production.

Robustness is more reliable than politicians promise.

Linux is very reliable and stable when running on PC hardware, especially compared with some popular operating systems. How stable is the embedded kernel itself? Linux is good for most microprocessors. The Linux kernel transplanted to the new microprocessor family runs as stable as the current microprocessor. It is often transplanted to one or more specific motherboard. These boards include specific peripheral devices and CPUs.

Fortunately, a lot of code is different from the processor, so porting is focused on the difference. Most of them are in the areas of memory management and interrupt control. Once successfully transplanted, they are very stable. As we have discussed earlier, boot policies are widely dependent on hardware requirements and you must do some customized work in a planned manner.

Device Drivers are even more messy: some stability is somewhat unstable. And the selection is very limited; once you leave the general PC platform, you need to write your own. Fortunately, there are many drivers around you, and you may find a change that is similar to your needs. The driver interface has been defined. Many types of drivers are very similar, so it is usually not difficult to port a disk, network, or a series of port drivers from one device to another. I found that many drivers are well written and easy to understand, but you still have to prepare a book about the kernel structure at hand. In my experience, Linux is at least as stable as the famous commercial operating system I have used. In short, the problem between these operating systems and Linux lies in the misunderstanding of microseconds in the working process, not in the difficulty of code or basic design errors. There is a lot of debate about any operating system, and there is no need to repeat it here. Linux has the following advantages: open source code, clear comments, and complete documentation. In this way, you can control and handle any problems.

With the basic kernel and driver, there are other problems. If the system has a hard disk, the reliability of the file system becomes a problem. We have more than two years of experience in designing Linux systems using disks. These systems have almost never been shut down normally. The power supply may be interrupted at any time. I feel very good, using the standard (EXT2) file system. The standard Linux Initialization script runs the fsck program, which is very effective in checking and clearing unstable inodes. It is wise to run the update program every 30 seconds instead of every 5 or 10 seconds. This shortens the time for data to be stored in the cache before it enters the disk, and reduces the possibility of data loss.

How to Develop

Embedded Linux does have its defects. For example, although it is not much worse than some competitors, it is indeed a greedy memory. This can be done by reducing unnecessary functions, but it may take a long time and, if not carefully, it may cause great troubles.

Many Linux applications use virtual memory. In many embedded systems, there is no value. Therefore, do not think that an embedded system without disks can run any Linux application.

Kernel debugging tools are not very good, especially at the underlying layer. Kgdb can easily locate errors. You only need to restart. Unfortunately, printing statements is more troublesome.

However, the worst thing for me is my psychological problem. Linux is very flexible. Embedded systems are not flexible in general, and they are strictly designed for the most effective implementation of predefined functions. The current trend is to maintain flexibility, overall goal functions, and minimize modifications. This goal is lofty, but the price will be greatly adjusted for specific work. Maintaining flexibility will result in additional work, with additional software packages, and sometimes lower performance. A recurring example is configuration. Consider configuring IP addresses on a network interface, which is usually done by running the ifconfig program on the startup script. This is a 28 K program. It calls data from the configuration file and can be replaced by several lines of code to initialize an appropriate structure. However, even if it is reasonable, it is still harmful because it distort the software in a way that has never been used.



The Application of Linux in embedded systems is feasible. It is useful and reliable. Its development cost is the same as that of its replacement.

[ Last edited by cooc on]