EtherCAT Protocol Implementation Issues on an Embedded Linux Platform
Sorin Potra
LVD-Napomar
Bd-ul Muncii, nr. 14, Cluj-Napoca,
Romania
Sorin.Potra@lvdnapomar.ro
Gheorghe Sebestyen Technical University of Cluj-Napoca G. Bari?iu, Nr. 26-28, Cluj-Napoca,
Romania Gheorghe.Sebestyen@cs.utcluj.ro
Abstract – The paper presents the most important
implementation issues of an industrial communication protocol, the EtherCat protocol, on an embedded Linux platform. The authors underscore critical aspects (e.g. reliability, timeliness, predictability) concerning the use of an Ethernet-like protocol in an industrial environment.
I.I NTRODUCTION
Today, the use of industrial communication networks is mandatory in most automation systems [8]. Industrial protocols are specially designed to fulfill the specific communication requirements of control applications, such as: real-time data delivery, high reliability and dependability, priority-based messaging, etc. [6][7].
An industrial network assures the communication environment between different automation devices, from the simplest ones, like intelligent sensors and actuators, until the more complex, process computers. Figure 1 shows a hierarchical automation system where industrial networks are the links between the system's components (sensors – S, actuators – A, Programmable Logic controllers – PLC, and industrial PCs).
The implementation of an industrial protocol involves a number of issues [6]:
-the protocol must be developed on systems (e.g.
intelligent sensors or actuators) with limited hardware
and software resources; such limitations are: small
memory capacity, limited processor speed, few or no
operating system support
-time restrictions and message delivery deadlines must be guaranteed
Figure 1. A network-based automation system
-the roundtrip time of a request-answer message pair is much smaller (usually microseconds) than in the case
of usual networks;
-the protocol drivers must have a highly predictable behavior; for instance, uncontrolled delays caused by
message queues are not allowed
-automatic fault recovery mechanisms must be included in the protocol drivers
The following chapters present the way in which these issues were solved during the implementation of an industrial protocol, namely the EtherCAT.
II.B RIF DESCRIPTION OF THE E THER CAT P ROTOCOL
In the last decade there were a number of attempts to adapt general-purpose computer protocols (e.g. Ethernet, TCP/IP) [4][5] for industrial purposes. EtherCAT (Ethernet Control Automation Technology) is a relatively new industrial protocol built on the Ethernet specifications; it incorporates some new features that make it adequate for control applications. This protocol solves the compatibility gap between an industrial protocol and a computer network protocol.
The EtherCAT combines the efficient and relatively high-speed message transmission (specific for Ethernet networks), with the predictability imposed by a master/slave medium access control policy. This access policy works in the following way: there is a single master node on a network segment that has the right to initiate data transfers; this node sends an Ethernet frame to the slave nodes; a slave node extracts the data from the frame addressed to it, puts some new data in the frame and than sends the frame to the next slave; the frame arrives back to the master node confirming the correctness of the transmission. All the message reception, data processing and frame retransmission operations are made "on the fly" by the slave nodes, without any extra delays. Special hardware components, embedded in the slave's Ethernet interface, are responsible for these operations. This solution assures a minimum roundtrip (reaction time), better than in the case of other industrial protocols (e.g. CAN, Profibus, etc.).
Figure 2 shows a typical EtherCAT segment, with one master node (a data acquisition, control and supervision device) and a number of slave nodes (intelligent sensors and actuators, PLCs, etc.).
1-4244-0361-8/06/$20.00 ?2006 IEEE
Figure 2. A Master/Slave EtherCAT network segment
In order to farther improve the data transmission efficiency the protocol allows data addressing at bit level. Logical addresses are allocated to every slave node inside of a single Ethernet frame. When a frame arrives to a slave, the node will take the data addressed to it (control information to the process) and in the same time it will put its own data (process parameter values) on the frame. So, data is transferred between the master and the slave nodes in a single frame.
In order to increase the reliability of the network the "application" level of the EtherCAT protocol specifies a number of states and transitions between them necessary to switch one or more slave nodes from an inactive state into a fully operational state. The network driver implemented in the master node must follow these transitions and it must detect automatically any defects in the system. Figure 3
shows these states and transitions.
Figure 3. State transitions in a slave node
The master node controls the transitions between states through sets of predefined control frames, every set being particular to a slave device. Each set contains the commands that have to be fulfilled by the slave in order to be able to make a desired transition. In figure 3 IP (Init to Preoperational), PI (Preoperational to Init), PS, SP, etc. are the transition names executed in the slave node as result to a request from the master node.
The final goal of the project described in this paper was to develop a driver for a Linux platform that implements the EtherCAT standard's specification for a master node.
III. T HE P ROTOCOL D EVELOPMENT F RAMEWORK A. The hardware platform
The hardware platform used in the development of the master protocol driver was composed of the following modules (figure 4):
1. an embedded industrial PC (AAEON PCM-6892) used
as master node
2. an EtherCAT evaluation board (Beckhoff EL9800)
used as slave node
Figure 4 shows the image of the experimental system
3. Ethernet UTP CAT 5e crossover interconnection
cables
4. power supply for the industrial PC
5. 24V power supply for the slave node
6. peripheral devices for storage and user interface
The EtherCAT evaluation board is a multifunctional device that contains process specific input/output interfaces and a network adapter based on the Ethernet physical layer. This board can simulate the behavior of a slave node, both from the network and from the process point of view. It can generate digital inputs and display digital outputs according to the master commands. The software driver for the EtherCAT slave can be downloaded through a special port. Through this board the developer can configure different testing scenarios. This feature was very useful in the process of protocol driver validation and performance measurement. B. The software platform
In order to assure the fulfillment of time restrictions, required in most control applications, a real-time operating system was necessary. For compatibility purposes a Linux platform with a real-time extension was considered the best solution. The RTAI (Real-Time Application Interface) was adopted, which is a Linux extension installed over the kernel; it offers a wide set of real-time functions accessible for the programmer through an API module.
As support for real-time communication the RTnet protocol driver set was selected. RTnet, developed at the Hanovra University, is compatible with the RTAI-Linux platform and accepts many popular network chipsets. The protocol driver implements the basic functionalities of UDP/IP, ICMP and ARP protocols in a deterministic fashion. RTnet offers POSIX socket API for the real-time user processes or to the kernel modules. Ethernet frames can be transmitted in real-time through the RTnet protocol [13],[14].
IV.S YSTEM S PECIFICATIONS
A.Functional Specification
In the case of an industrial communication protocol, based
on a master/slave architecture, the complexity of the protocol
is placed in the master node. The idea is to minimize the network software that has to be implemented in the slave nodes. Usually slave devices are built around a microcontroller, which has very limited computing resources (small internal memory, limited CPU speed).
In the case of EtherCAT protocol most of the higher-level functionalities concerning network initialization, configuration and traffic control are implemented in the master module. This module keeps an image of the input and output data which is transferred through the slave nodes to and from the controlled process. The actual data which has to
be transferred and its mapping on the existing slave nodes is specified through an XML file. In the initialization phase the master node configures the slave nodes to place and take their data to and from specified fields of an Ethernet frame. Through periodical frames the master node builds the actual image of the controlled process and passes the command information to the process. A higher-level control application can access input and output process data through
a set of functions offered by the master node driver. The application can send commands to put slaves in different states, as specified in figure 3, and receives the actual state of the slave as response. The master driver translates a generic command in a sequence of specific control frames transmitted
to the slave nodes. The state transitions will be made in accordance with the state automaton of the slave, specified in the EtherCAT protocol.
The XML configuration file, created with the TwinCAT software tool, contains the following information:
-configuration data for the master node
-initialization and configuration commands for the slave nodes (one or more commands for every state
transition and slave node)
-the dimension of the process image and the way in which input/output data is mapped on this image
-process control data that must be transmitted periodically to the slave node
-input process data that must be acquired periodically
An application built on top of the master driver writes and reads process data to and from the process image preserved in the master driver. The master driver will actualize the image
by reading the input data from the slaves and by sending the commands to the slaves. So, the communication between the master and the slave nodes is transparent to the control application. Input data is obtained without any delays from the latest process image; output data is set in the image and it will be actualized in the slaves in the next periodical frame.
B.Master Driver's Structure
The master driver must be integrated in the kernel part of the Linux operating system, so that any application could access the communication functionalities of the driver. One possibility is to integrate the source code of the driver in the source of the kernel and recompile the kernel. The adopted solution was to add the master driver module to the kernel as a set of "loadable kernel modules" (LKM) [3]. This is a better solution because avoids kernel recompilation, errors in the driver does not affect the kernel's reliability and the driver can be loaded only at request. Any errors caused by the driver can be solved by specific commands without blocking the whole operating system.
The execution time of an LKM is similar with a module incorporated in the kernel, an access to a function contained in the module in translated as an access to the memory zone where the module is loaded. This aspect was very important considering the real-time restrictions imposed by the protocol.
The master driver was built as a set of cooperating KLM modules instead of a monolithic single module because it offers a number of advantages:
-it is a scalable and more flexible solution
-the network functionalities may be divided in hierarchical levels
-the inherent complexity of the driver is reduced through division [1]
-the EtherCAT protocol suggests the implementation of the driver on two levels: a data-link level and an
application level
Every KLM offers a set of services to the other KLMs in the driver and to the upper control application. The communication between KLMs and the application is made through service calls.
Figure 5 shows the main components of the EtherCAT master driver.
The RT Network module is responsible for sending and receiving Ethernet frames under real-time restrictions. It offers basic network communication functions to the upper level.
The EtherCAT module offers EtherCAT telegrams' sending and receiving services. It is responsible to format and pack higer level transmission requests in different types of EtherCAT telegrams.
Figure 5. The structure of the EtherCAT master driver
The Application level module offers high-level services for the user applications. These services will be presented in the next chapter. This module builds and preserves the image of the controlled process.
The Control application module is any user application that requires communication services from the EtherCAT network. This module implements the supervision and control functionalities of the automation system.
C.Master driver functional description
The master has the role of coordinating all the slave devices. The master driver preserves a mirror data for each slave node connected on the network. This mirror shows the current state of the slaves and contains all the device specific commands that have to be sent during state transitions.
In order to control the network in a deterministic and predictive manner the master driver was defined as a state machine automaton. This automaton controls and follows the state transitions in the slave nodes, in accordance with the EtherCAT protocol. Figure 6 shows the state automaton of the master driver.
In order to follow the initialization and configuration commands' sequence sent to the slave nodes, for each transition in the slave’s state machine, an extra state in the master’s state machine was defined.
In the present implementation there are three steps needed to accomplish a slave’s state transition between two EtherCAT states. During the first step, the master sends all the global initialization commands that have to be received by the controlled slave devices. After all the slaves have confirmed the correct execution of these global commands, the master passes into an intermediary state called “Wait Slaves”. When entering this state, the master requests all slave mirrors to send their specific initialization commands to the associated controlled devices.
Figure 6. Master state machine
This represents the second step in the transition and ends when all the slave mirrors have received confirmation of the correct execution of these particular commands. When the second step has finished, the master starts sending the rest of the global initialization commands that have to be received by the slaves after the particular initialization commands were executed. This is the third and final step of the transition and ends when all the slaves have executed the global commands. After the third step, the transition of the master and slave nodes to the new EtherCAT state is considered finished.
As presented above, there are two types of initialization commands:
-global initialization commands that have to be sent and executed by all the controlled slaves; these
commands are handled by the master
-particular initialization commands that have to be executed by a particular slave device; these commands
are handled by the software mirror of that particular
slave device
Furthermore, the global commands are split in two types:
-commands that have to be issued at the start of an EtherCAT state transition, before the particular
initialization commands are issued
-commands that have to be issued at the end of an EtherCAT state transition after all the particular
initialization commands have been executed by the
devices.
Independently of their owner, all the EtherCAT commands are processed in the same manner.
D.Implementation aspects
In order to assure the severe time restrictions imposed by the EtherCAT protocol a number of special implementation solutions had to be adopted. Here are some of the most important implementation decisions and solutions:
-the driver components are implemented as real-time tasks, activated periodically at well defined time
periods
-there are no uncontrolled delays inside of the driver’s routines;
-communication between the driver components and the control application is made through an efficient
data transfer mechanism based on a shared memory
zone; this solution reduces significantly the time for
data exchange
-the driver is implemented as a set of cooperating modules instead of a monolithic solution; this gives
flexibility and better time responsiveness to the driver -the driver is part of the operating system’s kernel, so any user application can benefit from the
communication services of the driver; the control
application designer does not have to concentrate on
the communication aspects because they are solved on
a lower level, in the driver
-the use of a real-time extension of Linux as development platform makes the implementation
more open, reliable and time efficient
E.The Test System
In order to test the functional correctness of the master driver, a test application was developed. This application allows access to all driver functions through a flexible user interface. The application has two parts: one that runs in the user space (user process) and a LKM that runs in the kernel space (kernel process). The user process implement the user interface through which high level test commands can be generated and their results are visualized. The kernel process transforms the high level requests into service requests sent to the application module of the driver. A special communication mechanism was used to transfer information between the user mode and kernel mode processes. The solution was a shared memory zone between the two processes. This solution assures a rapid data transfer, very important for the performance measurements made on the network. Figure 7 shows a snapshot of the test application. The interface shows the current state of the slave nodes and the input/output process image. The user can request a change of the slaves’ state or to write a value in the output process image. These changes are automatically transferred to the slave through the master driver.
V.E XPERIMENTAL R ESULTS
The most important performance parameter of an industrial network is the transmission time of process data. Many general-purpose computer networks cannot be used in a control application because the transmission time is high or, even worst, unpredictable. This is caused mainly by two factors:
-the overhead of a message is big compared with the useful data (e.g. a signal value)
Figure 7 A Snapshot of the test application
-an unpredictable medium access control protocol, like the Ethernet, cannot guarantee a maximum delivery
time
The EtherCAT protocol imposes a strict medium access policy, controlled by the master module; this policy allows the designer to predict and control the transmission time of messages. The input and output parameters can be packed in a single EtherCAT message, reducing significantly the ratio between the overhead and the useful data in a frame. In this way both previously mentioned problems are solved. There is no need for a request-answer message exchange because the input parameters are placed in the master message during the reception and re transmission at the slave node. But such an approach implies severe time restrictions to the protocol driver.
In order to test the performance parameters of the implemented driver a special test application was developed. This application starts a periodic task with a frequency of one quarter of the update frequency of the process image done in the driver. The user module, which is part of the test application and is situated above the driver’s application module, periodically changes the values of the output process image preserved in the master node. The driver is responsible for the transfer of the output process image from the memory buffer to the actual outputs on the slave nodes. The time delay between the moment when a value is changed in the image and the moment when the change is effective in the slave is the most important performance parameter for the network. This time determines the maximum frequency for the changes in the process image and implicitly the maximum frequency with which a control application can change the state of a process parameter.
The Ethereal sniffer application was used to monitor the exchange of EtherCAT frames between the master and the slave nodes (figure 8). Enhanced with a plug-in for decoding the contents of EtherCAT frames, the sniffer proved to be a valuable tool in the driver development and testing process. The sniffer was also useful in the measurement of the delays between EtherCAT frames. According to its readings, the updates made by the test application to the output process
Figure 8. Sniffer capture of EtherCAT frames
image preserved the same frequency ratio (between the period of the driver’s task and the test application’s task); so every four EtherCAT frames had the same value contents, meaning that the longest delay between the modification of the output process image and the actual sending of the value to the slave device is the period of the driver’s task. Another important parameter is the time between the moment when an input parameter changes state or value at the slave’s entry and the moment when this change is visible in the process image at the master level.
The two time parameters are correlated and they reflect the
reaction time of the network infrastructure to a change in the system.
According to the measurements, the maximum delay in updating the process image is the activation period of the task associated to the master driver. The minimum of this period must cover the time needed to transmit the all the EtherCAT frames containing the commands in the current state. The driver’s task period depends on the number of inputs/outputs supervised by the system.
In a scenario with a single slave that controls 32 digital signals the optimal activation period was established to 200μs. As a consequence the reaction time of the network to
a data change is also 200μs. This fact was demonstrated through experiments with the above mentioned test application.
This result shows a significant performance increase of the EtherCAT network in comparison with other industrial networks. Figure 9. shows the time delay magnitude for the EtherCAT implementation and a equivalent CAN network. This result allowed the company that sponsored this research (L.V.D. Company NV, Belgium) to extend the use of network communication to some complex industrial equipments, where time restrictions made the use of other industrial networks prohibitive.
VI.C ONCLUSIONS
As experiments and validation tests showed the master driver developed during the present project is in accordance with the EtherCAT specifications. In the same time the performance measurements demonstrated that the implementation is highly efficient; the minimum cycle time achieved for a single slave is around 200μs, a much better time than in the case of other industrial networks in use today.
The network driver is integrated in a real-time extension of the Linux operating system. It is built as a set of cooperating LKM modules loaded in the kernel of the operating system. The network communication functions can be accessed by any user application through a set of public services offered by the driver.
The functional and performance test tools developed during the project are very useful for further control application developments. The tools can be used to test different particular network configurations and traffic scenarios. The designer of a control application can measure
Figure 9. Comparison between EtherCAT and CAN reaction time
if the network satisfies the time restrictions imposed by the controlled process.
The company that sponsored this research is using the driver to control some complex sheet metal processing industrial equipments. The results are better compared with a previous implementation where CAN protocol was used. The smaller cycle time assured by the driver increases the responsiveness of the control unit to the changes produced in the equipments.
ACKNOWLEDGMENT
The authors thanks to the representatives of the L.V.D. Company (Belgium) for the hardware and software support offered for the development of the present project.
REFERENCES
[1] A Tanenbaum, “Retele de calculatoare” 4th edition, Agora publishing
company, 2003
[2] E. Bianchi, L. Dozio and P. Mantegazza, “RTAI manual”,
http://www.aero.polimi.it/~rtai/documentation/reference/rtai_man.pdf [3]Bryan Henderson, “Linux Loadable Kernel Module HowTo”, 2005,
https://www.doczj.com/doc/c87887593.html,/HOWTO/Module-HOWTO/index.html
[4] C. Cardeira, F. Simonot-Lion M. Bayard, “Intelligent Field Devices
and Field Buses: Impact on Applications Design Methodology”,
Studies in Informatics and Control, Vol 4 No. 3 1995, pp 255-262
[5] F. Pasadas C. Cardeira, Real-Time Protocols for Industrial LANs, in
Proceedings of the Network of Excellence in Intelligent Control and
Integrated Manufacturing Systems, Portugal, 1995
[6]G. Sebestyen, “Real-Time Communications through Industrial
Networks”, Proceedings of A&Q'98 International Conference on Automation and Quality Control, Cluj-Napoca, p A243-249, 1998
[7]G. Sebestyen, “A Multistate Model Used in Small Real-Time
Systems”, in Automation Computers and Mathematics ACAM 1996, [8] B. Upender, P. Koopman ”Communication Protocols for Embedded
Systems”, in Embedded Systems Programming, 7(11), pp46-58, 1998 [9]*** “EtherCAT Communication Specification version 1.0”, Beckhoff
GmbH, Germania, 2004
[10]*** “EtherCAT Technical Introduction and Overview”,
https://www.doczj.com/doc/c87887593.html,/pdf/english/EtherCAT_Introduction_en.pdf,
2004
[11]*** “PCM-6892 User manula” 4th Edition, AAEON, Taiwan, 2004
[12]*** “EtherCAT Evaluation-Kit EL9800, FB1120 und FB1220”,
Beckhoff GmbH, Germania, 2004
[13]*** PacketSockets, https://www.doczj.com/doc/c87887593.html,/man7/packet.7.php
[14]*** “RTnet Documentation”, Hanovra, Germania, http://www.rts.uni-
hannover.de/rtnet/doc.html
1．下面哪一种工作模式不属于ARM特权模式（ A ）。 A．用户模式B．系统模式C．软中断模式D．FIQ模式 2．ARM7TDMI的工作状态包括（ D ）。 A．测试状态和运行状态B．挂起状态和就绪状态 C．就绪状态和运行状态D．ARM状态和Thumb状态 3．下面哪个Linux操作系统是嵌入式操作系统（ B ）。 A．Red-hat Linux B．uclinux C．Ubuntu Linux D．SUSE Linux 4．使用Host-Target联合开发嵌入式应用，（ B ）不是必须的。 A．宿主机B．银河麒麟操作系统 C．目标机D．交叉编译器 5．下面哪个不属于Linux下的一个进程在内存里的三部分的数据之一（ A ）。 A．寄存器段B．代码段 C．堆栈段D．数据段 选择题（共5小题，每题2分，共10分） 1．下面哪个系统属于嵌入式系统（ D ）。 A．“天河一号”计算机系统B．IBMX200笔记本电脑 C．联想S10上网本D．Iphone手机 2．在Makefile中的命令必须要以（ A ）键开始。 A．Tab键B．#号键 C．空格键D．&键 3．Linux支持多种文件系统，下面哪种不属于Linux的文件系统格式（ B ）。 A．Ext B．FAT32 C．NFS D．Ext3 4．下面哪种不属于VI三种工作模式之一（ D ）。 A．命令行模式B．插入模式 C．底行模式D．工作模式 5．下面哪一项不属于Linux内核的配置系统的三个组成部分之一（ C ）。 A．Makefile B．配置文件（config.in） C．make menuconfig D．配置工具 1．人们生活中常用的嵌入式设备有哪些？列举4个以上(1) 手机，(2) 机顶盒，(3) MP3，(4) GPS。（交换机、打印机、投影仪、无线路由器、车载媒体、PDA、GPS、智能家电等等。） 2．ARM9处理器使用了五级流水线，五级流水具体指哪五级：(5) 取指，(6) 译码，(7) 执行，(8) 缓冲/数据，(9) 回写。 3．在Makefile中的命令必须要以(10) Tab 键开始。 4．Linux支持多种文件系统，主要包括哪些（写出其中4中就行）(11) Ext，(12) VFAT，(13) JFS，(14) NFS。（JFS、ReiserFS、Ext、Ext2、Ext3、ISO9660、XFS、Minx、MSDOS、UMSDOS、VFAT、NTFS、HPFS、NFS、SMB、SysV、PROC等） 5．VI的工作模式有哪三种：(15) 命令行模式，(16) 插入模式，(17) 底行模式。
实验一linux基本操作实验的实验报告 一实验目的 1、熟悉嵌入式开发平台部件，了解宿主机/目标机开发模式； 2、熟悉和掌握常用Linux的命令和工具。 二实验步骤 1、连接主机和目标板；（三根线,网线直接连接实验箱和PC机，实验箱UART2连接主机的UART口）。 2、Linux命令的熟悉与操作 PC端：在PC机的桌面上打开虚拟机，并启动Linux系统，打开命令终端，操作Linux基本命令，如：查看：ls，进入目录：cd，创建文件：mkdir，删除文件：rmdir，配置网络：ifconfig，挂载：mount，设置权限：chmod，编辑器：vi，拷贝：cp等命令，要求能熟练操作。 使用方法： 1.查看：ls Ls列出文件和目录 Ls–a 显示隐藏文件 Ls–l 显示长列格式ls–al 其中：蓝：目录;绿：可执行文件;红：压缩文件;浅蓝：链接文件;灰：其他文件;红底白字：错误的链接文件 2.进入目录：cd 改变当前目录：cd 目录名(进入用户home目录：cd ~;进入上一级目录：cd -) 3.创建文件：mkdir 建立文件/目录：touch 文件名/mkdir目录名 4.删除文件：rmdir 删除空目录：rmdir目录名 5.配置网络：ifconfig 网络- （以太网和WIFI无线） ifconfig eth0 显示一个以太网卡的配置 6.挂载：mount mount /dev/hda2 /mnt/hda2 挂载一个叫做hda2的盘- 确定目录'/ mnt/hda2' 已经存在 umount /dev/hda2 卸载一个叫做hda2的盘- 先从挂载点'/ mnt/hda2' 退出fuser -km /mnt/hda2 当设备繁忙时强制卸载 umount -n /mnt/hda2 运行卸载操作而不写入/etc/mtab文件- 当文件为只读或当磁盘写满时非常有用 mount /dev/fd0 /mnt/floppy 挂载一个软盘 mount /dev/cdrom /mnt/cdrom挂载一个cdrom或dvdrom mount /dev/hdc /mnt/cdrecorder挂载一个cdrw或dvdrom mount /dev/hdb /mnt/cdrecorder挂载一个cdrw或dvdrom mount -o loop file.iso /mnt/cdrom挂载一个文件或ISO镜像文件
学习中心/函授站_ 姓名学号 西安电子科技大学网络与继续教育学 院 2014学年下学期 《嵌入式系统》期末考试试题 （综合大作业） 题号一二三四五总分 题分2010302020 得分 考试说明： 1、大作业于2014年12月25日下发，2015年1月10日交回； 2、考试必须独立完成，如发现抄袭、雷同均按零分计； 3、答案须手写完成，要求字迹工整、卷面干净。 一、问题简述（每小题4分，共20分） 1、简述嵌入式系统的定义和组成结构。 答：嵌入式系统是以应用为中心，以计算机技术为基础，并软硬件可剪裁、功能、 ,可靠性、体积、重量、成本、功耗、成本、安装方式等方面符合要求的专用计算机系统。 嵌入式系统一般由嵌入式微处理器、存储与I/O部分、外设与执行部分、嵌入式软件等四个部分组成。 2、简单说明ARM微处理器的特点。 答：(1) 体积小、低功耗、低成本、高性能。 (2) 支持Thumb(16位)/ARM(32位)双指令集，能很好地兼 容8位/16位器件。
(3) 大量使用寄存器，指令执行速度更快。 (4) 大多数数据操作都在寄存器中完成，通过Load/Store结 构在内存和寄存器之间批量传递数据。 (5) 寻址方式灵活简单，执行效率高。 (6) 指令长度固定。 3、简述嵌入式系统产品的设计和开发过程。 答：①在嵌入式系统的开发过程中，一般采用的方法是首先在通用PC机上的集成开发环境中编程；②然后通过交叉编译和链接，将程序转换成目标平台(嵌入式系统)可以运行的二进制代码；③接着通过嵌入式调试系统调试正确；④最后将程序下载到目标平台上运行。 要强调，选择合适的开发工具和调试工具，对整个嵌入式系统的开发都非常重要。 4、简述嵌入式系统设计中要考虑的因素。 答：在嵌入式系统的开发过程中，要考虑到实时性、可靠性、稳 定性、可维护性、可升级、可配置、易于操作、接口规范、抗干 扰、物理尺寸、重量、功耗、成本、开发周期等多种因素。 5、什么是BootLoader，了解其在嵌入式系统中作用。 答：就是启动载入或引导加载又叫自举装载。由于系统加电后需 要首先运行BootLoader这段程序，因此它需要放在系统加电后 最先取指令的地址上。嵌入式处理器的生产厂商都为其处理器预 先安排了一个在系统加电或复位后最先取指令的地址。 二、名词解释（每小题2分，共10分） 1、DSP(Digital Signal Processor)，数字信号处理器，一种特别用于快速处理数字信号的微处理器。DSP处理器对系统结构和指令进行了特殊设计，使其适合于执行DSP算法，编译效率较高，指令执行速度也较高。 2、RTOS Real Time Operating System. 译为实时操作系统。实时系统是指一个能够在指定的或者确定的时间内，实现系统功能和对外部或内部、同步或异步事件作出响应的系统。 3、BSP设计板级支持包（BSP）的目的主要是为驱动程序提供访问硬件设备寄存器的函数包，从而实现对操作系统的支持。类似于PC机上的BIOS，是一个承上启下的软件层次。由嵌入OS和用户开发相结合取得。BSP一般是在嵌入式系统上固化存放。 4、总线竞争就是在同一总线上，同一时刻，有两个以上器件要通
什么是嵌入式linux系统? 一、什么是嵌入式linux？ Linux从1991年问世到现在，短短的十几年时间已经发展成为功能强大、设计完善的操作系统之一，不仅可以与各种传统的商业操作系统分庭抗争，在新兴的嵌入式操作系统领域内也获得了飞速发展。嵌入式Linux（Embedded Linux）是指对标准Linux经过小型化裁剪处理之后，能够固化在容量只有几K或者几M字节的存储器芯片或者单片机中，适合于特定嵌入式应用场合的专用Linux操作系统。嵌入式Linux既继承了intelnet上无限的开放原代码资源，又具有嵌入式操作系统的特性。 二、嵌入式Linux的特点版权费：免费； 购买费用：媒介成本； 技术支持：全世界的自由软件开发者提供支持； 网络特性：免费而且性能优异； 软件移植：容易，代码开放，有许多应用软件支持； 应用产品开发周期：短，新产品上市迅速，因为有许多公开的代码可以参考和移植； 实时性能：RT_Linux，hardhat Linux 等嵌入式Linux支持实时性能； 稳定性：好； 安全性：好。 三、嵌入式Linux的市场前景和商业机会 嵌入式Linux有巨大的市场前景和商业机会，出现了大量的专业公司和产品，如Montavista、Lineo、Emi等。有行业协会，如Embedded Linux Consortum等。得到世界著名计算机公司和oem板级厂商的支持，例如IBM、Motorola、Intel等。传统的嵌入式系统厂商也采用了Linux策略如Lynxworks 、Windriver、QNX等。还有intelnet上的大量嵌入式Linux 爱好者的支持。嵌入式Linux支持几乎所有的嵌入式cpu和被移植到几乎所有的嵌入式oem板。 四、嵌入式Linux的应用领域嵌入式Linux的应用领域非常广泛，主要的应用领域有，信息家电：PDA，STB-Set-stopbox，Digital Telephone，Answering Machine，Screen Phone、数据网络：Ethernet switches，Router，Bridge，Hub，Remote access servers，ATM，Frame relay、远程通信、医疗电子、交通运输、计算机外设、工业控制、航空领域等。 五、嵌入式linux的优势嵌入式Linux的开发和研究是操作系统领域中的一个热点，目前已经开发成功的嵌入式系统中，大约有一半使用的是Linux。Linux之所以能在嵌入式系统市场上取得如此辉煌的成果，与其
《嵌入式数据库sqlite移植及使用》 实验报告 学生姓名：陈彤 学号：13004405 专业班级：130044 指导教师：孙国梓 完成时间：2016.5.31 实验3 嵌入式数据库sqlite移植及使用 一.实验目的 理解嵌入式软件移植的基本方法，掌握sqlite数据库软件移植的步骤，掌握sqlite开发的两种方式—命令模式和C代码开发模式的使用方法，并编程实现简单通讯录查询实验。 二.实验内容 实验3.1 移植嵌入式数据库sqlite 实验3.2 简单通讯录查询实例设计和测试 三.预备知识 Linux使用、数据库相关知识等 四.实验设备及工具（包括软件调试工具） 硬件：ARM 嵌入式开发平台、PC 机Pentium100 以上、串口线。 软件：WinXP或UBUNTU开发环境。 五.实验步骤 5.1 移植嵌入式数据库sqlite 步骤【参看教材103页】： 第一步，解压缩sqlite源码，命令tar zxvf sqlite-autoconf-3080900.tar.gz，在解压后的文件夹下，可以看到源码文件有shell.c 和sqlite3.c文件，生成Makefile的配置脚本文件configure.ac ，并检查当前文件夹下__A__(A.存在 B.不存在)Makefile文件。 第二步利用configure脚本文件生成基于ARM实验台的Makefile，具体命令为./configure CC=arm-linux-gcc –prefix=/opt/sqlite –host=arm-linux（假设安装目录为/opt/sqlite），并检查当前文件夹下___A__(A.存在 B.不存在)Makefile文件。 第三步，编译sqlite，命令为_make_，编译过程中使用的编译器为_ arm-linux-gcc _。 第四步，安装sqlit，命令为_make install_。安装完成后到_/opt/sqlite_文件夹下去查看相关文件，可以看到该文件夹下有_bin_、_include_、__lib__和share文件夹，其中可执行文件sqlite3位于_./bin_文件夹，库位于_./lib_文件夹。 第五步，将sqlite3拷贝到开发板bin目录下，将库下的文件拷贝到开发板的lib目录下【注意链接文件的创建】 第六步，数据库的使用 方式1：命令操纵数据库 在超级终端环境下创建数据库stucomm.db，命令为_sqlite3 stucomm.db_； 创建数据表stutable，字段包括id 整型，name 字符型，phoneNum 字符型，具体命令为_sqlite> create table stutable (id int(20),name char(20),phoneNum char(20));_； 插入2条记录，记录信息如下 001,zhangsan,10086 002,lisi,10000
计算机三级考试《嵌入式系统开发》测试题三级考试分为“网络技术”，“数据库技术”，“软件测试技术，信息安全技术，嵌入式系统开发技术等五个类别，从2013年下半年开始实施2013版考试大纲，并首次实现全部科目无纸化考试。那么计算机三级考试怎么考？以下仅供参考！ 1. 以下是选择嵌入式系统编程语言的衡量标准的是( D ) A.异常事件处理 B.多任务支持 C.程序控制结构 D.以上都是 2. 以下说法正确的是( A ) A.线程响应度高 l B.32位 C.16位 D.8位 6. 以下说法错误的是( D ) A.寄存器的速度最快 B.寄存器容量最小 C.一般用来存储计算的操作数和结果 D.寄存器位于处理器外部 7. 不能决定总线功能的强弱以及适应性的信号线是( C )
A.控制信号线 B.时序信号线 C.中断信号线 D.备用信号线 8. 以下说法错误的是( A ) A.程序就是进程 B.程序是静态的 C.线程响应度高 D.进程是动态的 9. 以下有关进程和程序的说法正确的是( C ) A.进程是静态的 B.一个进程可以对应多个程序 C.一个程序只能对应一个进程 D.程序不是进程 10. 以下不是嵌入式操作系统的是( A ) A.U-Boot B.MontaVista C.Windows CE D.RT-Linux 11. GDB中，用来显示源代码的命令是( B ) A.kill B.list
C.make D.break 12. 1KB等于( B ) A.1024MB B.1024B C.1024GB D.8bit 13. 以下不是嵌入式系统应用领域的是( A ) A.通用软件 B.工业控制 C.消费类电子产品 D.机器人 14. 十进制数100，用十六进制表达为( C ) A.62 B.63 C.64 D.65 15. ARM采用定长指令格式，所有指令都是32位，Bit[24:21]为( C ) A.目标寄存器编码 B.条件执行 C.指令操作符编码
嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解（一） 嵌入式Linux之我行，主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验，二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处，谢请指正。 ?共享资源，欢迎转载：https://www.doczj.com/doc/c87887593.html, 一、移植环境 ?主机：VMWare--Fedora 9 ?开发板：Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器：arm-linux-gcc-4.3.2.tgz ?u-boot：u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括： ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程，如下图。
u-boot的stage1代码通常放在cpu/xxxx/start.S文件中，他用汇编语言写成；u-boot的stage2代码通常放在lib_xxxx/board.c文件中，他用C语言写成。各个部分的流程图如下：
2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持，可以查看board目录的一些子目录，如：board/samsung/目录下就是对三星一些ARM 处理器的支持，有smdk2400、smdk2410和smdk6400，但没有2440，所以我们就在这里建立自己的开发板项目。 1）因2440和2410的资源差不多，主频和外设有点差别，所以我们就在board/samsung/下建立自己开发板的项目，取名叫my2440 2）因2440和2410的资源差不多，所以就以2410项目的代码作为模板，以后再修改
_* 南京邮电大学通信学院 实验报告 实验名称：基于ADS开发环境的程序设计 嵌入式Linux交叉开发环境的建立 嵌入式Linux环境下的程序设计 多线程程序设计 课程名称嵌入式系统B 班级学号 姓名 开课学期2016/2017学年第2学期
实验一基于ADS开发环境的程序设计 一、实验目的 1、学习ADS开发环境的使用； 2、学习和掌握ADS环境下的汇编语言及C语言程序设计； 3、学习和掌握汇编语言及C语言的混合编程方法。 二、实验内容 1、编写和调试汇编语言程序； 2、编写和调试C语言程序； 3、编写和调试汇编语言及C语言的混合程序； 三、实验过程与结果 1、寄存器R0和R1中有两个正整数，求这两个数的最大公约数，结果保存在R3中。 代码1：使用C内嵌汇编 #include
printf("gcdnum:%d\n",a); return 0; } 代码2：使用纯汇编语言 AREA example1,CODE,readonly ENTRY MOV r0, #4 MOV r1, #9 start CMP r0, r1 SUBLT r1, r1, r0 SUBGT r0, r0, r1 BNE start MOV r3, r0 stop B stop END 2、寄存器R0 、R1和R2中有三个正整数，求出其中最大的数，并将其保存在R3中。 代码1：使用纯汇编语言 AREA examp,CODE,READONL Y ENTRY MOV R0,#10 MOV R1,#30 MOV R2,#20 Start CMP R0,R1 BLE lbl_a CMP R0,R2 MOVGT R3,R0 MOVLE R3,R2 B lbl_b lbl_a CMP R1,R2 MOVGT R3,R1 MOVLE R3,R2 lbl_b B . END 代码2：使用C内嵌汇编语言 #include
参考答案 第一章 一、填空题。 1、嵌入式系统主要融合了计算机软硬件技术、通信技术和微电子技术，它是将计算机直接嵌入到应用系统中，利用计算机的高速处理能力以实现某些特定的功能。 2、目前国内对嵌入式系统普遍认同的定义是：以应用为中心、以计算机技术为基础、软硬件可裁剪、适应应用系统对功能、可靠性、成本、体积、功耗严格要求的专用计算机系统。 3、嵌入式系统一般由嵌入式计算机和执行部件组成，其中嵌入式计算机主要由四个部分组成，它们分别是：硬件层、中间层、系统软件层以及应用软件层。 4、嵌入式处理器目前主要有ARM、MIPS、Power PC、68K等，其中arm处理器有三大特点：体积小、低功耗、的成本和高性能，16/32位双指令集，全球合作伙伴众多。 5、常见的嵌入式操作系统有：Linux、Vxworks、WinCE、Palm、uc/OS-II和eCOS。 6、嵌入式系统开发的一般流程主要包括系统需求分析、体系结构设计、软硬件及机械系统设计、系统集成、系统测试，最后得到最终产品。 二、选择题 1、嵌入式系统中硬件层主要包含了嵌入式系统重要的硬件设备：、存储器（SDRAM、ROM等）、设备I/O接口等。（A） A、嵌入式处理器 B、嵌入式控制器 C、单片机 D、集成芯片 2、20世纪90年代以后，随着系统应用对实时性要求的提高，系统软件规模不断上升，实时核逐渐发展为，并作为一种软件平台逐步成为目前国际嵌入式系统的主流。（D） A、分时多任务操作系统 B、多任务操作系统 C、实时操作系统 D、实时多任务操作系统 3、由于其高可靠性，在美国的火星表面登陆的火星探测器上也使用的嵌入式操作系统是。（B） A、Palm B、VxWorks C、Linux D、WinCE [在此处键入]
《嵌入式系统》试题 闭卷答题时间:30分钟 一、填空题(请将答案填入题后括号中)：共10小题，每小题2分，满分20分。 1、一般而言，嵌入式系统的构架可以分为4个部分：分别是（）、存储器、输入/输出和软件，一般软件亦分为操作系统相关和（）两个主要部分。 2、根据嵌入式系统使用的微处理器，可以将嵌入式系统分为嵌入式微控制器，（），（）以及片上系统。 3、操作系统是联接硬件与应用程序的系统程序，其基本功能有（）、进程间通信、（）、I/O资源管理。 4、从嵌入式操作系统特点可以将嵌入式操作系统分为（）和分时操作系统，其中实时系统亦可分为（）和软实时系统。 5、内核负责管理各个任务，或者为每个任务分配CPU时间，并且负责任务之间的（），内核的基本服务是（）。 6、嵌入式开发一般采用（）方式，其中宿主机一般是指（）。 7、哈佛体系结构数据空间和地址空间（），ARM7TDMI采用（）的内核架构,ARM920T采用（）的内核架构。 采用（）级流水线结构，ARM920TDMI采用（）级流水线。 9.按操作系统的分类可知，Dos操作系统属于顺序执行操作系统，Unix 操作系统属于（）操作系统，VxWorks属于（）操作系统。 10、ARM7TDMI中，T表示支持16位Thumb指令集，D表示（），M表示内嵌乘法器Multiplier，I表示（），支持在线断点和调试。 二、选择题(请将答案填入题后括号中)：共10小题，每小题2分，满分20分。 1、要使CPU能够正常工作，下列哪个条件不是处理器必须满足的。（） (A)处理器的编译器能够产生可重入代码（B）在程序中可以找开或者关闭中断(C)处理器支持中断，并且能产生定时中断（D）有大量的存储空间 2、下面哪种操作系统最方便移植到嵌入式设备中。（） (A)DOS （B）unix (C)Windowsxp （D）linux 3、下面哪个选项不是SUB设备的特点。（） (A)串行通信方式（B）不可热拨插 (C)分HOST、DEVICE和HUB （D）通信速率比RS232快 4、下面哪种嵌入式操作系统很少用于手机终端设备上。（） (A)Symbian （B）WinCE (C)uc/os （D）linux 5、以下哪项关于SRAM和DRAM的区别是不对。（） (A)SRAM比DRAM慢（B）SRAM比DRAM耗电多 (C)DRAM存储密度比SRAM高得多（D）DRM需要周期性刷新 6、uc/os操作系统不包含以下哪几种状态。（） (A)运行（B）挂起 (C)退出（D）休眠 7、0x07&0x11的运算结果是。（） (A)0x01 （B）0x11 (C)0x17 （D）0x07 8、以下哪种方式不是uc/os操作系统中任务之间通信方式。（） (A)信号量（B）消息队列 (C)邮件（D）邮箱 9、以下哪种方式不是文件系统的格式。（） (A)FAT （B）DOS (C)NTFS （D）Ext 10、在将uc/os操作系统移植到ARM处理器上时，以下哪些文件不需要修改。（） (A) （B） (C) （D）OSTaskInit 三、判断题：共5小题，每小题2分，满分10分。 1、所有的电子设备都属于嵌入式设备。（） 2、冯诺依曼体系将被哈佛总线所取代。（） 3、嵌入式linux操作系统属于免费的操作系统。（） 4、移植操作系统时需要修改操作系统中与处理器直接相关的程序。（） 5、的最大通信速率为12M/S。（） 简答题：共2小题，每小题10分，满分20分。 1、根据嵌入式系统的特点，写出嵌入式系统的定义。 2、试分析实时操作系统的工作状态特点及相互之间的转换。
实验一开发环境的搭建与配置 【实验目的】 1)熟悉嵌入式Linux开发平台。 2)掌握嵌入式Linux开发平台的开发环境搭建与配置。 3)了解minicom配置串口通信参数的过程。 4)了解嵌入式Linux的启动过程。 5)掌握程序交叉编译运行及调试的一般方法。 【实验内容】 1)连接实验开发板与宿主机。 2)在虚拟机中的CentOS（宿主机）搭建开发环境。 3)在宿主机中配置minicom。 4)分析嵌入式Linux的启动过程。 5)在宿主机上编写简单的C语言程序并用交叉编译工具进行编译，然后传输到目标机上运行。 6)在宿主机上编写简单的C语言程序并用交叉编译工具进行编译，用gdbserver进行远程调试。 【实验步骤】 连接实验开发板，对虚拟机进行设置 1)首先把实验开发板打开，用网线和串口线连接宿主机，并连接电源（注意这时不要拨动实验 开发板的开关按钮）。 2)在桌面上点击打开vmware 软件，选择“编辑虚拟机设置”，如下图所示：
图1 3)进入虚拟机配置界面后把网络连接方式设置为“桥接方式”，如图2所示： 图2
4)添加串口，如下图所示： 图3 5)完成串口的添加后，选择“OK”,完成对虚拟机的设置。如下图所示：
图4 6)选择虚拟机的“Edit”、“Virtual Network Editor...”，如下图所示：
图5 7)进入虚拟机网络参数设置界面后对VMnet0进行设置（注意这里桥接的网卡应选择与实验开 发板相连接的那块儿网卡），然后点击“Apply”、“OK”如下图所示：
图6 8)上述设置完成后启动CentOS（CentOS的用户名为“root”，密码为“xidianembed”）。 工具链的配置 1)在CentOS的根目录下创建一个名为“EELiod”的目录，把实验中要用到的文件（主要是一 些rpm包）拷贝到该目录下。（可以用U盘、WinSCP等工具进行，此处不再做详细说明）。 2)交叉编译工具链位于/opt/buildroot-2011.02/output/host/usr目录下，进入工具链的bin目录下， 可以看到一些编译工具，这些工具将会在之后的交叉编译过程中使用到。
从软件工程的角度来说，嵌入式应用软件也有一定的生命周期，如要进行需求分析、系统设计、代码编写、调试和维护等工作，软件工程的许多理论对它也是适用的。 但和其他通用软件相比，它的开发有许多独特之处： ·在需求分析时，必须考虑硬件性能的影响，具体功能必须考虑由何种硬件实现。 ·在系统设计阶段，重点考虑的是任务的划分及其接口，而不是模块的划分。模块划分则放在了任务的设计阶段。 ·在调试时采用交叉调试方式。 ·软件调试完毕固化到嵌入式系统中后，它的后期维护工作较少。 下面主要介绍分析和设计阶段的步骤与原则： 1、需求分析 对需求加以分析产生需求说明，需求说明过程给出系统功能需求，它包括：·系统所有实现的功能 ·系统的输入、输出 ·系统的外部接口需求（如用户界面） ·它的性能以及诸如文件/数据库安全等其他要求 在实时系统中，常用状态变迁图来描述系统。在设计状态图时，应对系统运行过程进行详细考虑，尽量在状态图中列出所有系统状态，包括许多用户无需知道的内部状态，对许多异常也应有相应处理。 此外，应清楚地说明人机接口，即操作员与系统间地相互作用。对于比较复杂地系统，形成一本操作手册是必要的，为用户提供使用该系统的操作步骤。为使系统说明更清楚，可以将状态变迁图与操作手册脚本结合起来。
在对需求进行分析，了解系统所要实现的功能的基础上，系统开发选用何种硬件、软件平台就可以确定了。 对于硬件平台，要考虑的是微处理器的处理速度、内存空间的大小、外部扩展设备是否满足功能要求等。如微处理器对外部事件的响应速度是否满足系统的实时性要求，它的稳定性如何，内存空间是否满足操作系统及应用软件的运行要求，对于要求网络功能的系统，是否扩展有以太网接口等。 对于软件平台而言，操作系统是否支持实时性及支持的程度、对多任务的管理能力是否支持前面选中的微处理器、网络功能是否满足系统要求以及开发环境是否完善等都是必须考虑的。 当然，不管选用何种软硬件平台，成本因素都是要考虑的，嵌入式Linux 正是在这方面具有突出的优势。 2、任务和模块划分 在进行需求分析和明确系统功能后，就可以对系统进行任务划分。任务是代码运行的一个映象，是无限循环的一段代码。从系统的角度来看，任务是嵌入式系统中竞争系统资源的最小运行单元，任务可以使用或等待CPU、I/O设备和内存空间等系统资源。 在设计一个较为复杂的多任务应用系统时，进行合理的任务划分对系统的运行效率、实时性和吞吐量影响都极大。任务分解过细会不断地在各任务之间切换，而任务之间的通信量也会很大，这样将会大大地增加系统的开销，影响系统的效率。而任务分解过粗、不够彻底又会造成原本可以并行的操作只能按顺序串行执行，从而影响系统的吞吐量。为了达到系统效率和吞吐量之间的平衡折中，在划分任务时应在数据流图的基础上，遵循下列步骤和原则：
计算机三级《嵌入式系统开发技术》考试题及答案 1. GDB中，终止被调试的程序可以使用命令( B ) A.clear B.kill C.stop D.make 2. 以下不是引导程序的是( D ) A.VIVI B.U-Boot C.BLOB D.RT-Linux 3. 1024MB等于( B ) A.1TB B.1GB C.1KB D.1B 4. 以下是嵌入式系统的是( D ) A.VIVI B.U-Boot C.BLOB D.RT-Linux 5. GDB中，显示表达式的值使用命令( A )
A.display B.show https://www.doczj.com/doc/c87887593.html, D.list 6. EDSP只指( B ) A.嵌入式微控制器 B.嵌入式数字信号处理器器 C.嵌入式微处理 D.嵌入式片上系统 7. 能确定数据传输的宽度的是( A ) A.数据线 B.时序信号线 C.中断信号线 D.电源线 8. 世界上第一台计算机诞生在( B ) A.英国 B.美国 C.法国 D.苏联 9. 十进制数123，用十六进制表达为( C ) A.70 B.7A
C.7B D.7C 10. ARM采用定长指令格式，所有指令都是32位，Bit[15:11]为( B ) A.第一个操作数寄存器 B.目标寄存器编码 C.指示本指令操作是否影响CPSR的值 D.永远是0 11. 决定地线分别方式的线称为( D ) A.备用线 B.控制线 C.电源线 D.地线 12. 打包结束后得到的是一个( A ) A.二进制文件 B.文本文件 C.源文件 D.汇编文件 13. 以下有关进程和程序的说法正确的是( ABC ) A.进程是动态 B.程序是静态的 C.一个程序可以对应多个进程
嵌入式系统开发技术题库第3套 一、选择题 1:与个人计算机（PC）相比，嵌入式系统具有许多不同的特点。下面不属于嵌入式系统特点的是（）。A:嵌入式系统与具体应用紧密结合，具有很强的专用性 B:嵌入式系统通常包含在非计算机设备（系统）中，具有隐蔽性 C:嵌入式系统的软硬件资源往往受到严格的限制 D:嵌入式系统性能较低，价格也比较便宜 2:嵌入式系统中的CPU具有一些与通用计算机所使用的CPU不同的特点，下面不是其特点的是（）。A:支持实时处理 B:低功耗 C:高主频 D:集成了测试电路 3:嵌入式系统使用的片上系统英文缩写名为SoC，下面关于SoC叙述中错误的是（）。 A:SoC也称为系统级芯片，它是电子设计自动化水平的提高和集成电路制造技术飞速发展的产物 B:SoC芯片中既包含数字电路，也可以包含模拟电路，甚至还能包含数字/模拟混合电路和射频电路C:SoC将嵌入式系统的几乎全部功能都集成在一块芯片中，单个芯片就能实现数据的采集、转换、存储、处理和I/O等多种功能 D:SoC的设计制造难度很大，目前还没有得到广泛使用 4:微电子技术特别是集成电路制造技术是嵌入式系统发展的重要基础，下面关于集成电路的叙述中错误的是（）。 A:集成电路的集成度指的是单个集成电路所含电子元件（如晶体管、电阻、电容等）的数目多少 B:根据集成度的高低，集成电路可以分为小规模、中规模、大规模、超大规模和极大规模等几种 C:嵌入式系统中使用的处理器芯片属于大规模集成电路 D:集成电路的制造工艺复杂且技术难度非常高，许多工序必须在恒温、恒湿、超洁净的无尘厂房内完成 5:文字信息是人们用以表达和传递信息的媒体之一，大多数嵌入式系统都必须处理文字信息。下面关于文字信息的表示及其处理的叙述中，错误的是（）。 A:目前使用最广泛的西文字符集是ASCII字符集，它包含96个可打印字符 B:GB2312是我国目前广泛使用的汉字编码国家标准之一 C:GB2312包括6000多汉字，但不包含西文、俄文等其他字符 D:GB2312字符集中的汉字与符号在系统中采用双字节表示 6:假设一台数码相机一次可拍摄16位色1024 x 1024的彩色相片共80张，数据压缩比平均是4，则它使用的存储器容量大约是（）。 A:40MB B:60MB C:80MB D:120MB 7:在数字音频信息数字化过程中，正确的处理顺序是（）。 A:量化、取样、编码 B:取样、编码、量化 C:取样、量化、编码 D:编码、取样、量化 8:互联网借助TCP/IP协议把许多同构或异构的计算机网络互相连接起来，实现了遍布全球的计算机的互连、互通和互操作，其中的IP协议起着关键性的作用。下面有关IP协议的叙述中，错误的是（）。
嵌入式实验报告（二） 姓名：董辰辰 学号：111180031 专业：电子信息与科学 一、 实验目的 1、 了解Linux 内核源代码的目录结构以及各个目录的相关内容。 2、 了解Linux 内核各配置选项内容和作用。 3、 掌握Linux 内核的编译过程。 4、 了解嵌入式操作系统中文件系统的类型和作用。 5、 了解JFFS2文件系统的优点以及在嵌入式系统中的作用。 6、 掌握利用busybox 软件制作嵌入式文件系统的方法。 7、 掌握嵌入式Linux 文件系统的挂载过程。 二、实验内容和要求 1、配置完整的内核，尽可能理解配置选项在操作系统中的作用。 2、以 Busybox 为基础，构建一个合适的文件系统。 3、制作ramdiak 文件系统映像。 4、将自己编译生成的内核和文件系统下载进开发板。 5、讨论自己的嵌入式系统所具备的的功能。 6、比较romfs 、ext2fs/ext3fs 、JFFS2等文件系统的优缺点。 三、实验设计和分析 实验分为两个部分：Linux 内核配置编译和文件系统构建。本次实验的目的 就是自己搞一个内核和文件系统。当然自己编写代码是不太可能啦，而是根据 linux 提供的源代码自己配置编译出一个自己的内核，在构建一个自己需要的文 件系统。实验室用的内核版本是2.6.35.7 实验室的开发板有了内核和文件系统 才能够对其进行开发。内核是操作系统最基本的部分，可以说是一个软件，实验 室的开发板有处理器、内存、Flash 闪存等硬件组成，可以说内核是调度它们的 软件，有了内核各种应用程序才能够调用硬件资源，总的来说内核文件是操作系 统的核心，负责系统的进程管理，内存管理，设备和文件管理等，决定着系统的 性能和稳定性。文件系统是操作系统的一个重要组成部分，通过对操作系统所管 理的存储空间的抽象，向用户提供统一的、对象化的访问接口，屏蔽对物理设备 的直接操作和资源管理。我觉得内核的本质其实是程序，而文件系统是设置一些 规则来用来管理存储的，在一个完整的操作系统中两者都是不可或缺的，内核在 加载的时候需要有很多的挂载指令，应该挂载的就是文件系统的文件夹，比如将 proc 文件系统挂载到proc 文件夹，这就是为什么在开发板启动时内核和文件系 本页已使用福昕阅读器进行编辑。福昕软件（Ｃ）２００５－２００９，版权所有，仅供试用。
实验四嵌入式Linux开发环境的搭建 一、实验目的 1、了解嵌入式Linux开发环境的作用 2、掌握相关服务器的安装 二、实验准备 硬件：JXARM9-2410教学实验箱，PC机 软件：Windows XP操作系统，ADS集成开发工具 三、实验过程 1、tftp网络配置 (1) 虚拟机网络配置 a. 点击虚拟机-设置，将网络适配器设置为自定义，并 指定虚拟网络为VMnet0。 b. 点击编辑-虚拟机网络参数-主机虚拟网络映射，并 且指定其桥接的网卡
c. Red Hat IP配置 ●点击系统设置-网络，双击eth0配置IP信息如下： 地址：172.20.11.243 子网掩码：255.255.255.0 默认网关地址：172.20.11.254 DNS: 210.29.152.4 ●点击激活，在弹出的对话框点击是按钮 ●
测试网络连接是否正常 方法一：在linux下，点击系统工具-终端，输入命令ping 172.20.11.243 方法二：在主系统中打开命令提示符，输入ping 172.20.11.243 (2)修改tftp的配置文件 a.在终端下输入gedit /etc/xinetd.d/tftp b.修改”disable=yes”为”=no”,点击保存，关闭gedit
c.重启xinetd服务，使刚才的更改生效,在终端里输入， /etc/init.d/xinetd restart d.进入tftpboot文件夹创建一个测试文件testfile e.取得tftpboot文件夹的所有权限，命令chmod 777 /tftpboot f.启动tftp测试上传和下载 2配置NFS服务器 a.设置：开始->系统设置->服务器设置->NFS服务器打开配置对话 框 第一步：点击添加nfs共享 第二步：输入目录/tftpboot 第三步：输入主机172.20.11.243 第四步：基本权限为读/写
嵌入式Linux具有稳定、可伸缩及开放源代码等特点，可兼容多 种处理器和主机，广泛适用于各种产品和应用。但是，交叉编译、 设备驱动程序开发/调试，以及更小尺寸等要求对嵌入式Linux开 发者来说都是严峻的挑战。为应对这些挑战，针对嵌入式Linux开 发的专用工具应运而生，而且发展十分迅猛。 但是，许多这类开发工具都不兼容非X86平台，而且也没有很好 地实现归档备案或集成。在其它开发环境下，组件间的高度集成并 没有完全兑现。因此，要想完全从这些免费的软件组件开始创建 一个完整的跨平台开发环境，开发者应意识到这将需要大量的调 研、实施、培训和维护方面的工作。 Linux 是少数既可以在嵌入式设备上运行也可作为开发环境的操 作系统之一。这一特性可让开发者在转向此开发系统之前于常用硬 件(比如X86桌面系统)之上开发、调试和测试应用程序和库，因 此可减少对标准参考平台和指令集仿真器的依赖。这一技术仅适用于应用程序和库，但不适用于设备驱动程序，因为后者的开发依赖于 Linux架构。 开放源代码团体及一些软件供应商可提供设备驱动程序开发工具。由于设备驱动程序比标准应用程序距离硬件更近，因此它们的开发比较困难。所幸的是，Linux 桌面系统可以利用一些Windows及其它操作系统所没有的工具。有足够经验开发设备驱动程序的开发人员可能已经习惯将Linux作为他们的桌面开发系统了。 Linux的快速发展及其桌面方案的不断涌现提出了一个重要问题：所选择的工具方案怎样在不同的Linux分布式系统上运行？它们依赖于主机平台的软件配置吗？ 有些Linux工具提供独立于主机平台的开发环境，包括一系列可支持开发工具的应用软件、库和实用程序。这一方法几乎将开发环境与主机配置完全隔离开来，因此主机可以是任何Linux分布式系统，而且任何更新和修改都不会影响开发环境的功能。 这种方法的主要缺点是对存储空间的要求有所增加――约200MB，因为它自己实际上相当于一个微型Linux分布式系统。 可用的工具 一个嵌入式Linux产品的开发需要几个阶段，包括为目标板配置和构建基本Linux OS；调试应用程序、库、内核及设备驱动程序/内核模块；出货前最终方案的优化、测试和验证。 有数百种开放源代码开发工具可供选择。只要开发者原意花时间和精力去调研、实施和维护一系列各不相同的工具，总能找出一个完整的解决方案，完成几乎任何开发任务。
《嵌入式开发》期中试卷 试卷适用范围：2011级计算机科学与技术（本）1、2班 一、填空题（每空1分，共46分） 习题 1 1．填空题 （1）嵌入式系统是以应用为中心、以计算机技术为基础，软、硬件可裁剪，适应于应用系统对功能、可靠性、成本、体积、功耗等方面有特殊要求的专用计算机系统。 （2）嵌入到对象体系中的专用计算机系统。嵌入性、专用性与计算机系统是嵌入式系统的三个基本要素。对象系统是指嵌入式系统所嵌入的宿主系统。 （3）嵌入式系统按形态可分为设备级（工控机）、板级（单板、模块）、芯片级（MCU、SOC）。 （4）嵌入式系统由硬件和软件两大部分组成，硬件一般由高性能微处理器和外围接口电路组成，软件一般由操作系统和应用程序构成，软件和硬件之间由所谓的中间层（BSP层，板级支持包）连接。 （5）嵌入式系统从组织层次上看，嵌入式系统一般由硬件层、中间层、软件层和功能层组成。 （6）在专用的嵌入式板子上面运行GNU/Linux系统已经变得越来越流行。一个嵌入式Linux系统从软件的角度看通常可以分为四个层次：引导加载程序、 Linux内核、文件系统、用户应用程序。 （7）嵌入式系统硬件的核心部件是各种类型的嵌入式处理器。 （8）嵌入式系统的核心部件是嵌入式处理器，一般把嵌入式处理器分成4类，即微处理器、微控制器、数字信号处理器、和嵌入式片上系统。 （9）ARM公司首创了 chipless 的生产模式，专门从事基于RISC技术芯片的设计开发，公司本身并不生产芯片，而是设计出高效的IP内核，授权给半导体公司使用。 （10）ARM7TDMI中，T表示支持Thump指令集。D表示支持片上调试（Debug）。M表示内嵌硬件乘法器（Multiplier）。I表示支持片上断点和调试点。 （11）ARM9系列微处理器包含ARM920T、ARM922T和ARM940T三种类型，以适用于不同的应用场合。 （12）ARM微处理器有两种工作状态：Thump状态、ARM状态。 （13）通用寄存器分为三类：未分组寄存器、分组寄存器、程序计数器（PC）。 （14）异常是由内/外部源引起的需要处理器干预的一个事件。 （15）精简指令集计算机RISC（Reduced Instruction Set Computer）和复杂指令集计算机CISC 是当前CPU的两种架构。 （16）ARM微处理器的在较新的体系结构中支持两种指令集： ARM指令集、Thump指令集。 （17）MMU的作用有两个：将虚拟地址转化为物理地址、对存储器访问的