外文翻译---嵌入式系统的网络服务器
- 格式:doc
- 大小:1.41 MB
- 文档页数:13
Implementation and Evaluation for Sophisticated Periodic ExecutionControl in Embedded SystemsYuuki Furukawa, Toshihiro Yamauchi and Hideo Taniguchi Graduate School of Natural Science and Technology, Okayama Universityfurukawa@swlab.cs.okayama-u.ac.jp, {yamauchi, tani}@cs.okayama-u.ac.jpAbstractEmbedded systems are complicated, and a large number of these systems are widely used today. In embedded systems, the types of processings to be executed are limited, and many processes are executed periodically. In such systems, we need to reduce the overhead of periodic execution control and the dispersion of the processing time. ART-Linux has been proposed as a conventional real-time operating system that can be used for this purpose in various devices such as robots. In this paper, we discuss the periodic execution control of ART-Linux and clarify several problems. Next, we propose a design for sophisticated periodic execution control in order to solve these problems. In addition, we discuss the realization of periodic execution control, and the effects of the proposed control. Finally, we show the results of our evaluation for the release and the wait to clarify the effects of the proposed control.Keywords: P eriodic execution control, Scheduling, ART-Linux, Control overhead, Real-time process1. IntroductionEmbedded systems are complicated, and a large number of these systems are widely used today [1]. Therefore, it is important to upgrade the software that controls the resources of the embedded devices. In embedded systems, the types of processings to be executed are limited, and many processes are executed periodically. An example of such a process is a process that controls the motor of a robot; this process needs to be executed every 5 ms. Such a process must be executed before a deadline, and this is an example of real-time processing. In this case, we need to reduce the overhead of the periodic execution control and the dispersion of the processing time.ART-Linux [2][3][4] has been proposed as a conventional real-time operating system that can be used in devices such as robots [5]. In ART-Linux, we can use the application program (AP) and the device driver for Linux, the real-time process with the short period can be periodically executed without significant jitter. There have been studies related to the improvement of the performance of ART-Linux [6].In this paper, we discuss the periodic execution control of ART-Linux and clarify several problems. Next, we propose a design of a sophisticated periodic execution control to solve these problems. In addition, we discuss the realization of periodic execution control, and the effects of the proposed control. Finally, we present the evaluations of the control overhead and the dispersion of the processing time to clarify the effects of the proposed control.2.1. Periodic Execution ControlART-Linux is a real-time operating system based on Linux. We refer to processes executed periodically as real-time processes; all other processes are termed non-real-time processes.ART-Linux manages real-time processes and non-real-time processes separately. Real-time processes have a higher priority than non-real-time processes. That is, non-real-time processes are executed only when there are no real-time processes to be executed.We show the periodic execution control of ART-Linux in figure 1. The ready queue in figure 1 manages the real-time processes that are in a ready state so that the processes can be executed on the basis of priority. We call this the ready state. The wait queue manages the real-time processes that are in a wait state. We call the transition from the wait queue to the ready queue a release. In the next few paragraphs, we explain the processing of the periodic execution control of ART-Linux.1. RegisterWhen a non-real-time process requires registration, this process is connected to the ready queue. Consequently, it is managed as a real-time process. This real-time process is assigned a period and a priority.2. ExecuteIf there is already a real-time process in the ready queue, the real-time processes are executed on the basis of their priorities.3. WaitA real-time process requires a wait when the processing of the real-time process for oneperiod is finished. Then, this real-time process is disconnected from the ready queue, connected to the wait queue, and set a waiting time. The waiting time is the time from the next release time of the real-time process before this one in the wait queue to the next release time of this real-time process. In this way, the real-time process waits until its next release time.4. ReleaseAt the time of a timer interrupt, the waiting time of the real-time process at the top of the wait queue is calculated. If the resulting value is less than 0, the real-time process is disconnected from the wait queue and connected to the ready queue. Then, the waiting time of the next real-time process in the wait queue is calculated, and the release of this real-time process is judged. The above step is repeated until the waiting time after calculation is greater than 0 or until all real-time processes are disconnected from the wait queue. In other words, the above step is repeated until all real-time processes reaching a release time are connected to the ready queue.5. UnregisterWhen a real-time process requires unregistration, this process is disconnected from the ready queue and managed as a non-real-time process. Then, its period and priority are initialized.2.2. Performance2.2.1. Measurement environment and items: We measured the processing time from the timer interrupt to the execution of a real-time process to clarify the periodic execution control overhead in ART-Linux. Further, we measured the interval error of the periodic execution to clarify the precision of the periodic execution control. An interval of the periodic execution is the time from a processing start time to the next processing start time for a real-time process. In addition, the interval error is the difference in value between an interval and the period of a real-time process. We list the measurement environment in table 1. We used the rdtsc instruction to record the time.2.2.2. Time from timer interrupt to execution of real-time process: We registered one real-time process with a period of 1 ms and the maximum priority and measured the time from the timer interrupt to the execution of this process 100 times. This result is shown in table 2, and the distribution of the time is shown in figure 2.The difference between the average values and the maximum values is considerably larger than the difference between the average values and the minimum values in both table 2 and figure 2. We speculate that the dispersion of the time from the timer interrupt to the execution of the real-time process is large. One reason for this may be the fact that the processing time for the release is proportional to the number of real-time processes to be released at the same time, and the time from the timer interrupt to the execution of the real-time process increases. Therefore, we believe that the precision of the periodic execution will be low.2.2.3. Measurement of interval of periodic execution: We registered one real-time process with a maximum priority and measured the interval of periodic execution. We set theexecution in each case. The interval error is shown in figure 3; we have explained it below.The interval error of the periodic execution is proportional to the period shown in figure 3. We measured the precision of the timer interrupt period to clarify this factor. As a result of the measurement, we found that the actual timer interrupt interval is approximately 0.996 ms for the timer interrupt interval of 1 ms. Therefore, there is approximately 0.4% error for the timer interrupt interval. In figure 3, the interval error of the periodic execution is approximately 4 µs for a period of 1 ms. That is, this error is affected by the error of the timer interrupt interval. In addition, we speculate that the timer interrupt does not occur by a correct period because of the difference between the timer interrupt period that the system requires and the precision of the timer movement clock.2.3. ProblemsWe will discuss five problems to be clarified by the processing of the periodic execution control and the result of the measurement in ART-Linux.1. The control overhead for a release is proportional to the number of real-time processesscheduled to be released at the same time, and the dispersion of the processing time for the release is considerable.For the release at the time of the timer interrupt in ART-Linux, the waiting time for a real-time process at the top of the wait queue is calculated, and the release of this process is judged. Then, all real-time processes scheduled to be released at this time are disconnected from the wait queue and connected to the ready queue. Therefore, the control overhead for the release is proportional to the number of real-time processes scheduled to be released at the same time. Therefore, if there are a considerable number of real-time processes scheduled to be released at the time of the timer interrupt, the processing time for the2. The control overhead of the connection processing to the wait queue for the wait isproportional to the number of real-time processes, and the dispersion of the processing time for the wait is considerable.For the wait of a real-time process in ART-Linux, the wait queue is searched from the top to calculate the waiting time of a real-time process that requires a wait and decide a position to insert this process into the wait queue. Therefore, processing that is proportional to the length of the wait queue is required; the control overhead for the wait is affected by the number of real-time processes and the waiting time of each real-time process in the wait queue. For example, if there are a considerable number of real-time processes that are released earlier than the real-time process that requires a wait, the processing time for the wait is significant. Hence, the processing time for the wait is long, and the dispersion of this processing time is considerable.3. A real-time process that is not completely processed before the next release time has anadverse effect on the other real-time processes.Let us consider a case in which a real-time process is not completely processed before the next release time of a periodic execution control. Such a real-time process changes the interval of the periodic execution of the other real-time processes, and the precision of the periodic execution becomes low. In figure 4, process B is an example of such a real-time process. When process B requires a wait in ART-Linux, it waits from this time to the next release time. In this case, process B waits until the release time of t2 not t1. In other words, even if process B is not executed periodically on the basis of its period, the execution of this process continues periodically. Process B uses the time when process A is feasible, and the interval of the periodic execution of process A changes.4. The dispersion of time from the timer interrupt to the execution of a real-time process issignificant.As shown in Section 2.2.2, there is a case in which the change in the time from the timer interrupt to the execution of a real-time process is considerable. If such a change in time is big, the precision of the periodic execution is low. One of this reason is that the dispersion of the processing time for the release is significant.5. A difference in the clock precision between a timer and a processor is not coordinated.As shown in Section 2.2.3, the interval error of the periodic execution is proportional to the period and increases because there is a difference in the clock precision between a timer and a processor. If the difference between the period and the interval of the period execution is considerable, the precision of the periodic execution will be low.3. Sophisticated periodic execution control3.1. DesignThe processing time of the release and the wait for the periodic execution control of ART-Linux are affected by the number of real-time processes, and the dispersion of those processing time is significant. This results from the waiting time of a real-time process. Therefore, the sophisticated periodic execution control that we propose manages the real-time process scheduled to be released with respect to the time of each timer interrupt without managing the real-time processes that need to wait in one queue. Therefore, the proposed control can solve four of the five above-mentioned problems for the periodic execution control in ART-Linux.In figure 5, we show the schematic representation of the sophisticated periodic execution control that can solve problems 1–4 of ART-Linux. The control can be explained as follows: The execution management table in figure 5 is equivalent to the ready queue shown in figure 1, and the periodic control table is equivalent to the wait queue.particular, it manages the release element of the real-time process to be executed by connecting it to the entry of the execution management table on the basis of the priority of the real-time process. The release element is the element that has the information of the real-time process and has two queue entries. These entries are used for connecting the real-time process to the execution management table and the periodic control table. The periodic control table manages the real-time process scheduled to be released each time; the number of entries is equivalent to the longest period that can be set. One entry in this table is equivalent to one timer interrupt and is connected to the release element of the real-time process to be released at the timer interrupt. In other words, the number of entries in the periodic control table should be the least common multiple of the periods for all real-time processes.We explain the processing of the sophisticated periodic execution control below.1. RegisterWhen a non-real-time process requires registration, this process is managed as a real-time process by the periodic control table. Then, the periodic control table is searched, an entry that is connected to few release elements in the periodic control table is found, and the release element of the real-time process is connected to this entry. Simultaneously, the real-time process is set a period and a priority.2. ReleaseAt the time of the timer interrupt, the current entry is translated to the next entry. The current entry is the entry that corresponds to the time of the timer interrupt in the periodic control table. If there is a release element in the current entry, the decision to release a real-time process is taken. In particular, the release element is connected to the execution management table on the basis of the priority of the real-time process. Then, the release element is not disconnected from the periodic control table. If the priority of the real-time process to be released is greater than that of the current process, a pre-emption occurs. In addition, if there is a release element of the real-time process to be executed in the execution management table at this time, all release elements of this real-time process are disconnected from the execution management table and the periodic control table, and this real-time process is terminated. This is done to restrain the adverse effect that this real-time process has on the other real-time processes.3. ExecuteAfter the processing of release, wait, and unregister, if there is a release element in the execution management table, real-time processes are executed on the basis of their priorities. Then, the release element is not disconnected from the execution management table. Therefore, there is a release element of the real-time process being executed at the top of the entry corresponding to the priority of the execution management table. A bitmap is used for deciding which entry should be connected to the execution management table.4. WaitWhen a real-time process requires a wait, its release element is disconnected from the periodic control table. Therefore, the real-time process waits until the next release time.5. UnregisterWhen a real-time process requires unregistration, all release elements of this process are disconnected from the periodic control table. Then, the period and the priority of this process are initialized. Hence, this process is managed as a non-real-time process.3.2. CharacteristicsThe sophisticated periodic execution control that we proposed in Section 3.1 has the following characteristics:1. The release of the real-time process is managed by the periodic control table.2. A release element has two queue entries that are used for connecting the release element tothe execution management table and the periodic control table.3. A real-time process that is not completely processed before the next release time isterminated.4. When the release element is connected, the dispersion for the number of release elementsconnected to each entry of the periodic control table becomes low.According to characteristic 1, the calculation of the waiting time is unnecessary. Because of characteristic 2, the processing of the disconnection from the periodic control table for the release and the processing of the connection to the periodic control table for wait are unnecessary. Furthermore, because of characteristic 1 and 2, the number of queue operations required decreases, and the control overheads for the release and wait become small. In addition, we have speculated that the dispersion of the processing time for the release and wait become small because the number of processing for searching the release element is few. Because of characteristic 3, the influence of a real-time process that is not completely processed before the next release time on the other real-time processes is restrained. Because of characteristic 4, the dispersion of the processing time for the release becomes small.3.3. Realization3.3.1. Data structure: We have realized the sophisticated periodic execution control that we proposed earlier. We show the data structure of this periodic execution control in figure 6 and explain each management table below. The data structure of the periodic execution control has six management tables.real-time processes with the periodic control table. The current entry (curpointp) is translated into the next entry at every timer interrupt. Pct is the pointer to the top of the periodic control table, and pctsize is the number of entries in the periodic control table.The number of entries in the periodic control table is the least common multiple of the periods of all real-time processes. Each entry manages the release element. All release elements that are connected with the entry to which curpointp points, (current entry) are connected to the execution control table for the release. The count of the periodic control table is the number of release elements to manage.The release element contains information on the real-time process. Next is used for connecting the release element to the periodic control table, whereas prinext is used for connecting the release element to the execution management table. Procp is pointer to the real-time process.The execution management table manages the release elements of the real-time processes that are to be executed on the basis of their priority. In this table, the release element of the real-time process being executed is at top of the entry that has the maximum priority among the entries that release elements are connected.The real-time information table manages the period and the priority of the real-time process. The number of each entry is equivalent to the process identifier. If the process management table manages the period and the priority of the real-time process, the access time may increase because the process management table has a considerable amount of information. Therefore, the cache miss is restrained, and the access time required to use the real-time information table becomes short. When a real-time process is registered, rflag is set a period and rpri is set a priority. If the real-time process is released, the most significant bit of rflag is set. Further, when the real-time process requires a wait, this bit is reset.number of unused release elements, and maxnum is the number of all release elements that are allocated at the time of the initialization of all management tables.3.3.2. Coding:Bear in mind the following for the implementation of the sophisticated periodic execution control.First, the optimization of the code and the use efficiency improvement of the register used in the method are required in order to speed up processing. For example, we summarize the cords handling the same variable in one place in order to reduce the amount of rewriting in the register. As a result, the processing time becomes short.Many release elements may be used by a real-time process in the proposed control. Therefore, the quantity of data to be referred to during one processing may become considerable, and the cache miss rate may become high. Moreover, the access time may increase significantly because the data spatial locality becomes low. Therefore, when the sophisticated periodic execution control is implemented, it is necessary to devise how to handle data such as the period and the priority of the real-time processes and how to allocate the release element.Hence, we reduce the quantity of data for a real-time process and minimize the quantity of data for a release element. Further, during the processing of the release and the wait, data that do not relate with the periodic control are not read. The release element has only two queue entries and a pointer to the process. Information related to the real-time process, such as the period and the priority, is described in the real-time information table. This is done to avoid giving the information of the real-time process in the process management table and to reduce the quantity of data that is accessed. If the process management table contains the information of the real-time process, the quantity of data that needs to be accessed increases considerably because the process management table has a significant amount of information. Moreover, the state of the real-time process as ready or wait is contained in rflag. We can use the same entry to manage the period and the state of the real-time process because the period of the real-time process is only changed in the processing of registration or unregistration. Therefore, we can reduce the quantity of data accessed, and the cache miss rate becomes low.Figure 7 shows how to allocate release elements in the control that we have realized. At the initialization of each management table, release elements are allocated according to the maxnum size. Let x be the value that is obtained by dividing maxnum by pctsize. “i” is the serial number of each entry in the periodic control table. When the release element is connected to the i-th entry, the unused release element to use is searched from the (x * i)-thentry of all release elements. Therefore, the release element for each entry in the periodic control table is accumulated in the memory. Therefore, the data spatial locality is improved, and the access time for the release and wait decreases.3.4. EffectsWe have described the effects of the sophisticated periodic execution control below.1. The control overhead of the release becomes small.For the release of a real-time process in ART-Linux, the waiting time for all real-time processes scheduled to be released at the same time is calculated; then, these processes are disconnected from the wait queue and connected to the ready queue. On the other hand, in the proposed control, the current entry is translated into the next entry, and all release elements of the current entry are connected to the execution management table. Therefore, it is unnecessary to calculate the waiting time and to disconnect the real-time processes from the wait queue. Moreover, the number of processing that is influenced by the number of real-time processes scheduled to be released at the same time decreases, and the dispersion of the processing time for release becomes small.2. The control overhead of the wait becomes small, and the dispersion of the processing timefor the wait becomes small.For the wait of a real-time process, in ART-Linux, the wait queue is searched from the top, and the waiting time for the real-time process that requires a wait is calculated. Then, the real-time process is disconnected from the ready queue and connected to the wait queue.On the other hand, in the proposed control, the release element is only disconnected from the execution management table. In addition, the release element of the real-time process being executed is at the top of the entry with its priority. Therefore, the processing time for the wait is short, and this value is fixed without affecting the number of the real-time processes in the wait queue and the waiting time of each real-time process.3. The adverse effect of a real-time process that could not be completely processed before thenext release time on the other real-time processes is restrained.In ART-Linux, the execution of the real-time process continues periodically even if the execution is not completed before the next release time. On the other hand, in the proposed control, if there is a release element of the real-time process still to be executed in the current entry as a release at the next release time, this real-time process is terminated. In other words, a real-time process that is not completely processed before the next release time is terminated. Therefore, the influence of such a real-time process on the other real-time processes is restrained.4. The dispersion of the processing time for the release is small.In the proposed control, for registration, when the release element is connected to the periodic control table, the periodic control table is searched, an entry managing few release elements in the periodic control table is found, and the release element of the real-time process is connected to this entry. Therefore, the dispersion for the number of release elements being connected to each entry of the periodic control table becomes low. Hence, when there are real-time processes with different periods, the dispersion of the processing time for a release becomes small. As a result, the dispersion of the time from the timer interrupt to the execution of a real-time process becomes small.974. Evaluation4.1. AnT operating systemWe have implemented and evaluated the proposed control in AnT [7][8]. AnT is an operating system based on microkernel architecture. The basic architecture of AnT is shown in figure 8. The program consists of OS and service. The OS comprises the kernel, which is called as the internal core, and the external core, which is executed as processes (OS server). Service consists of AP processes that execute the applications program. The internal core is the program part that guarantees the execution for a minimum number of common functions in all the systems. As the main function, the internal core has functions of scheduling management and memory management. The external core is the necessary program part to adapt to the use cases of the systems, it has a dynamically reconfigurable structure. For example, AnT offers the functions of input/output control, file management, and device driver as processes. Service is the program part that offers services.AnT has the following characteristics: fast inter-server program communication mechanism, process control mechanism for dynamic running mode switch, adaptive-control function, and dynamic OS server replacement mechanism. The fast inter-server program communication mechanism offers high-speed communication control using copy-less data transfer, protection of the transfer data and provision of interface that adapted to the use case of the systems [8]. The dynamic running mode switch mechanism is mechanism that can switch the running mode of a process dynamically and freely. The adaptive-control function dynamically changes the software function and structure to adapt to the use case of the system. The dynamic OS server replacement mechanism allows us to continue the service without stopping the operating system when the OS server is extended or when the OS server is malfunctioning.4.2. Evaluation itemsWe have clarified the effects of the proposed control by comparison of AnT and ART-Linux. We evaluated the following.1. The processing time of the release when there are a large number of real-time processesscheduled to be released at the same time2. The processing time of the wait when there are a large number of real-time processes inthe wait state3. The dispersion for the number of real-time processes to be released at the same time98。
1.TDP--Thermal Design Power 散热设计功耗2.SMBus ---System Management Bus 系统总线3.GPIO---General Purpose Input Output 通用输入/输出或总线扩展器4.SIO--超级输入输出芯片5.SO-DIMM--小外形双列内存模组6.DIMM--Dual-Inline-Memory-Modules,即双列直插式存储模块7.SPI--Serial Peripheral Interface--串行外设接口8.IDE--微型计算机智能接口,是现在普遍使用的外部接口,主要接硬盘和光驱,传输模式有以下三种:PIO(Programmed I/O)模式、DMA(Driect Memory Access)模式、Ultra DMA(简称UDMA)模式9.AMT---主动管理技术10.POST--通电自检程序11.HDMI--High Definition Multimedia Interface高清晰度多媒体接口12.CRT ---Cathode Ray Tube 阴极射线管13.DAC --Digital Analog Converter 数模转换器14.DDC --Display Data Channel—I2C bus interface between a display and a graphics adapter. 显示数据通道15.DVI --Digital Visual Interface —video interface standard developed by the Digital Display Working Group (DDWG). 数字可视化界面16.EFT --Electrical Fast Transient 电快速瞬变17.EMI --Electro magnetic Interference 电磁干扰18.ESD --Electrostatic Discharge 静电放电19.ExpressCard--A PCMCIA standard built on the latest USB 2.0 and PCI Express buses.20.GBE --Gigabit Ethernet 千兆以太网21.LPC-- Low Pin-Count Interface: a low speed interface used for peripheral circuits such as Super I/O controllers, which typically combine legacy-device support into a single IC. 低针脚数接口22.LVDS --Low-Voltage Differential Signaling 低压差分信号23.PCI Express (PCIe)--Peripheral Component Interface Express – next-generation high speed Serialized I/O bus24.PCI Express Lane --One PCI Express Lane is a set of 4 signals that contains two differential lines for Transmitter and two differential lines for Receiver. Clocking information is embedded into the data stream.25.SATA --Serial ATA attachment: serial-interface standard for hard disks26.SDVO --Serial Digital Video Out— proprietary technology introduced by Intel. to add additional video signaling interfaces to a system. 连续数字式录影27.T.B.D. --To be determinedB --Universal Serial Bus29.x1, x2, x4, x16 x1 refers to one PCI Express Lane of basic bandwidth; x2 to acollection of two PCI Express Lanes; etc.. Also referred to as x1, x2, x4, x16 link.30.ASIC(专用集成电路)Application-Specific Integrated Circuit. A piece of custom-designed hardware in a chip. 专用集成电路。
软考中级嵌入式系统需掌握的英语词汇一、嵌入式系统基础1. 嵌入式系统:Embedded System2. 硬件:Hardware3. 软件:Software4. 固件:Firmware5. 系统软件:System Software6. 应用软件:Application Software7. 实时操作系统:Real-Time Operating System (RTOS)二、微控制器原理1. 微控制器:Microcontroller2. 中央处理器:Central Processing Unit (CPU)3. 存储器:Memory4. 输入/输出接口:Input/Output Interface5. 时钟系统:Clock System6. 中断:Interrupt7. 外设:Peripheral三、ARM架构与编程1. ARM架构:ARM Architecture2. ARM指令集:ARM Instruction Set3. ARM汇编语言:ARM Assembly Language4. ARM链接器:ARM Linker5. ARM工具链:ARM Toolchain6. ARM Cortex系列:ARM Cortex Series7. ARM内存管理单元:ARM Memory Management Unit (MMU)四、实时操作系统1. 实时操作系统:Real-Time Operating System (RTOS)2. 任务调度:Task Scheduling3. 信号量:Semaphore4. 消息队列:Message Queue5. 内存管理:Memory Management6. 中断处理:Interrupt Handling7. 时间管理:Time Management五、低功耗设计1. 低功耗设计:Low Power Design2. 待机模式:Standby Mode3. 休眠模式:Sleep Mode4. 唤醒机制:Wake-up Mechanism5. 能效比:Energy Efficiency Ratio6. 功率优化:Power Optimization7. 低功耗电路设计:Low Power Circuit Design六、传感器与信号处理1. 传感器:Sensor2. 模拟信号:Analog Signal3. 数字信号:Digital Signal4. 信号调理:Signal Conditioning5. 采样率:Sampling Rate6. 滤波器:Filter7. 数据转换器:Data Converter8. 信号处理算法:Signal Processing Algorithm9. 特征提取:Feature Extraction10. 信号分析:Signal Analysis11. 噪声抑制:Noise Suppression12. 数据融合:Data Fusion13. 动态范围:Dynamic Range14. 量程:Range of Measurement。
嵌入式系统嵌入式系统是一种设计用来执行一种或几种功能的实时计算机系统。
它被嵌入于一个完整的包括硬件和机械装置的设备中。
与传统计算机,例如个人电脑相比,他的设计更灵活应用更广泛。
在今天由嵌入式系统控制的设备很普遍。
历史第一个被大家认可的现代嵌入式系统是麻省理工学院仪器研究室的查尔斯·斯塔克·德雷珀开发的阿波罗导航计算机。
在两次月球飞行中他们在太空驾驶舱和月球登陆舱都是用了这种惯性导航系统。
在计划刚开始的时候,阿波罗导航计算机被认为是阿波罗计划风险最大的部分。
为了减小尺寸和重量而使用的当时最新的单片集成电路加大了阿波罗计划的风险。
第一款大批量生产的嵌入式系统是1961年发布的民兵I导弹上的D-17自动导航控制计算机。
它是由独立的晶体管逻辑电路建造的,它带有一个作为主内存的硬盘。
当民兵II导弹在1966年开始生产的时候,D-17由第一次使用大量集成电路的更新计算机所替代。
仅仅这个项目就将与非门集成电路模块的价格从每个1000美元降到低了每个3美元,使集成电路的商用成为可能。
民兵导弹的嵌入式计算机有一个重要的设计特性:它能够在项目后期对制导算法重新编程以获得更高的导弹精度,并且能够使用计算机测试导弹,从而减少测试用电缆和接头的重量。
这些二十世纪六十年代的早期应用,使嵌入式系统得到长足发展,它的价格开始下降,同时处理能力和功能也获得了巨大的提高。
英特尔4004是第一款微处理器,它在计算器和其他小型系统中找到了用武之地。
但是,它仍然需要外部存储设备和外部支持芯片。
1978年,国家工程制造商协会发布了可编程微控制器的“标准”,包括几乎所有以计算机为基础的控制器,如单片机,数控设备,以及基于事件的控制器。
随着微控制器和微处理器的价格下降,一些消费性产品用使用微控制器的数字电路取代如分压计和可变电容这样的昂贵模拟组件成为可能。
到了二十世纪八十年代中期,许多以前是外部系统的组件被集成到了处理器芯片中,这种结构的微处理器得到了更广泛的应用。
嵌入式常用英语词汇English: Some common terminology used in embedded systems include:1. Microcontroller: A small computer on a single integrated circuit that contains a processor core, memory, and programmableinput/output peripherals.2. Firmware: Software that is embedded in a hardware device to control its operation and functionality.3. Real-time Operating System (RTOS): An operating system that is designed to serve real-time applications that process data as it comes in, typically without buffering delays.4. Embedded Software: Software that is written to control the functions of a specific hardware device.5. Bootloader: A small program that loads the operating system into the computer's memory during the boot-up process.6. Debugging: The process of finding and fixing errors or bugs withina software program or system.7. Embedded System Design: The process of creating a system that is implemented in electronic hardware and software.8. Sensor: A device that detects and responds to some type of input from the physical environment.9. Actuator: A component of a machine that is responsible for moving or controlling a mechanism or system.10. I/O Interface: The point of connection between a computer and other devices, such as input/output devices or a network.中文翻译:嵌入式系统中常用的术语包括:1. 微控制器:一种集成了处理器核心、内存和可编程输入/输出外围设备的单一集成电路上的小型计算机。
毕业设计外文资料翻译(译文)题目名称:Embedded Linux applications: An overview学院:计算机科学技术专业年级:计算机科学与技术07级学生姓名:xx班级学号: 1班 16号指导教师:xx二○一一年四月十日译文题目:Embedded Linux applications: An overview原文题目:嵌入式 Linux 应用:概述原文出处:Internet source : /developer- -works/cn/linux/embed/embl/overview/index.htmlEmbedded Linux applications: An overviewLinux now spans the spectrum of computing applications, including IBM's tiny Linux wrist watch, hand-held devices (PDAs and cell phones), Internet appliances, thin clients, firewalls, industrial robotics, telephony infrastructure equipment, and even cluster-based supercomputers. Let's take a look at what Linux has to offer as an embedded system, and why it's the most attractive option currently available.One. Emergence of embedded systemsThe computers used to control equipment, otherwise known as embedded systems, have been around for about as long as computers themselves. They were first used back in the late 1960s in communications to control electromechanical telephone switches. As the computer industry has moved toward ever smaller systems over the past decade or so, embedded systems have moved along with it, providing more capabilities for these tiny machines. Increasingly, these embedded systems need to be connected to some sort of network, and thus require a networking stack, which increases the complexity level and requires more memory and interfaces, as well as, you guessed it, the services of an operating system.Off-the-shelf operating systems for embedded systems began to appear in the late 1970s, and today several dozen viable options are available. Out of these, a few major players have emerged, such as VxWorks, pSOS, Neculeus, and Windows CE.Two. Advantages/disadvantages of using Linux for your embedded systemAlthough most Linux systems run on PC platforms, Linux can also be a reliable workhorse for embedded systems. The popular "back-to-basics" approach of Linux, which makes it easier and more flexible to install and administer than UNIX, is an added advantage for UNIX gurus who already appreciate the operating system because it has many of the same commands and programming interfaces as traditional UNIX.The typical shrink-wrapped Linux system has been packaged to run on a PC, with a hard disk and tons of memory, much of which is not needed on an embedded system. A fully featured Linux kernel requires about 1 MB of memory. However, the Linux micro-kernel actually consumes very little of this memory, only 100 K on a Pentium CPU, including virtual memory and all core operating system functions. With the networkingstack and basic utilities, a complete Linux system runs quite nicely in 500 K of memory on an Intel 386 microprocessor, with an 8-bit bus (SX). Because the memory required is often dictated by the applications needed, such as a Web server or SNMP agent, a Linux system can actually be adapted to work with as little as 256 KB ROM and 512 KB RAM. So it's a lightweight operating system to bring to the embedded market.Another benefit of using an open source operating system like Embedded Linux over a traditional real-time operating system (RTOS), is that the Linux development community tends to support new IP and other protocols faster than RTOS vendors do. For example, more device drivers, such as network interface card (NIC) drivers and parallel and serial port drivers, are available for Linux than for commercial operating systems.The core Linux operating system itself has a fairly simple micro-kernel architecture. Networking and file systems are layered on top of the micro-kernel in modular fashion. Drivers and other features can be either compiled in or added to the kernel at run-time as loadable modules. This provides a highly modular building-block approach to constructing a custom embeddable system, which typically uses a combination of custom drivers and application programs to provide the added functionality.An embedded system also often requires generic capabilities, which, in order to avoid re-inventing the wheel, are built with off-the-shelf programs and drivers, many of which are available for common peripherals and applications. Linux can run on most microprocessors with a wide range of peripherals and has a ready inventory of off-the-shelf applications.Linux is also well-suited for embedded Internet devices, because of its support of multiprocessor systems, which lends it scalability. This capability gives a designer the option of running a real-time application on a dual processor system, increasing total processing power. So you can run a Linux system on one processor while running a GUI, for example, simultaneously on another processor.The one disadvantage to running Linux on an embedded system is that the Linux architecture provides real-time performance through the addition of real-time software modules that run in the kernel space, the portion of the operating system that implements the scheduling policy, hardware-interrupts exceptions and program execution. Since these real-time software modules run in the kernel space, a code error can impact the entire system's reliability by crashing the operating system, which can be a very serious vulnerability for real-time applications.An off-the-shelf RTOS, on the other hand, is designed from the ground up for real-time performance, and provides reliability through allocating certain processes a higher priority than others when launched by a user as opposed to by system-level processes. Processes are identified by the operating system as programs that execute inmemory or on the hard drive. They are assigned a process ID or a numerical identifier so that the operating system may keep track of the programs currently executing and of their associated priority levels. Such an approach ensures a higher reliability (predictability) with the RTOS time than Linux is capable of providing. But all-in-all, it's still a more economical choice.Three. Different types of Embedded Linux systemsThere are already many examples of Embedded Linux systems; it's safe to say that some form of Linux can run on just about any computer that executes code. The ELKS (Embeddable Linux Kernel Subset) project, for example, plans to put Linux onto a Palm Pilot. Here are a couple of the more well-known small footprint Embedded Linux versions:ETLinux -- a complete Linux distribution designed to run on small industrial computers, especially PC/104 modules.LEM -- a small (<8 MB) multi-user, networked Linux version that runs on 386s.LOAF -- "Linux On A Floppy" distribution that runs on 386s.uClinux -- Linux for systems without MMUs. Currently supports Motorola 68K, MCF5206, and MCF5207 ColdFire microprocessors.uLinux -- tiny Linux distribution that runs on 386s.ThinLinux -- a minimized Linux distribution for dedicated camera servers, X-10 controllers, MP3 players, and other such embedded applications.Software and hardware requirementsSeveral user-interface tools and programs enhance the versatility of the Linux basic kernel. It's helpful to look at Linux as a continuum in this context, ranging from a stripped-down micro-kernel with memory management, task switching and timer services to a full-blown server supporting a complete range of file system and network services.A minimal Embedded Linux system needs just three essential elements:∙ A boot utility∙The Linux micro-kernel, composed of memory management, process management and timing services∙An initialization processTo doing anything useful while remaining minimal, you also need to add:∙Drivers for hardware∙One or more application processes to provide the needed functionalityAs additional requirements become necessary, you might also want:∙ A file system (perhaps in ROM or RAM)∙TCP/IP network stack∙ A disk for storing semi-transient data and swap capability∙ A 32-bit internal CPU (required by all complete Linux systems)Four. Hardware platform optionsChoosing the best hardware can be complex because of internal company politics, prejudices, legacies of other projects, a lack of complete or accurate information, and cost, which should take into account the total product costs and not just the CPU itself. Sometimes a fast, inexpensive CPU can become expensive once bus logic and the delays necessary to make it work with other peripherals are considered. To calculate the necessary speed of a CPU for any given project, start with a realistic view of how fast the CPU needs to run to accomplish a given task and triple it. Also, determine how fast the bus needs to run. If there are secondary buses, such as a PCI bus, consider them also. A slow bus (that is, one that is saturated with DMA traffic) can significantly slow down a fast CPU. Here are some of the best hardware solutions for Embedded Linux applications.Bright Star Engineering: Bright Star Engineering's ipEngine-1 is a credit-card sized single-board computer with Embedded Linux support. It utilizes a PowerPC-based CPU and provides an array of on-board peripherals, including Ethernet, LCD/Video Controller, USB, Serial I/O, and a 16K gate user-configurable FPGA. BSE's Embedded Linux configuration allows Linux to be booted from the ipEngine's on-board 4MB flash memory.Calibri: CalibriTM-133 is a ready-to-use, compact, multipurpose network appliance that uses Embedded Linux as its operating system. It offers a highly efficient and low-cost solution to firewall, VPN, and routing demands.EmbeddedPlanet: EmbeddedPlanet has created a PostPC-era computer that comes loaded with MontaVista's HardHat Linux. Powered by a PowerPC-based computing engine and matching I/O card, Linux Planet comes in a colorful translucent case with a touchscreen and access to digital and analog I/O.Eurotech: Eurotech provides embedded PC SBC and sponsors ET-Linux, a complete Linux system designed to run on small industrial computers and based on glibc 2.1.2.Microprocess Ingenierie: Microprocess develops, produces, and sells standard and customized products for the industrial and embedded market. Microprocess has a global activity in real-time software and great expertise in systems integration. Its products, like the 740 PowerPC compactPCI board, can be ordered with a standard distribution of Linux or an Embedded Linux version.Moreton Bay: Moreton Bay is releasing their NETtel 2520 and NETtel 2500 rangeof Linux-based Internet routers. These small, easy-to-connect intelligent router solutions are engineered to offer a simple, secure, and affordable extranet-friendly Virtual Private Network (VPN) for flat networks. The NETtel router family runs an Embedded Linux kernel. A development kit is available; it enables customized code to be stored in flash memory and executed inside the NETtel. The code may contain special encryption or authentication protocols, or some local monitoring script where NETtel is used as a remote control device.Matrix Orbital: This an optional, but not recommended, addition. Matrix Orbital manufactures a line of serial LCDs and VFDs, which many Linux users are including in their embedded systems. The product line ranges from 8x2 to 40x4 character LCDs, 20x2 and 20x4 VFDs, plus a 240x64 graphic LC (128x128 on the way). Communication with the displays is accomplished via either RS232 or I2C, both of which are standard on all of their modules. A comprehensive command set is included in the modules' BIOS.Five. Real-time Embedded Linux applicationsOne of the most important issues with embedded systems is the need for a real-time operating system. The definition of real-time here varies quite a bit. To some people, real-time means responding to an event in the one-microsecond range, to others it is 50 milliseconds. The hardness of real-time also varies quite a bit. Some systems need hard real-time response, with short deterministic response latencies to events. However, on many systems, when analyzed closely, we see a response time requirement that is actually near real-time. Often the real-time requirement is a tradeoff of time and buffer space. With memory getting cheaper, and CPUs getting faster, near real-time is now more typical than hard real-time and many commercial operating systems that claim to be real-time are far from being hard real-time. Usually, when you get into the detailed design of these systems, there are warnings that the drivers' interrupts and applications must be very carefully designed in order to meet real-time requirements.RT-Linux (Linux with real-time extensions) contains time critical functions to provide precise control over interrupt handling, through the use of an interrupt manager, and does a good job of making sure that critical interrupts get executed when needed. The hardness of this approach depends mostly on the CPU interrupt structure and context-switch hardware support. This approach is sufficient for a large range of real-time requirements. Even without the real-time extensions, Linux does pretty well at keeping up with multiple streams of events. For example, a Linux PC system on a low end Pentium is able to keep multiple 10BaseT interfaces executing effectively, while simultaneously running character-level serial ports at a full 56KBPS without losing any data.Some real-time hardware and software Linux APIs to consider are RTLinux, RTAI, EL, and Linux-SRT. RTLinux is a hard real-time Linux API originally developed at the New Mexico Institute of Technology. RTAI (DIAPM) is a spin-off of the RTLinux real-time API that was developed by programmers at the Department of Aerospace Engineering, Polytechnic Politecnico di Milano (DIAPM). EL/IX is a proposed POSIX-based hard real-time Linux API being promoted by Red Hat. And Linux-SRT is a soft real-time alternative to real-time APIs, which provides performance-enhancing capabilities to any Linux program without requiring that the program be modified or recompiled.See the Resources section later in this article for information on the above and for some Web sites offering different flavors of software extensions, development tools, support, and training courses for the standard Linux operating system.Short deterministic response latenciesSome real-time embedded systems need to respond quickly to external events in order to accomplish a specific task. A custom microcontroller embedded inside a missile, for example, needs to respond quickly to external events such as moving targets, weather, humans, etc., before instructing the missile to target a specific object in its surrounding environment. Short deterministic response latencies mean that the embedded system can determine the time it will take to respond to an external event.Six. Configuration proceduresNow let's take a look at how to make LEM, a small, embeddable Linux distribution, which provides both network and X server. You can download this distribution, although it is not essential. You will need a full Linux distribution to build your own Embedded Linux operating system, which will contain everything you need (utilities, sources, compiler, debugger, and documentation). Here is a list of the software that can be used to make LEM:TinyLogin: TinyLogin is a suite of tiny UNIX utilities for handling logging into, being authenticated by, changing one's password for, and otherwise maintaining users and groups on an embedded system. It also provides shadow password support to enhance system security. TinyLogin is, as the name implies, very small, and makes an excellent complement to BusyBox on an embedded System.BusyBox: BusyBox is a multicall binary used to provide a minimal subset of POSIX-style commands and specialized functions. It is geared toward the very small, such as boot floppies, embedded systems, etc. Specifically it is used in the Debian Rescue/Install system (which inspired development on the original BusyBox ), the Linux Routeur Project, LEM, lineo, and others. Busybox is being maintained by Erik Andersen.Ash: Ash is a very small Bourne shell.Sysvinit: Sysvinit is the most used init package for Linux. We will use init and the C version of the start-stop-daemon.See the Resources section for more information on these items.Seven. Creating a bootdiskA bootdisk is basically a miniature, self-contained Linux system on a floppy diskette. It can perform many of the same functions that a complete full-size Linux system performs. The following material is based on the Bootdisk-HOWTO (see Resources).Step 1. BiosAll PC systems start the boot process by executing code in ROM (specifically, the BIOS) to load the sector from sector 0, cylinder 0 of the boot drive. The boot drive is usually the first floppy drive (designated A: in DOS and /dev/fd0 in Linux). The BIOS then tries to execute this sector. On most bootable disks, sector 0, cylinder 0 contains either: ∙Code from a boot loader such as LILO, which locates the kernel, loads it, and executes it to start the boot proper∙The start of an operating system kernel, such as LinuxIf a Linux kernel has been raw copied to a diskette, a hard drive, or another media, the first sector of the disk will be the first sector of the Linux kernel itself. This first sector will continue the boot process by loading the rest of the kernel from the boot device.Step 2. The boot loaderYou will use a boot loader like LILO to operate the boot process. It allows the development and production platforms to co-exist on the same hardware and permits switching from one to the other just by rebooting. The LILO boot loader is loaded by the bios. It then loads kernels or the boot sectors of other operating systems. It also provides a simple command line interface to interactively select the item to boot with its options. See Resources for more information on LILO.Step 3. The kernelThe kernel checks the hardware and mounts the root device and then looks for the init program on the root filesystem and executes it.Step 4. InitInit is the parent of all other processes that will run on your Linux OS. It will watch its child processes and start, stop, re-launch them if needed. Init takes all information from /etc/inittab.Step 5. InittabThe file /etc/inittab/ refers to scripts named /etc/rc... to do the system setup. It also hasentries for the getty tool to handle the login process.Step 6. The login processThere is one getty available in the inittab file for each console allowed for the users. Getty will launch /bin/login to verify the user password.Step 7. Creating a new partitionFrom the LFS-HOWTO (see Resources): Before we can build our new Linux system, we need to have an empty Linux partition on which we can build our new system. If you already have a Linux Native partition available, you can skip this step and the following one. Start the fdisk program (or cfdisk if you prefer that program) with the appropriate hard disk as the option (like /dev/hda if you want to create a new partition on the primary master IDE disk). Create a Linux Native partition, write the partition table, and exit the (c)fdisk program. If you get the message that you need to reboot your system to ensure that the partition table is updated, then please reboot your system now before continuing.Step 8. Creating an ext2 file system on the new partitionFrom the LFS-HOWTO (see Resources): To create a new ext2 file system we use the mke2fs command. Give $LFS as the only option, and the file system will be created. From now on I'll refer to this newly created partition as $EMBPART. $EMBPART should be substituted with the partition you have created.Step 9. Mounting the partitionTo access the newly created filesystem, you have to mount it. To do this, create an /mnt/hda? directory and type the following at the shell prompt:mkdir /mnt/hda?mount $EMBPART /mnt/hda?If you created your partition on /dev/hda4 and you mounted it on /mnt/hda4, then you'll need to return to the step where you copied a file to $dollar;EMBPART/usr/sbin, and copy that file to /mnt/hda4/usr/bin. Do this after the last command in Step 14 (Copy the file in $EMBPART/usr/sbin).Step 10. Populating the filesystemThe root filesystem must contain everything needed to support a full Linux system. We will build a directory structure not that far from the File Hierarchy Standard (see Resources).Step 11. DirectoriesThe mkdir function in the new mounted filesystem creates the following directories: /procDirectory stub required by the proc filesystem/etcSystem configuration file/sbinCritical System binaries/binBasic binaries considered part of the system/libShared Libraries to provide run-time support/mntMount point for maintenance/usrAdditional utilities and applications∙cd /mnt/hda?∙mkdir bin dev home proc sbin usr boot etc liv mnt root tmp var∙mkdir -p usr/bin usr/sbin usr/share usr/lib∙mkdir -p etc/config etc/default etc/init.d etc/rc.boot∙mkdir -p etc/rc0.d etc/rc1.d etc/rc2.d etc/rc3.d etc/rc4.d etc/rc5.d etc/rc6.d etc/rcS.d/devThe dev directory is the stub required to perform devices input / output. Each file in this directory may be created using the mknod function. You may save time by directly copying the required dev entries from your desktop Linux, using the following instruction: cp -dpR /dev /mntEight. Installing TinyLogin and login dependenciesTinyLogin (see the Resources section to install it) will give us the following tools in less than 35Kb:/bin/addgroup, /bin/adduser, /bin/delgroup, /bin/deluser, /bin/login, /bin/su, /sbin/getty, /sbin/sulogin, /usr/bin/passwd.Please refer to your main distribution doc or man pages for a full description of those commands.Step 12. Configuring TinyLoginFrom the TinyLogin README: TinyLogin is modularized to help you build only the components you need, thereby reducing binary size. To turn off unwanted TinyLogin components, simply edit the file tinylogin.def.h and comment out the parts you do not want using C++ style (//) comments.Step 13. Installing TinyLoginAfter the build is complete, a tinylogin.links file is generated, which is then used by make install to create symlinks to the tinylogin binary for all compiled-in functions. By default, make install will place a symlink forest into pwd /_install unless you have defined thePREFIX environment variable.Step 14. Installing Sysvinit and start-stop daemonAfter the kernel is done loading, it tries to run the init program to finalize the boot process. Now:1.Unpack the Sysvinit archive2.Go to the src directory3.Copy the init executable in $EMBPART/sbinThe Sysvinit package also offers a C version of the start-stop-daemon in the contrib directory.pile it2.Copy the file in $EMBPART/usr/sbinStep 15. Configuring SysvinitSysvinit needs a configuration file named inittab, which should be placed in $EMBPART/etc. Here is the one used in the LEM distribution:# /etc/inittab: init(8) configuration.# $Id: inittab,v 1.6 1997/01/30 15:03:55 miquels Exp $# Modified for LEM 2/99 by Sebastien HUET# default rl.id:2:initdefault:# first except in emergency (-b) mode.si::sysinit:/etc/init.d/rcS# single-user mode.~~:S:wait:/sbin/sulogin# /etc/init.d executes the S and K scripts upon change# 0:halt 1:single-user 2-5:multi-user (5 may be X with xdm or other) 6:reboot.l0:0:wait:/etc/init.d/rc 0l1:1:wait:/etc/init.d/rc 1l2:2:wait:/etc/init.d/rc 2l3:3:wait:/etc/init.d/rc 3l4:4:wait:/etc/init.d/rc 4l5:5:wait:/etc/init.d/rc 5l6:6:wait:/etc/init.d/rc 6# CTRL-ALT-DEL pressed.ca:12345:ctrlaltdel:/sbin/shutdown -t1 -r now# Action on special keypress (ALT-UpArrow).kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."# /sbin/mingetty invocations for runlevels.1:2345:respawn:/sbin/getty 9600 tty12:23:respawn:/sbin/getty 9600 tty2#3:23:respawn:/sbin/getty tty3 #you may add console there#4:23:respawn:/sbin/getty tty4Step 16. Creating initial boot scriptsAs seen in the inittab file, Sysvinit needs additional scripts in its own directories.Step 17. Creating the necessary directories and base filesUse the following command to create the directories:cd $EMBPART/etcmkdir rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d init.d rcS.d rc.bootGo to the unpacked Sysvinit source directoryCopy the debian/etc/init.d/rc to:$EMBART/etc/init.dGo to the $EMBPART/etc/init.d/Create a new file rcS like those in LEM:#!/bin/shPATH=/sbin:/bin:/usr/sbin:/usr/binrunlevel=Sprevlevel=Numask 022export PATH runlevel prevlevel/etc/default/rcSexport VERBOSE# Trap CTRL-C only in this shell so we can interrupt subprocesses.trap ":" 2 3 20# Call all parts in order.for i in /etc/rcS.d/S??*do[ ! -f "$i" ] && continuecase "$i" in*.sh)(trap - 2 3 20. $i start);;*)$i start;;esacdone# run the files in /etc/rc.boot[ -d /etc/rc.boot ] && run-parts /etc/rc.bootCopy run-parts from your distro to $EMBPART/bin.Step 18. Adding base scriptsA lot of the commands being used here are UNIX/Linux commands that set, export, etc. paths that are embedded inside of a UNIX shell script.<!-reboot---------------------------------------------->Create a new file reboot containing the following:#!/bin/shPATH=/sbin:/bin:/usr/sbin:/usr/binecho -n "Rebooting... "reboot -d -f -i<!-halt---------------------------------------------->Create a new file halt containing the following:#!/bin/shPATH=/sbin:/bin:/usr/sbin:/usr/binhalt -d -f -i -p<!-mountfs---------------------------------------------->Nine. SummaryThe Linux operating system has a very bright future in the area of embedded applications for anything from Internet appliances to dedicated control systems. Roughly 95% of all newly manufactured microcomputer chips are used for embedded applications. The power, reliability, flexibility, and scalability of Linux, combined with its support for a multitude of microprocessor architectures, hardware devices, graphics support, and communications protocols have established Linux as an increasingly popular software platform for a vast array of projects and products.Because Linux is openly and freely available in source form, many variations and configurations of Linux and its supporting software components have evolved to meet the diverse needs of the markets and applications to which Linux is being adapted. There are small footprint versions and real-time enhanced versions. Despite the origins of Linux asa PC architecture operating system, there are now ports to numerous non-x86 CPUs, with and without memory management units, including PowerPC, ARM, MIPS, 68K, and even microcontrollers. But look out, there's more coming in the near future for many other Information Technology (IT) domains!嵌入式Linux 应用:概述现在Linux 广泛用于各类计算应用,不仅包括IBM 的微型Linux 腕表、手持设备(PDA 和蜂窝电话)、因特网装置、瘦客户机、防火墙、工业机器人和电话基础设施设备,甚至还包括了基于集群的超级计算机。
1.TDP--Thermal Design Power 散热设计功耗2.SMBus ---System Management Bus 系统总线3.GPIO---General Purpose Input Output 通用输入/输出或总线扩展器4.SIO--超级输入输出芯片5.SO-DIMM--小外形双列内存模组6.DIMM--Dual-Inline-Memory-Modules,即双列直插式存储模块7.SPI--Serial Peripheral Interface--串行外设接口8.IDE--微型计算机智能接口,是现在普遍使用的外部接口,主要接硬盘和光驱,传输模式有以下三种:PIO(Programmed I/O)模式、DMA(Driect Memory Access)模式、Ultra DMA(简称UDMA)模式9.AMT---主动管理技术10.POST--通电自检程序11.HDMI--High Definition Multimedia Interface高清晰度多媒体接口12.CRT ---Cathode Ray Tube 阴极射线管13.DAC --Digital Analog Converter 数模转换器14.DDC --Display Data Channel—I2C bus interface betweena display and a graphics adapter. 显示数据通道15.DVI --Digital Visual Interface —video interface standard developed by the Digital Display Working Group (DDWG). 数字可视化界面16.EFT --Electrical Fast Transient 电快速瞬变17.EMI --Electro magnetic Interference 电磁干扰18.ESD --Electrostatic Discharge 静电放电19.ExpressCard--A PCMCIA standard built on the latest USB 2.0 and PCI Express buses.20.GBE --Gigabit Ethernet 千兆以太网21.LPC-- Low Pin-Count Interface: a low speed interface used for peripheral circuits such as Super I/O controllers, which typically combine legacy-device support into a single IC. 低针脚数接口22.LVDS --Low-Voltage Differential Signaling 低压差分信号23.PCI Express (PCIe)--Peripheral Component Interface Express – next-generation high speed Serialized I/O bus 24.PCI Express Lane --One PCI Express Lane is a set of 4 signals that contains two differential lines for Transmitter and two differential lines for Receiver. Clocking information is embedded into the data stream.25.SATA --Serial ATA attachment: serial-interface standard for hard disks26.SDVO--Serial Digital Video Out—proprietary technology introduced by Intel. to add additional video signaling interfaces to a system. 连续数字式录影27.T.B.D. --To be determinedB --Universal Serial Bus29.x1, x2, x4, x16 x1 refers to one PCI Express Lane of basic bandwidth; x2 to acollection of two PCI Express Lanes; etc.. Also referred to as x1, x2, x4, x16 link.30.ASIC(专用集成电路)Application-Specific Integrated Circuit. A piece of custom-designed hardware in a chip. 专用集成电路。
6.1 ConclusionsAutonomous control for small UAVs imposes severe restrictions on the control algorithmdevelopment, stemming from the limitations imposed by the on-board hardwareand the requirement for on-line implementation. In this thesis we have proposed anew hierarchical control scheme for the navigation and guidance of a small UAV forobstacle avoidance. The multi-stage control hierarchy for a complete path control algorithmis comprised of several control steps: Top-level path planning,mid-level pathsmoothing, and bottom-level path following controls. In each stage of the control hierarchy,the limitation of the on-board computational resources has been taken intoaccount to come up with a practically feasible control solution. We have validatedthese developments in realistic non-trivial scenarios.In Chapter 2 we proposed a multiresolution path planning algorithm. The algorithmcomputes at each step a multiresolution representation of the environment usingthe fast lifting wavelet transform. The main idea is to employ high resolution closeto the agent (where is needed most), and a coarse resolution at large distances fromthe current location of the agent. It has been shown that the proposed multiresolutionpath planning algorithm provides an on-line path solution which is most reliableclose to the agent, while ultimately reaching the goal. In addition, the connectivityrelationship of the corresponding multiresolution cell decomposition can be computed directly from the the approximation and detail coefficients of the FLWT. The path planning algorithm is scalable and can be tailored to the available computational resources of the agent.The on-line path smoothing algorithm incorporating the path templates is presentedin Chapter 3. The path templates are comprised of a set of B-spline curves,which have been obtained from solving the off-line optimization problem subject tothe channel constraints. The channel is closely related to the obstacle-free high resolutioncells over the path sequence calculated from the high-level path planner. Theobstacle avoidance is implicitly dealt with since each B-spline curve is constrainedto stay inside the prescribed channel, thus avoiding obstacles outside the channel.By the affine invariance property of B-spline, each component in the B-spine pathtemplates can be adapted to the discrete path sequence obtained from thehigh-levelpath planner. We have shown that the smooth reference path over the entire pathcan be calculated on-line by utilizing the path templates and path stitching scheme. The simulation results with the D_-lite path planning algorithm validates the effectivenessof the on-line path smoothing algorithm. This approach has the advantageof minimal on-line computational cost since most of computations are done off-line.In Chapter 4 a nonlinear path following control law has been developed for asmall fixed-wing UAV. The kinematic control law realizes cooperative path followingso that the motion of a virtual target is controlled by an extra control input to helpthe convergence of the error variables. We applied the backstepping to derive theroll command for a fixed-wing UAV from the heading rate command of the kinematiccontrol law. Furthermore, we applied parameter adaptation to compensatefor theinaccurate time constant of the roll closed-loop dynamics. The proposed path followingcontrol algorithm is validated through a high-fidelity 6-DOF simulation of a fixed-wing UAV using a realistic sensor measurement, which verifies the applicabilityof the proposed algorithm to the actual UAV.Finally, the complete hierarchical path control algorithm proposed in this thesis isvalidated thorough a high-fidelity hardware-in-the-loop simulation environment usingthe actual hardware platform. From the simulation results, it has been demonstratedthat the proposed hierarchical path control law has been successfully applied for pathcontrol of a small UAV equipped with an autopilot that has limited computational resources.6.2 Future ResearchIn this section, several possible extensions of the work presented in this thesis are outlined.6.2.1 Reusable graph structure The proposed path planning algorithm involves calculating the multiresolution cell decomposition and the corresponding graph structure at each of iteration. Hence, the connectivity graph G(t) changes as the agent proceeds toward the goal. Subsequently, let x 2 W be a state (location) which corresponds to nodes of two distinct graphs as followsBy the respective A_ search on those graphs, the agent might be rendered to visit x at different time steps of t i and t j , i 6= j. As a result, a cyclic loop with respect to x is formed for the agent to repeat this pathological loop, while never reaching the goal. Although it has been presented that maintaining a visited set might be a means of avoiding such pathological situations[142], it turns out to be a trial-and-error scheme is not a systemical approach. Rather, suppose that we could employ a unified graph structure over the entire iteration, which retains the information from the previous search. Similar to the D_-lite path planning algorithm, the incremental search over the graph by reusing the previous information results in not only overcoming the pathological situation but also reducing the computational time. In contrast to D_ orD_-lite algorithms where a uniform graph structure is employed, a challenge lies in building the unified graph structure from a multiresolution cell decomposition. Specifically, it includes a dynamic, multiresolution scheme for constructing the graph connectivity between nodes at different levels. The unified graph structure will evolveitself as the agent moves, while updating nodes and edges associated with the multiresolutioncell decomposition from the FLWT. If this is the case, we might be ableto adapt the proposed path planning algorithm to an incremental search algorithm, hence taking advantages of both the efficient multiresolution connectivity (due tothe FLWT) and the fast computation (due to the incremental search by using the previous information).6.1个结论小型无人机自主控制施加严厉限制控制算法发展,源于所施加的限制板载硬件并要求在线实施。
The DIL/NetPCs DNP/1110 – Using the Embedded LinuxWeb Server for Embedded SystemsAfter the “everybody-in-the-Internet-wave” now obviously follows the“everything-in-the-Internet-wave”.The most coffee, vending and washingmachines are still not available about the worldwide net. However the embeddedInternet integration for remote maintenance and diagnostic as well as the so-calledM2M communication is growing with a considerable speed rate.Just the remote maintenance and diagnostic of components and systems by Webbrowsers via the Internet, or a local Intranet has a very high weight for manydevelopment projects. In numerous development departments people work oncompletely Web based configurations and services for embedded systems. Theremaining days of the classic user interface made by a small LC-display with frontpanel and a few function keys are over. Through future evolutions in the field ofthe mobile Internet, Bluetooth-based PAN s (Personal Area Network's) andthe rapidly growing M2M communication (M2M=Machine-to-Machine)a further innovating advance is to be expected.The central function unit to get access on an embedded system via Web browser isthe Web server. Such Web servers bring the desired HTML pages (HTML=HyperText Markup Language) and pictures over the worldwide Internetor a local network to the Web browser. This happens HTTP-based (HyperText Transfer Protocol). A TCP/IP protocol stack –that means it is based onsophisticated and established standards–manages the entire communication.Web server (HTTP server) and browser (HTTP client) build TCP/IP-applications. HTTP achieved a phenomenal distribution in the last years.Meanwhile millions of user around the world surf HTTP-based in the WorldWide Web. Today almost every personal computer offers the necessaryassistance for this protocol. This status is valid more and more for embeddedsystems also. The HTTP spreads up with a fast rate too.The DIL/NetPCs DNP/1110 – Using the Embedded Linux1. TCP/IP-based HTTP as Communication PlatformHTTP is a simple protocol that is based on a TCP/IP protocol stack (picture 1.A).HTTP uses TCP (Transmission Control Protocol). TCP is a relative complex andhigh-quality protocol to transfer data by the subordinate IP protocol. TCP itselfalways guarantees a safeguarded connection between two communication partnersbased on an extensive three-way-handshake procedure. As aresult the data transfer via HTTP is always protected. Due tothe extensive TCP protocol mechanisms HTTP offers only a low-gradeperformance.Figure 1: TCP/IP stack and HTTP programming modelHTTP is based on a simple client/server-concept. HTTP server and clientcommunicate via a TCP connection. As default TCP port value the port number80 will be used. The server works completely passive. He waits for a request(order) of a client. This request normally refers to the transmition of specificHTML documents. This HTML documents possibly have to be generateddynamically by CGI. As result of the requests, the server will answer with aresponse that usually contains the desired HTML documents among others(picture 1.B).GET /test.htm HTTP/1.1Accept]: image/gif, image/jpeg, */*User selling agent: Mozilla/4.0Host: 192.168.0.1Listing 1.A: HTTP GET-requestHTTP/1.1 200 OKDate: Mon, 06 Dec 1999 20:55:12 GMTServer: Apache/1.3.6 (Linux)Content-length: 82Content-type: text/html<html><head><title>Test-Seite</title></head><body>Test-SeiteThe DIL/NetPCs DNP/1110 – Using the Embedded Linux</body></html>Listing 1.B: HTTP response as result of the GET-request from listing 1.AHTTP requests normally consist of several text lines, which are transmitted to theserver by TCP. The listing 1.A shows an example. The first line characterizes therequest type (GET), the requested object (/test1.htm) and the used HTTP version(HTTP/1.1). In the second request line the client tells the server, which kind offiles it is able to evaluate. The third line includes information about theclient- software. The fourth and last line of the request from listing 1.A is used toinform the server about the IP address of the client. In according to the type ofrequest and the used client software there could follow some further lines. Asan end of the request a blank line is expected.The HTTP responses as request answer mostly consist of two parts. At first thereis a header of individual lines of text. Then follows a content object (optional).This content object maybe consists of some text lines –in case of a HTML file– ora binary file when a GIF or JPEG image should be transferred. The first line of theheader is especially important. It works as status or error message. If anerror occurs, only the header or a part of it will be transmitted as answer.2. Functional principle of a Web ServerSimplified a Web server can be imagined like a special kind of a file server.Picture 2.A shows an overview. The Web server receives a HTTP GET-requestfrom the Web browser. By this request, a specific file is required as answer (seestep 1 into picture 2.A). After that, the Web server tries to get access on the filesystem of the requested computer. Then it attempts to find the desired file (step 2).After the successful search the Web server read the entire file(step 3) and transmit it as an answer (HTTP response comprising of headerand content object) to the Web browser (step 4). If the Web server cannot findthe appropriate file in the file system, an error message (HTTP response whichonly contains the header) is simply be send as response to the client.Figure 2: Functional principle from Web server and browserThe DIL/NetPCs DNP/1110 – Using the Embedded LinuxThe web content is build by individual files. The base is build by static files withHTML pages. Within such HTML files there are references to further filesembedded –these files are typically pictures in GIF or JPEG format. However,also references to other objects, for example Java-Applets, are possible. After aWeb browser has received a HTML file of a Web server, this file will beevaluated and then searched for external references. Now the steps 1 to 4 frompicture 2.A will run again for every external reference in order to request therespective file from the corresponding Web server. Please note, that such areference consists of the name or IP address of a Web server (e.g. ""),as well as the name of the desired file (e.g. "picture1.gif"). So virtually everyreference can refer to another Web server. In other words, a HTML file could belocated on the server "ssv-embedded.de" but the required picture -which isexternal referenced by this HTML file- is located on the Web server"". Finally this (worldwide) networking of separate objects is thecause for the name World Wide Web (WWW). All files, which are required by aWeb server, are requested from a browser like the procedure shown on picture2.A. Normally these files are stored in the file system of the server. TheWebmaster has to update these files from time to time.A further elementary functionality of a Web server is the CommonGateway Interface(CGI) -we have mentioned before. Originally this technologyis made only for simple forms, which are embedded into HTML pages. The data,resulting from the padding of a form, will be transmitted to a Web server viaHTTP-GET or POST-request (see step 1 into picture 2.B). In such a GET- orPOST-request the name of the CGI program, which is needed for theevaluation of a form, is fundamentally included. This program has to be on theWeb server. Normally the directory "/cgi-bin" is used as storage location.As result of the GET- or POST-request the Web server starts the CGI programlocated in the subdirectory "/cgi-bin" and delivers the received data in form ofparameters (step 2). The outputs of a CGI program are guided to the Web server(step 3). Then the Web server sends them all as responses to the Web browser(step 4).3. Dynamic generated HTML PagesIn contradiction to a company Web site server, which informs people about theproduct program and services by static pages and pictures, an embeddedWeb server has to supply dynamically generated contents. The embedded Webserver will generate the dynamic pages in the moment of the first access by abrowser. How else could we check the actual temperature of a system viaInternet? Static HTML files are not interesting for an embedded Web server.The most information about the firmware version and service instructions arestored in HTML format. All other tasks are normally made via dynamic generatedHTML.There are two different technologies to generate a specific HTML page in themoment of the request: First the so-called server-side-scripting and secondthe CGI programming. At the server-side-scripting, script code is embeddedinto a HTML page. If required, this code will be carried out on the server (server-sided).The DIL/NetPCs DNP/1110 – Using the Embedded LinuxFor this, there are numerous script languages available. All these languages areusable inside a HTML-page. In the Linux community PHP is used mostly. Thefavourite of Microsoft is VBScript. It is also possible to insert Java directly intoHTML pages. Sun has named this technology JSP(Java Server Pages).The HTML page with the script code is statically stored in the file system of theWeb server. Before this server file is delivered to the client, a special programreplaces the entire script code with dynamic generated standard HTML. The Webbrowser will not see anything from the script language.Figure 3: Single steps of the Server-Side-ScriptingPicture 3 shows the single steps of the server-side-scripting. In step 1 the Webbrowser requests a specific HTML file via HTTP GET-request. The Web serverrecognizes the specific extension of the desired file (for example *.ASP or *.PHPinstead of *.HTM and/or *.HTML) and starts a so-called scripting engine(see step 2). This program gets the desired HTML file including the script codefrom the file system (step 3), carry out the script code and make a newHTML file without script code (step 4). The included script code will be replacedby dynamic generated HTML. This new HTML file will be read by the Webserver (step 5) and send to the Web browser (step 6). If a server-sided scripting issupposed to be used by an embedded Web server, so you haveto consider the necessary additional resources. A simple example: In orderto carry out the embedded PHP code into a HTML page, additional programmodules are necessary for the server. A scripting engine together with theembedded Web server has to be stored in the Flash memory chip of an embeddedsystem. Through that, during run time more main memory is required.4. Web Server running under LinuxOnce spoken about Web servers in connection with Linux most peopleimmediately think of Apache. After investigations of the Netcraft Surveythis program is the mostly used Web server worldwide. Apache is anenhancement of the legendary NCSA server. The name Apache itself hasnothing to do with Red Indians. It is a construct from "A Patchy Server" becausethe first version was put together from different code and patch files.Moreover there are numerous other Web servers - even for Linux. Most of this arestanding under the GPL (like Apache) and can be used license free. Avery extensive overview you can find at "/". EveryWeb server has his advantages and disadvantages. Some are developed forspecific functions and have very special qualities. Other distinguishes at bestthrough their reaction rate at many simultaneous requests, as wellas the variety of theirconfiguration settings. Others are designed to need minimal resources and offer very small setting possibilities, as well as only one connection to a client.The most important thing by an embedded Web server is the actual resource requirements. Sometimes embedded systems offer only minimal resources, which mostly has to be shared with Linux. Meanwhile there are numerous high- performance 32-bit-386/486-microcontroller or (Strong)ARM-based embedded systems that own just 8 Mbytes RAM and 2 Mbytes Flash-ROM (picture 4). Outgoing from this ROM (Read-only-Memory, i.e. Flash memory chips) a complete Linux, based on a 2.2- or 2.4-Kernel with TCP/IP protocol stack and Web server, will be booted. HTML pages and programs are also stored in the ROM to generate the dynamic Web pages. The space requirements of an embedded system are similar to a little bigger stamp. There it is quite understandable that there is no place for a powerful Web server like Apache.Figure 4: Embedded Web Server Module with StrongARM and LinuxBut also the capability of an Apache is not needed to visualize the counter of a photocopier or the status of a percolator by Web servers and browsers. In most cases a single Web server is quite enough. Two of such representatives are boa () and thttpd (). At first, both Web servers are used in connection with embedded systems running under Linux. The configuration settings for boa and thttpd are poor, but quite enough. By the way, the source code is available to the customer. The practicable binary files for these servers are always smaller than 80 Kbytes and can be integrated in the most embedded systems without problems. For the dynamic generation of HTML pages both servers only offer CGI (Common Gateway Interface) as enlargement. Further technologies, like server-side-includes (SSI) are not available.The great difference between an embedded Web server and Apache is, next to the limited configuration settings, the maximal possible number of simultaneous requests. High performance servers like Apache immediately make an own process for every incoming call request of a client. Inside of this process allfurther steps will then be executed. This requires a very good programming and a lot of free memory resources during run time. But, on the other hand many Web browsers can access such a Web server simultaneously. Embedded Web server like boa and thttpd work only with one single process. If two users need to get access onto a embedded Web server simultaneously, one of both have to wait a few fractions of a second. But in the environment of the embedded systems that is absolutely justifiable. In this case it is first of all a question of remote maintenance, remote configuration and similar tasks. There are not many simultaneous requests expected.List of FiguresFigure 1: TCP/IP stack and HTTP programming modelFigure 2: Functional principle from Web server and browserFigure 3: Single steps of the Server-Side-ScriptingFigure 4: Embedded Web Server Module with StrongARM and LinuxListingsListing 1.A: HTTP GET-requestListing 1.B: HTTP response as result of the GET-request from listing 1.A ContactSSV Embedded SystemsHeisterbergallee 72D-30453 HannoverTel. +49-(0)511-40000-0Fax. +49-(0)511-40000-40Email: sales@ist1.deWeb: www.ssv-embedded.deDocument History (Sadnp05.Doc)Revision Date Name1.00 24.05.2002FirstVersion KDWThis document is meant only for the internal application. The contents ofthis document can change any time without announcement. There is takenover no guarantee for the accuracy of the statements. Copyright ©SSV EMBEDDED SYSTEMS 2002. All rights reserved.INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'ASIS' WITHOUT WARRANTY OF ANY KIND. The user assumes the entirerisk as to the accuracy and the use of this document. Some names withinthis document can be trademarks of their respective holders.嵌入式系统的网络服务器在“每个人都处在互联网的浪潮中”之后,现在很明显随之而来的是“每件事都处在互联网的浪潮中”。