Unit 1:- Overview of Embedded System:

An Embedded System can be defined as a computing device that does a specific focused job. Appliances such as the air-conditioner, VCD player, DVD player, printer, fax machine, mobile phone etc. are examples of embedded systems. Each of these appliances will have a processor and special hardware to meet the specific requirement of the application along with the embedded software that is executed by the processor for meeting that specific requirement. The embedded software is also called firm ware. The desktop/laptop computer is a general purpose computer. You can use it for a variety of applications such as playing games, word processing, accounting, software development and so on. In contrast, the software in the embedded systems is always fixed. OR An Embedded System can be defined as a control system or computer system designed to perform a specific task. Common examples of embedded systems include MP3 players, navigation systems on aircraft and intruder alarm systems. An embedded system can also be defined as a single purpose computer. Most embedded systems are time critical applications meaning that the embedded system is working in an environment where timing is very important: the results of an operation are only relevant if they take place in a specific time frame.

1.1 Embedded Systems:

The first question that needs to be asked is "What exactly is an EMBEDDED COMPUTER? An embedded computer is frequently a computer that is implemented for a particular purpose. In contrast, an average PC computer usually serves a number of purposes: checking email, surfing the internet, listening to music, word processing, etc... However, embedded systems usually only have a single task, or a very small number of related tasks that they are programmed to perform. Every home has several examples of embedded computers. Any appliance that has a digital clock, for instance, has a small embedded microcontroller that performs no other task than to display the clock. In general, an Embedded System: Is a system built to perform its duty, completely or partially independent of human intervention? Is specially designed to perform a few tasks in the most efficient way. Interacts with physical elements in our environment, viz. controlling and driving a motor, sensing temperature, etc. OR An Embedded System is a special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Embedded systems control many of the common devices in use today. Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale. E H Ansari

Here Real Time Computing means, is the study of hardware and software systems that are subject to a "real-time constraint"i.e., operational deadlines from event to system response. By contrast, a non-real-time system is one for which there is no deadline, even if fast response or high performance is desired or preferred. The needs of real-time software are often addressed in the context of real-time operating systems, and synchronous programming languages, which provide frameworks on which to build real-time application software. OR In general, "embedded system" is not an exactly defined term, as many systems have some element of programmability. For example, Handheld computers share some elements with embedded systems such as the operating systems and microprocessors which power them but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected. Embedded systems are typically implemented with programmable devices: microprocessors, microcontrollers, FPGAs or EEPROM and Flash memories. Contrary to microprocessors that require external peripherals to operate, microcontrollers have built-in peripherals on the chip, reducing the size of the system. There are many different CPU architectures used in embedded systems such as ARM, x86, PIC, AVR, PowerPC, etc. Use of FPGAs enables to create SoPC (System on a Programmable Chip) designs where all logic is programmed into the FPGA, including the CPU. ASICs are common only in very-high-volume embedded systems because of their very high initial costs. Power consumption of portable devices is limited because these devices are generally powered from battery. Therefore the low power consumption is very important in this case.

What are Embedded Systems used for?

The uses of embedded systems are virtually limitless, because every day new products are introduced to the market that utilizes embedded computers in novel ways. In recent years, hardware such as microprocessors, microcontrollers, and FPGA chips have become much cheaper. So when implementing a new form of control, it's wiser to just buy the generic chip and write your own custom software for it. Producing a custom-made chip to handle a particular task or set of tasks costs far more time and money. Many embedded computers even come with extensive libraries, so that "writing your own software" becomes a very trivial task indeed. From an implementation viewpoint, there is a major difference between a computer and an embedded system. Embedded systems are often required to provide Real-Time response. A Real-Time system is defined as a system whose correctness depends on the timeliness of its response. Examples of such systems are flight control systems of an aircraft, sensor systems in nuclear reactors and power plants. For these systems, delay in response is a fatal error. A more relaxed version of Real-Time Systems is the one where timely response with small delays is acceptable. Example of such a system would be the Scheduling Display System on the railway platforms. In technical terminology, Real-Time Systems can be classified as: Hard Real-Time Systems - systems with severe constraints on the timeliness of the response. Soft Real-Time Systems - systems which tolerate small variations in response times. Hybrid Real-Time Systems - systems which exhibit both hard and soft constraints on its performance. E H Ansari

What are the Strengths & Downfalls of an Embedded System?

Strengths: Smaller silicon size for logic functions combined with higher operating security and better testability Flexible wiring of PCB trough high degree of freedom of PIN layout Re-design while specs change only requires re-programming/reconfiguration High degree of integration and specific security mechanism against un-allowed SW reading which results in an optimized know-how-security Effective design through CAD/CAE-tools Design of application specific processors based on VHDL-models on the several design levels: # algorithmic level (AL) # register transfer level (RTL) # logic level (LL) Downfalls: Embedded computers may be economical, but they are often prone to some very specific problems. A PC computer may ship with a glitch in the software, and once discovered, a software patch can often be shipped out to fix the problem. An embedded system, however, is frequently programmed once, and the software cannot be patched. Even if it is possible to patch faulty software on an embedded system, the process is frequently far too complicated for the user.

Another problem with embedded computers is that they are often installed in systems for which unreliability is not an option. For instance, the computer controlling the brakes in your car cannot be allowed to fail under any condition. The targeting computer in a missile is not allowed to fail and accidentally target friendly units. As such, many of the programming techniques used when throwing together production software cannot be used in embedded systems. Reliability must be guaranteed before the chip leaves the factory. This means that every embedded system needs to be tested and analyzed extensively. An embedded system will have very few resources when compared to full blown computing systems like a desktop computer, the memory capacity and processing power in an embedded system is limited. It is more challenging to develop an embedded system when compared to developing an application for a desktop system as we are developing a program for a very constricted environment. Some embedded systems run a scaled down version of operating system called an RTOS (real time operating system).

1.2 Categories & Requirements of an Embedded System: Categories of an Embedded System:

Based on functionality and performance requirements, embedded systems can be categorized as: Stand-alone embedded systems Real-time systems Networked information appliances E H Ansari

 Mobile devices

Stand alone Embedded Systems:

As the name implies, stand-alone systems work in stand-alone mode. They take inputs, process them and produce the desired output. The input can be electrical signals from transducers or commands from a human being such as the pressing of a button. The output can be electrical signals to drive another system, an LED display or LCD display for displaying of information to the users. Embedded systems used in process control, automobiles, consumer electronic items etc. fall into this category. In a process control system, the inputs are from sensors that convert a physical entity such as temperature or pressure into its equivalent electrical signal. These electrical signals are processed by the system and the appropriate electrical signals are produced using which an action is taken such as opening a valve. A few embedded systems used at home are Camera, Microwave Oven and CD/DVD Player etc. BUT, Embedded systems are not always standalone devices. Many embedded systems consist of small, computerized parts within a larger device that serves a more general purpose. For example, the Gibson Robot Guitar features an embedded system for tuning the strings, but the overall purpose of the Robot Guitar is, of course, to play music. Similarly, an embedded system in an automobile provides a specific function as a subsystem of the car itself.

Real Time Systems:

Embedded systems in which some specific work has to be done in a specific time period are called Real-Time Systems. For example, consider a system that has to open a valve within 30 milliseconds when the humidity crosses a particular threshold. If the valve is not opened within 30 milliseconds, a catastrophe may occur. Such systems with strict deadlines are called hard real-time systems. In some embedded systems, deadlines are imposed, but not adhering to them once in a while may not lead to a catastrophe. For example, consider a DVD player. Suppose, you give a command to the DVD player from a remote control, and there is a delay of a few milliseconds in executing that command. But, this delay wont lead to a serious implication. Such systems are called soft real-time systems.

Networked Information Appliances:

Embedded Systems that are provided with network interfaces and accessed by networks such as Local Area Network or the Internet are called networked information appliances. Such embedded systems are connected to a network, typically a network running TCP/IP (Transmission Control Protocol! Internet Protocol) protocol suite, such as the Internet or a companys Intranet. These systems have emerged in recent years. These systems run the protocol TCP/IP stack and get connected either through PPP or Ethernet to a network and communicate with other nodes in the network. Here are some examples of such systems: A networked process control system consists of a number of embedded systems connected as a Local Area Network. Each embedded system can send real-time data to a E H Ansari

central location from where the entire process control system can be monitored. The monitoring can be done using a web browser such as the Internet Explorer. A web camera can be connected to the Internet. The web camera can send pictures in real-time to any computer connected to the Internet. In such a case, the web camera has to run the HTTP server software in addition to the TCP/IP protocol stack. The door-lock of your home can be a small embedded system with TCP/IP and HTTP server software running on it. When your children stand in front of the door-lock after they return from school, the web camera in the door lock will send an alert to your desktop over the Internet and then you can open the door-lock through a click of the mouse. Desktop Compute Interne t

Weather Monitoring System Fig. 1.3 shows a weather monitoring system connected to the Internet. TCP/IP protocol suite and HTTP web server software will be running on this system. Any computer connected to the Internet can access this system to obtain real-time weather information. The networked information appliances need to run the complete TCP/IP protocol stack including the application layer protocols. If the appliance has to provide information over the Internet, HTTP web server software also needs to run on the system. Mobile Devices: Mobile devices such as mobile phones, Personal Digital Assistants (PDAs), smart phones etc. are a special category of embedded systems. Though the PDAs do many general purpose tasks, they need to be designed just like the conventional embedded systems. The limitations of the mobile devices are memory constraints, small size, lack of good user interfaces such as full-fledged keyboard and display etc.-are same as those found in the embedded systems. Hence, mobile devices are considered as embedded systems. However, the PDAs are now capable of supporting general purpose application software such as word processors, games, etc

Requirements of an Embedded System:

1) Dynamic and configurable environment: Embedded systems are generally deployed in environments that are highly dynamic and configurable. For example, the environment of an embedded system deployed in a battlefield is extremely dynamic. 2) Interconnected network of components: Frequently an embedded system is a complex network of components. Therefore, a malicious or accidental fault in a component can lead to a complex cascade of events in the network. 3) Recovery is paramount: Generally, techniques developed in the realm of software security focus on detection and prevention. Embedded systems are frequently deployed in mission critical applications where consequences of failures can be dire. Therefore, recovery from failures is extremely important in the context of embedded systems. 4) High dependability requirements: E H Ansari

Reliability R (t) = probability of system working correctly provided that is was working at t=0. Maintainability M (d) = probability of system working correctly d time units after error occurred. Availability A (t): probability of system working at time t. Safety: no harm to be caused

Security: confidential and authentic communication 5) Must be efficient Energy Efficient Code-Size Efficient Runtime Efficient Weight Efficient Cost Efficient 6) Trend to replace conventional mechanics by digital embedded components. Reasons: Production cost, Functionality, Weight, Size. 7) A component should have: A unique identifier A documentation Ports (input/output) Contracts Property set Possible required components 8) Classification: A component can be classified. This affects e.g. a component's visibility, which could be restricted to a project, group, department etc. 9) Interfaces: The component has to provide concepts to specify a component's interfaces. The concepts shall be as flexible as possible to allow e.g. procedural and object-oriented (with and without polymorphism) interfaces. Type safety must be guaranteed. The interface specification has to be separated from the implementation. 10) Multiple Interfaces: It must be possible to define more than one interface for a component. 11) Unique Identifier: Each component has to have a unique ID by which it can always be identified. 12) Key Words: Each component is characterized by a few key words (the abstract). 13) Containment: The model has to support building hierarchies. 14) Completeness: The model and its contents must be sufficient (contain enough information) for code generation. 15) Portability: The component has to be implementation language independent. However, the concepts must be realizable at least in C/C++ and Java. 16) Textual Format / Openness: The specification of components has to be in a textual format. The format has to be tool and vendor independent ( use open standards). E H Ansari

IMPORTANT: Characteristics of an Embedded System:

Embedded systems are characterized by some special features listed below: Embedded systems do a very specific task; they cannot be programmed to do different things. Embedded systems have very limited resources, particularly the memory. Generally, they do not have secondary storage devices such as the CDROM or the floppy disk. Embedded systems have to work against some deadlines. A specific job has to be completed within a specific time. In some embedded systems, called real-time systems, the deadlines are stringent. Missing a deadline may cause a catastrophe-loss f life or damage to property. Embedded systems are constrained for power. As many embedded systems operate through a battery, the power consumption has to be very low. Embedded systems need to be highly reliable. Once in a while, pressing ALT-CTRL-OEL is OK on your desktop, but you cannot afford to reset your embedded system. Some embedded systems have to operate in extreme environmental conditions such as very high temperatures and humidity. The program instructions written for embedded systems are referred to as firmware, and are stored in read-only memory or Flash memory chips. They run with limited computer hardware resources: little memory, small or non-existent keyboard and/or screen. Embedded systems that address the consumer market (for example, electronic toys) are very cost-sensitive: Even a reduction of $0.1 is lot of cost saving, because thousands or millions systems may be sold. Unlike desktop computers in which the hardware platform is dominated by Intel and the operating system is dominated by Microsoft, there is a wide variety of processors and operating systems for the embedded systems. So, choosing the right plat-form is the most complex task.

1.4 Challenges & Issues in Embedded System Development:

A. Computer Design Requirements: Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets. 1. Real time/reactive operation Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. In many cases the system design must take into account worst case performance. Predicting the worst case may be difficult on complicated architectures, leading to overly pessimistic estimates erring on the side of caution. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements. Reactive computation means that the software executes in response to external events. These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be a periodic, in which case the E H Ansari

maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component. Design challenge:

Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics (e.g., cache memory).

2. Small size, low weight Many embedded computers are physically located within some larger artifact. Therefore, their form factor may be dictated by aesthetics, form factors existing in pre-electronic versions, or having to fit into interstices among mechanical components. In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type. Design challenges:

Non-rectangular, non-planar geometries. Packaging and integration of digital, analog, and power circuits to reduce size.

3. Safe and reliable Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer. Traditionally, such systems have employed multiply-redundant computers or distributed consensus protocols in order to ensure continued operation after an equipment failure. Design challenge:

Low-cost reliability with minimal redundancy.

4. Harsh environment Many embedded systems do not operate in a controlled environment. Excessive heat is often a problem, especially in applications involving combustion (e.g., many transportation applications). Additional problems can be caused for embedded computing by a need for protection from vibration, shock, lightning, power supply fluctuations, water, corrosion, fire, and general physical abuse. For example, in the Mission Critical example application the computer must function for a guaranteed, but brief, period of time even under non-survivable fire conditions. Design challenges:

Accurate thermal modeling. De-rating components differently for each design, depending on operating environment. E H Ansari

5. Cost sensitivity Even though embedded computers have stringent requirements, cost is almost always an issue (even increasingly for military systems). Although designers of systems large and small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically. A reason for this may be that the effect of computer costs on profitability is more a function of the proportion of cost changes compared to the total system cost, rather than compared to the digital electronics cost alone. Design challenge:

Variable "design margin" to permit tradeoff between product robustness and aggressive cost optimization.

B. System-level requirements In order to be competitive in the marketplace, embedded systems require that the designers take into account the entire system when making design decisions. 1. End-product utility The utility of the end product is the goal when designing an embedded system, not the capability of the embedded computer itself. Embedded products are typically sold on the basis of capabilities, features, and system cost rather than which CPU is used in them or cost/performance of that CPU. Design challenge:

Software- and I/O-driven hardware synthesis (as opposed to hardware-driven software compilation/synthesis).

2. System safety & reliability A bigger and more difficult issue at the system level is software safety and reliability. While software doesn't normally "break" in the sense of hardware, it may be so complex that a set of unexpected circumstances can cause software failures leading to unsafe situations. Design challenges:

Reliable software. Cheap, available systems using unreliable components. Electronic vs. non-electronic design tradeoffs.

3. Controlling physical systems The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. In order to do this, analog inputs and outputs must be transformed to and from digital signal levels. Additionally, significant current loads may need to be switched in order to operate motors, light fixtures, and other actuators. All these requirements can lead to a large computer circuit board dominated by non-digital components. E H Ansari

Design challenge:

Distributed system tradeoffs among analog, power, mechanical, network, and digital hardware plus software.

4. Power management A less pervasive system-level issue, but one that is still common, is a need for power management to either minimize heat production or conserve battery power. While the push to laptop computing has produced "low-power" variants of popular CPUs, significantly lower power is needed in order to run from inexpensive batteries for 30 days in some applications, and up to 5 years in others. Design challenge:

Ultra-low power design for long-term battery operation.

************************* *

E H Ansari

10

Unit 2: - Embedded Hardware & Software Development

Environment:
2.1 Hardware Architecture: The Hardware Architecture of an Embedded System is as follows:

1. Processor : It is the brain of an Embedded Logic Circuit. We can use three types

of processors for designing an embedded system, as per the requirement, namely: a. 8 bit Microcontroller: This type of processor is used for the application where power and space requirement is high but processing power and memory requirement is low. Like electronic toys, smart card etc. Some 8 bit Microcontrollers are i. 8051 ii. PIC iii. Motorola b. 32 bit Microprocessor: This type of processor is used for the application where power and space requirement is low but processing power and memory requirement is high. Like handheld computers etc. Some 8 bit Microprocessors are i. MIPS ii. Atmel iii. Rabbit
E H Ansari

11

(Digital Signal Processor): This type of processor is used for applications where signals are handled than data, like audio video applications. It contains a MAC unit which performs all complex floating point Fourier calculation. Some DSP are i. Analog Devices ii. Digital Devices 2. Memory : In the case of microcontroller internal/external memory are used i.e. RAM & ROM. BUT, there are various types of memory used, Internal RAM, External RAM, Internal Cache, Flash/EEPROM, ROM/PROM and Memory Address 3. Address Latch: Address Latch in embedded system is used to connect external memories with microcontroller. 4. Crystal : Crystal provides clock signal for the processor. 5. LED/LCD : These are the standard output devices, for viewing the critical value. These are shaped into a thin, flat panel made up of many number of color filled with crystals & arrayed in front of light source. 6. Keypad : It is a standard input device for setting critical values. It is a set of buttons arranged in blocks which usually bear digits & other symbols but not a complete set of alphabets. 7. External Latch: It is a device which is used to interface microcontroller with LED/LCD 8. Buffer : It is used to interface keypad with microcontroller. 9. Chip Select (CS): In some applications multiple processors are used in parallel format. Chip Select is used to produce chip select signal among processors. 10. ADC/DAC : Processors handles only digital signals, so external analog signals are handled by the logic circuit through ADC/DAC block. 11. Application Specific Control Circuit: The exact hardware architecture depends on the specific application. Application specific control circuit is used to control external additional functional blocks, for the specified applications. 12. Communication Interface: It interfaces logic circuits with other external systems through some standards like IrDA, Ethernet, Bluetooth, PCI Bus etc. 13. Reset Circuit: Reset circuit is used to initiate all the hardware blocks when any error or interrupt occurs in any of the functional block. All functional blocks are assembled on a single PCB board. This main board has a minute size, so probabilities of physical invasive attacks are more on these boards. So, all the main boards are installed in a smart device with special protection for providing better security. 2.2 Microcontroller Architecture:
DO YOURSELF

c. DSP

E H Ansari

12

2.3 Communication Interface Standards: Communication Interfaces are used to transmit the data to a PC or work station with another system. For meeting this, there are number of interface standards in Embedded System for communication. Some of them are as follows: A. Serial Communication Interfaces: It can transmit one bit of data at a time. i. RS232: It is used for connecting serial devices. The device that connects to the interface is data communication equipment and one to which the interface is connected is data terminal equipment. It is used in notebooks, portable computers etc. ii. RS422: It is a balanced serial interface for the transmission of digital data. It supports greater distance, higher data rate and greater immunity to electrical interference. iii. RS 485: It works in multipoint applications. It is compatible with RS 422 and provides a 2 wire bus topology. Used in applications where a single controller needs to control multiple devices. B. USB: It was designed to simplify the connections between a host PC and up to 127 associated peripherals. In particular, it was intended to open up the PC to peripherals that didnt exist at the time that the USB bus was created. It is designed to be low cost and very easy for the average end user to connect and use. There are three transmission standards under the USB label namely, a. Low Speed: It is designed for human interface devices (HID) with short, infrequent messages. Example devices are keyboards, mice, and monitor configuration applications. Data rates are limited to 10 to 100 Kbps and messages are limited to 8 bytes or fewer. The specification states that devices in this class are limited to one 8-byte message every 10 ms, although Win98 doesnt enforce this limit. b. Full Speed or Medium Speed: It is designed to take over audio and telephone applications and can run at 500 Kbps to 10 Mbps Maximum data payload is 8, 16 32 or 64 bytes per message. Full Speed guarantees message latency and bandwidth. c. High Speed: It is designed for video and disk applications. It can run at 25 to 500 Mbps. It also guarantees latency and high bandwidth.
C. Bluetooth: Bluetooth is primarily intended for short-range cable replacement

applications. Products available now include wireless mice, keyboards, headphones, wireless hands free cell phones and RS232 cable replacement. Bluetooth features cheap hardware, at least in comparison to other RF solutions, but certification costs offset this in low volumes. Bluetooth must coexist with many competing transmitters in the same band including microwave ovens, portable phones, garage door openers and many other radio services including Wi-Fi. A Bluetooth connection is designed for either point to point

E H Ansari

13

with exactly two ends (called unicasting), or a point to multipoint configuration (multicasting). D. I2C: It is a low to medium data rate master slave communication bus. The bus consists of two wires of circuit one for clock and other for data with a pull up resistor on each wire of the bus. E. SPI (Serial Peripheral Interface): It is operated in full duplex mode device and communicates in master/slave mode where the master device initiates the data. Some advantages & disadvantages of SPI are Advantages: a. Higher throughput than I2C b. Extremely simple hardware interfacing c. Low power requirement Disadvantages: a. No h/w flow control b. Handles only short distances. c. Require more pins on IC package
F. CAN: It was originally developed as the Car Area Network by Bosch for automotive engine controller applications. As such, it is extremely reliable in noisy environments, very low cost, widely available, and has lots of development support. Renamed the Controller Area Network, it has found wide acceptance in many stationary applications including vending machines. CAN is the lowest cost communication protocol. It is an excellent choice for large networks of hard-wired controllers that need to exchange medium quantities of data at medium rates. CAN is fully differential and has built-in CRC and automatic message resend if necessary. The CAN controller handles all error detection and message retransmission; the designer does not have to even think about them. However, this does mean that message timing can be described as elastic at best. Messages will eventually get through, but priority must be planned carefully in advance. All messages are broadcast to all nodes. Every message is accepted either by every node or by no nodes. In the latter case, it will be retransmitted automatically. Although a node receives every message, it only acts on some as described below. G. PCI Bus: It is a high performance bus for interconnecting chips. H. IrDA: It is a transmission standard commonly used in computer and peripherals

like mobile phones etc. It provides device to device communication over a short distance. I. PIC, IEEE BUS Standard, USART, UART etc.and the list goes on 2.4 Embedded System Development Process: Embedded System Development Process consists of two basic steps. i. Embedded Hardware System Development Process ii. Embedded Software System Development Process Using these two development process one can develop an Embedded System. Let us start from the first step i.e. hardware system development process. Embedded Hardware System Development Process:
E H Ansari

14

In developing a hardware system, for an Embedded System, there are few steps to be carried out and they are as follows: a) Determining the requirements of an Embedded System: The requirements can be divided into functional requirements, which are determined as per the application used. The functional requirements dictate the hardware components namely. I/O peripherals, External Interfaces, Input devices, Output devices etc., and non-functional requirements, which are size, cost and power consumption. b) Designing the system architecture: As per the requirements for hardware system, the system architecture is designed to fulfill the engineering requirements. c) Choosing the Operating System: For choosing the appropriate operating system for developing a hardware system for embedded system we must go through the following, i. Timing requirement ii. Processor Support for operating system iii. Footprint of an operating system iv. support for JAVA v. Cost of the Operating System d) Choosing the appropriate processor : Based on functionality, processing speed & memory addressing capability we select a processor. i 8bit microcontroller ii 16 ar 3L bit Microprocessor iii Digital signal processing e) Choosing the development platform i ii iii iv Hardware Platform Operating System Programming Language Development Tools programming language: Major engineering software

f) Choosing

development projects are coded is C but with the availability of Microsoft Embedded Visual Tool we write application for Window CE or Embedded NT in VC++ language. If any system provides JVM, we can write application in JAVA.
g) Verify the Software on the host system: There are certain norms of

verifying the software on the host system: i. ii. Compile and assemble the source code of the software into object codes. Link all the object files to a single object file. The linking of object file to a single file is done by a Linker which runs on the host machine.
E H Ansari

15

iii.

Relocate the single object file in which physical memory addresses are assigned using loader.

h) Verify the software on the targeted system: There are certain norms of

verifying the software on the targeted system: i. Once the software is tested on the host system it is ported on the targeted system and ported on the targeted board for carrying out the testing for functionality & performance requirements. Embedded Software System Development Process: Goal is to develop a quality product which should reflect all customers requirements, functionality requirements, performance requirements & reliability requirements. In developing a software system, for an Embedded System, there are few steps to be carried out and they are as follows: a) Engineering Requirements: Based on the input/output we can develop a new product. Some needs are I/O of the system, Time, Size, Cost, Communication Standards etc. b) Design Trade-off: i. To meet all functional & performance requirements ii. To reduce the size of the system and hence cost too iii. To reduce the power requirement iv. To reduce maintenance effort & hence time. v. To increase reliability c) Hardware & Software Design: Hardware Design: i. Selection of processor ii. Calculation of memory requirement iii. Identification of I/O devices iv. Communication Standards Software Design: i. Working out the details of the processing to be done ii. iii. iv. Decomposition of the processing Calculation of processing time and resource required for processing Deciding the use of an Operating System
d) Implementation: In designing a software system for an embedded system,

hardware and software implementation go in parallel format. In hardware implementation we do the following steps: i. ii. Develop the circuit Obtain the PCB
E H Ansari

16

iii. iv. v.

Procure the components Assemble the components & testing the industrial module Test complete hardware

Once hardware is implemented we can now implement the software part. Software implementation is done by programming the whole system.
e) Operation & Maintenance: This is the last phase of the Embedded System. It

gives the final & wanted product to the clients. 2.5 Embedded Operating Systems: What is an Embedded OS?
An embedded operating system is an operating system for embedded computer systems. These operating systems are designed to be very compact and efficient, forsaking many functions that non-embedded computer operating systems provide, and which may not be used by the specialized applications they run. They are frequently also real-time operating systems. An embedded operating system is essentially a stripped down operating system with a limited number of features. It is typically designed for very specific functions for controlling an electronic device. For example, all cell phones use an operating system that boots up when the phone is turned on. It handles all the basic interface and features of the phone. Additional programs can be loaded onto the phones, but they are typically JAVA applications that run on top of the operating system. Embedded operating systems can either be custom written operating systems specific to the device or one of the myriad of general purpose operating systems that has been modified to run on top of the device. Common embedded operating systems include Symbian (cell phones), Windows Mobile/CE (handheld PDAs) and Linux. In the case of an embedded OS on a personal computer, this is an additional flash memory chip installed on a motherboard that is accessible on boot from the PC. Examples of embedded operating systems could include the software used in Automated teller machines, Cash Registers, CCTV systems, jukeboxes and suchlike.

Why Put an Embedded OS on a PC?

The main reason is to expand the capabilities of the system without the need to be running all of the hardware. The other major benefit of an embedded operating system on a PC is to speed up the ability to use the system for specific functions. The average system takes anywhere from one to five minutes to fully boot up the Vista operating system from a cold start. An embedded operating system could be loaded up from a cold start in a matter of seconds.

2.6 Types of Embedded Operating System:

A/ROSE

:-

E H Ansari

17

A/ROSE (the Apple Real-time Operating System Environment) was a small embedded operating system which ran on Apple Computer's Macintosh Coprocessor Platform, an expansion card for the Apple Macintosh. The idea was to offer a single "overdesigned" hardware platform on which 3rd party vendors could build practically any product, reducing the otherwise heavy workload of developing a Nimbus-based expansion card. A/ROSE itself was very small, the kernel using only 6k, and the operating system as a whole about 28k. A/ROSE supported pre-emptive multitasking with round-robin task scheduling with a 110 microsecond context switch time and only 20 microseconds of latency (guaranteed interrupt response time). A/ROSE was a message passing system, and the main calls made by programs running under it were Send () and Receive (). Messages were short, including only 24 bytes of user data, and sent asynchronously. To find the appropriate endpoint, A/ROSE included a name server that allowed the applications to bind their names to their task IDs, allowing them to move in the system and be found dynamically. The OS also supported a number of routines for finding, starting and stopping tasks on other cards, one of those "cards" being the host computer.

Embedded Linux

:Embedded Linux is the use of a Linux operating system in embedded computer systems such as mobile phones, personal digital assistants, media players, set-top boxes, and other consumer electronics devices, networking equipment, machine control, industrial automation, navigation equipment and medical instruments.

FreeBSD

:-

FreeBSD is a Unix-like free operating system descended from AT&T UNIX via the Berkeley Software Distribution (BSD) branch through the 386BSD and 4.4BSD operating systems. It runs on Intel x86 family (IA-32) IBM PC compatible computers, DEC Alpha, PowerPC, ARM and NEC PC-9801 architectures along with Microsoft's Xbox. Support for other architectures is in varying stages of development. FreeBSD has been characterized as "the unknown giant among free operating systems." It is not a clone of UNIX, but works like UNIX, with UNIX-compliant internals and system APIs. FreeBSD is generally regarded as reliable and robust.

FreeRTOS

:FreeRTOS is a real-time operating system for embedded devices, being ported to several microcontrollers. It is distributed under the GPL with an optional exception. The exception permits users' proprietary code to remain closed source while maintaining the kernel itself as open source, thereby facilitating the use of FreeRTOS in commercial applications. The exception also prevents users from comparing FreeRTOS with other RTOSs, except with permission from the author. FreeRTOS is designed to be small and simple. The kernel itself is comprised of only three or four C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembler functions included where needed (mostly in architecture specific scheduler routines).

Inferno

:Inferno is an operating system for creating and supporting distributed services. Inferno applications are portable across a broad mix of hardware, networks, and environments. It defines a virtual machine that can be implemented on any real machine, E H Ansari

18

provides a type-safe language that is compiled to portable byte code, and, more significantly, it includes a virtual operating system that supplies the same interfaces whether Inferno runs natively on hardware or is hosted as an application on other systems.

LynxOS

:The LynxOS RTOS is a Unix-like real-time operating system from LynuxWorks (formerly "Lynx Real-Time Systems"). Sometimes known as the Lynx Operating System, LynxOS features full POSIX conformance and, more recently, Linux compatibility. LynxOS is mostly used in real-time embedded systems, in applications for avionics, aerospace, the military, industrial process control and telecommunications. LynxOS components are designed for absolute determinism (hard real-time performance), which means that they respond within a known period of time.

MINIX 3

:MINIX 3 is a project to create a small, highly reliable and functional Unix-like operating system. The main goal of the project is for the system to be fault-tolerant by detecting and repairing its own faults on the fly, without user intervention. The main uses of the operating system are envisaged to be embedded systems (such as ADSL routers) as well as the education sector, such as universities or the XO-1 laptop.

.NET Micro Framework

:The .NET Micro Framework is a .NET platform for extremely resource-constrained devices. It includes a small version of the .NET CLR and supports development in C# and debugging (in an emulator or on hardware), both using Microsoft Visual Studio. It also features a subset of the .NET base class libraries (about 70 classes with about 420 methods), a GUI framework loosely based on Windows Presentation Foundation, and additional libraries specific to embedded applications. The .NET Micro Framework aims to make embedded development easier, faster, and less expensive by giving embedded developers access to the modern technologies and tools used by desktop application developers. According to Microsoft, the unique features of the .NET Micro Framework (relative to other .NET platforms) are: A memory footprint of about 300 KB; for comparison, the next smallest .NET implementation, the .NET Compact Framework running on Windows CE, needs about 12 MB Can run directly "on the metal" without an operating system; running on an OS is also possible Supports common embedded peripherals and interconnects, including flash memory, EEPROM, GPIO, I2C, SPI, USB Optimized for energy-efficiency in battery-powered devices Does not require a memory management unit Provides multithreading support even when running on single-threaded operating systems A hardware abstraction layer allows porting to additional architectures A managed device driver model allows drivers for many devices to be written in C# Execution constraints to catch device lockups and crashes Transparent support for storing objects in non-volatile memory E H Ansari

19

Open AT OS

:Open AT OS is an operating system provided by Wavecom together with its CPUs. It basically provides what some other operating systems do, with the particularity to natively provide GSM related functions such as GSM voice calls or data transfer related APIs. On Wavecom CPUs, the Application binary is downloaded beside the GSM function binary and both are executed at the same time on the processor.

QNX

:QNX is a commercial Unix-like real-time operating system, aimed primarily at the embedded systems market. QNX is based on the idea of running most of the OS in the form of a number of small tasks, known as servers. This differs from the more traditional monolithic kernel, in which the operating system is a single very large program composed of a huge number of "parts" with special abilities. In the case of QNX, the use of a microkernel allows users (developers) to turn off any functionality they do not require without having to change the OS itself; instead, those servers are simply not run. :RTLinux (or Real-Time Linux) is an extension of Linux to a real-time operating system. RTLinux supports hard real-time (deterministic) operation through interrupt control between the hardware and the operating system. Interrupts needed for deterministic processing are processed by the real-time core, while other interrupts are forwarded to the non-real time operating system. The operating system (Linux) runs as a low priority thread. First-In-First-Out pipes (FIFOs) or shared memory can be used to share data between the operating system and the real-time core

RTLinux

Windows XP Embedded Windows CE :-

:- Used for Embedded Systems like mobiles, PDAs etc.

Windows CE (also known officially as Windows Embedded Compact post version 6.0) is Microsoft's operating system for minimalistic computers and embedded systems. Windows CE is a distinctly different operating system and kernel, rather than a trimmeddown version of desktop Windows. It is supported on Intel x86 and compatibles, MIPS, ARM, and Hitachi SuperH processors. Windows CE is optimized for devices that have minimal storagea Windows CE kernel may run in under a megabyte of memory. Devices are often configured without disk storage, and may be configured as a closed system that does not allow for end-user extension (for instance, it can be burned into ROM). Windows CE conforms to the definition of a real-time operating system, with deterministic interrupt latency. It supports 256 priority levels and uses priority inheritance for dealing with priority inversion. The fundamental unit of execution is the thread. This helps to simplify the interface and improve execution time

************************* *
E H Ansari

20

TCP/IP and UDP/IP for Embedded Systems

Network Protocols

by Michael Barr

If your embedded system is on a network, the key question is: what subset of TCP/IP will you include in your product? TCP/IP is the name given to a large collection of related networking protocols. It would be unusual in an embedded application to use all of these protocols at once. So the real question is: what subset of TCP/IP will you include in your product, if any? It's now been more than five years since I developed my very first internet appliance. Of course, it wasn't really an appliance in the consumer understanding of that word. But it was the first time that anyone at my company had attempted to use the TCP/IP suite of protocols to connect proprietary equipment. The product in question was a piece of telecommunications equipment designed to connect remote land-based telephone networks via satellite. One or more of these satellite gateways would be attached to each land-based network, thereby allowing telephone calls from one network to the other to be routed through a satellite channel. None of the TCP/IP protocols was required to communicate with the satellite, nor were any of them required to communicate with the land-based telephone network. Therefore, we really could've used just about any protocol we wanted for communication between the internal subsystems of our product. We chose a subset of TCP/IP.

Why TCP/IP?
With literally hundreds of internally and externally developed communications protocols to choose from, we had no compelling reason to choose TCP/IP. This was 1995 after all, and the Internet was just beginning to take hold outside of universities and the Department of Defense; the World Wide Web was still in its infancy; and a war between Ethernet and Token Ring was raging fiercely. If I'd been a stock market investor back then, I probably would've bet all my savings on a networking company called Novell. (Thankfully, I didn't have any money to invest at the time.) What we needed on that project was a way to connect one or more of these satellite gateways to a local PC-based monitoring and control station. (Take a look at Figure 1 to get a feel for the overall context.) Most PCs were not on networks then and Windows 3.1, the dominant PC operating system, had only limited TCP/IP support-in the form of the Winsock add-on. But this was still far better than the PC support for proprietary network protocols. So we decided to use TCP/IP for the communication between the subsystems of our own product (specifically, the satellite gateway and the PC).

E H Ansari

21

Figure 1. Satellite gateways in context The point was not to put our product onto the Internet (with a capital 'I') or even the customer's corporate intranet. In fact, the Ethernet cabling connecting our satellite gateways and PC-based monitoring station was going to be restricted to that purpose. The customer wouldn't necessarily even know what protocols were involved. So it really didn't matter what protocols we chose, so long as they did the job and did it well.

Embedding TCP/IP
Back then, independent embedded TCP/IP stack vendors didn't exist like they do today. We were familiar with a couple of RTOSes that included TCP/IP stacks (yes, VxWorks, LynxOS, and others included TCP/IP that far back), but the RTOS we'd selected did not. Our RTOS was just a small kernel that didn't include any kind of networking support at all. Our options were, therefore, quite limited. We could either port the BSD TCP/IP stack ("free" source code from the University of California at Berkeley that formed the basis of most TCP/IP implementations at the time) or write our own. A preliminary estimate of the work involved in porting BSD revealed that the source code (and resulting executable) was huge and would not be easily reduced to just the subset we needed or ported to our kernel. We really only needed a narrow subset of the full TCP/IP suite, so we decided to develop our own more limited protocol stack from scratch. In fact, what we needed wasn't a TCP/IP stack at all. What we really needed for this particular application was a UDP/IP stack. Figure 2 shows the interrelationships between the member protocols and applications in a typical TCP/IP stack. As you can see from the figure, UDP and TCP are "peer" protocols (ICMP and IGMP are also their peers), in the sense that they are at the same protocol level. The vast majority of application programs and higher-layer protocols depend on either UDP or TCP, but not both.

E H Ansari

22

Figure 2. The interrelationship of the TCP/IP protocols and applications You see, communications between our satellite gateway and PC-based monitoring and control station was pretty simple. The list of communication requirements was limited to the following:

Each satellite gateway needed to be individually addressable by the PC At boot-time, each satellite gateway needed to determine the address of the local PC and receive a set of boot parameters At boot-time, each satellite gateway needed to be able to download new firmware, if any, from the PC and store it into local flash memory

During normal operation, each satellite gateway needed to send its operating statistics and various event reports to the PC

This list of required communications functions maps nicely to UDP/IP, ARP, BOOTP, and TFTP. In other words, all of these demands could be met by a UDP/IP-only protocol stack augmented with ARP support and BOOTP and TFTP application software. So that's what I set out to develop.

Road map
Figure 3 shows the relationship between the various protocols we chose to implement. The "network interface" at the bottom was Ethernet, but it's possible to use SLIP or PPP in its place. TFTP and BOOTP, at the top of the stack, are the application layer programs. Both are client applications that communicate with server counterparts hosted on a remote system.

E H Ansari

23

Figure 3. A smaller UDP/IP-only protocol stack Between the network interface and the client applications are the protocol layers, IP and UDP. UDP is a much simpler protocol to understand and use than its transport layer peer TCP. UDP provides only for the "connectionless" exchange of information between two devices on the network. Since there is no "connection" to track and maintain and there is no guarantee of successful communication, the UDP protocol is stateless. The implementation of the IP protocol layer, on the other hand, can get complicated very quickly. The more features you add the more you need to research and understand the best implementation techniques invented. But it's possible to exclude several IP features found in a general-purpose IP implementation. Even SNMP, a far more complicated client-server application than either BOOTP or TFTP, requires only a UDP/IP stack. Unlike HTTP, it is not built upon the "connection-oriented" communications embodied by TCP. This article began as a column in the April 2000 issue of Embedded Systems Programming. If you wish to cite the article in your own work, you may find the following MLA-style information helpful: Barr, Michael. "TCP/IP or Not TCP/IP?," Embedded Systems Programming, April 2000 , pp. 49-52.
Network System

VD P (Vid eo Det ecti on

E H Ansari

24

Pro ces sor)

VDP (Video Detection Processor)

The VDP-20 is a product for providing higher performance and lower cost than any other systems for vehicle detection. This is an embedded system with a camera interface, a serial port, an Ethernet port, etc. Also, it includes an image detection system realized by software. Consequently, VDP-20 is able not only to analyze video image in real time but also to provide accurate image detection. A detection area of VDP-20 can estimate real distance of road, which provides accurate data information. VDP-20 can detect vehicle velocity, occupancy, vehicle volume, etc in real time at multiple lanes and transfer traffic data to distance areas through a serial or TCP.IP communication. The size of VDP-20 is very small because it is an embedded system with various hardware devices. The image detection algorithm used in VDP-20 can detect vehicles in all weather and lighting conditions

Features => TCP/IP communication thru 10/100 Base-TX with RJ-45 => Software upgrade thru a serial or a TCP/IP communication => Detect up to 8 lanes per slot => Maximum 16 slots => Detection area used in 3D => Software-based vehicle detection => Data compression process for transferring and storing images => Real-time image transfer thru TCP/IP communication Function => Detect vehicle velocity => Analyze traffic volume => Classification of vehicle types => Detect accident occurred => Detect moving direction of vehicle => Analyze condition of road surface Specifications Port per slot One RS-232C port

E H Ansari

25

10/100 Base-TX one port One video input BNC port Power Size Weight Environment System Outline The Video Detector VDP-20 an analyze and process the flow of traffic, occupancy, accident occurred, vehicle velocity and so on. This can be easily maintained and repaired by network managers at remote distance. To install the VDP-20 on the road, a pole must be set up at the side of the road and then the VDP-20 must be attached on the pole. This can be done to accurately detect vehicles at all lanes and process the traffic information.The position and focus of the camera in the VDP-20 must be set to cover all lanes.The detection area and the moving direction of vehicle for all lanes must be set. Also the communication for data transmission process must be set. The VDP-20 can analyze and process detected data in real time, and then transfer the traffic information to the control center through the transmission system OCD
In this paper, we introduce on-chip debug system (OCDS) which supports symbolic debugging at c-level using OCD integrated Debug-logic into target processor. The OCDS consist of SW debugger that supports a functionality of symbolic debugging, OCD (on-chip debugger) serving as a debugger of internal state of target processor, and Interface & Control block interfacing SW debugger and OCD. After OCD block is interfaced with 32 bit RISC processor core and then implemented with FPGA, OCD is connected by Interface & Control block, and SW debugger. The verification of the design is carried out through device recognition, carrying-out instructions of JTAG(joint test action group), reading and writing the internal registers of the processor and memory, and checking the emulation functions such as setting break-points and watch points.

85~132 VAC, 190~265 VAC 220 watts, 50/60 Hz 177mm*448.8mm*311mm(H*W*L) 5kg -40~+75C Humidity: 0%~95%

E H Ansari

26