Professional Documents
Culture Documents
Prepared By :
Mr.P.Karthikeyan,AP/CSE
Mr.B.Thiyagarajan, AP/CSE
Mrs.P.Subha Priya, AP/CSE
Verified by :
Approved by :
UNIT I
EMBEDDED SYSTEMS
2 MARKS
UNIT 1
1. What is an embedded system? [April 2012]
An embedded system employs a combination of hardware & software (a computational
engine) to perform a specific function; is part of a larger system that may not be a computer;
works in a reactive and time-constrained environment.
2. What are the components of the Embedded Systems? [NOV 2011]
An embedded system is basically a computer controlled device designed to perform some
specific tasks. In most cases these tasks revolve around real-time control of machines or
processes. Embedded systems are more cost effective to implement than systems composed of
general purpose computers, such as PCs. The components of ES are,
Memory
System Clock
Peripherals
3. What is the Classification of an embedded system? [April 2013]
The Embedded system is classified into following category
Small Scale Embedded System
Medium Scale Embedded System
Sophisticated Embedded System
4. What is Sophisticated Embedded System?
The sophisticated embedded system has the following features,
Enormous hardware and software Complexity.
This may need scalable processor or configurable processor and programming logic
arrays.
Constrained by the processing speed available in their hardware units.
5. What are the characteristics of an embedded system?
The typical characteristics of the embedded Systems are as follows:
Embedded systems are designed to do some specific task, rather than be a generalpurpose computer for multiple tasks. Some also have real-time performance constraints
that must be met, for reason such as safety and usability; others may have low or no
EMBEDDED SYSTEMS
EMBEDDED SYSTEMS
EMBEDDED SYSTEMS
functional
ALU,
registers,
blocks
timing
control unit.
MICROCONTROLLERS
are It includes functional blocks of
& microprocessors & in addition
has timer, parallel i/o, RAM,
EPROM, and ADC & DAC.
instruction.
digital
computers application
system.
specific
dedicated
systems.
EMBEDDED SYSTEMS
Microprocessor
Microcontroller
Embedded Processor
EMBEDDED SYSTEMS
EMBEDDED SYSTEMS
EMBEDDED SYSTEMS
11 MARKS
System Examples:
1. Watch
It is time display system.
Parts: Hardware, Needles, Battery, Dial, Chassis and Strap.
Rules: (1) All needles move clockwise only
(2) A thin needle rotates every second.
(3) A long needle rotates every minute.
(4) A short needle rotates every hour.
(5) All needles return to the original position after 12 hours.
2. Washing Machine
It is an automatic clothes washing System.
Parts: Status display panel, switches and dials, Motor, Power Supply, Control Unit, Inner water
level sensor and solenoid valve
EMBEDDED SYSTEMS
Embedded Systems:
Definition:
An embedded system is one that has computer hardware with software embedded in it as one of
its important components.
HARDWARE
SOFTWARE
PROGRAM
[Its software embeds in ROM (Read only Memory). It does not need secondary memories as in a
computer]
Computer hardwares that can be used:
A Microprocessor
Embedded system is a
Microcontroller based
Software driven
Reliable
10
EMBEDDED SYSTEMS
In diverse environments
Embedded system is Hardware with Software embedded in it, for a dedicated application.
specific tasks. In most cases these tasks revolve around real-time control of machines or
processes. Embedded systems are more cost effective to implement than systems composed of
general purpose computers, such as PCs.
Processor
The main part of an embedded system is its processor. This can be a generic
microprocessor or a microcontroller. The processor is programmed to perform the
specific tasks for which the embedded system has been designed.
Memory
1.
System Clock
The system clock is a very important part of an embedded system since all processes in
an embedded system run on clock cycles and require precise timing information. This
clock generally consists of an oscillator and some associated circuitry.
11
EMBEDDED SYSTEMS
Peripherals
The peripherals interface an embedded system with other components. The peripheral devices
are provided on the embedded system boards for easy integration. Typical peripherals include
serial port, parallel port, network port, keyboard and mouse ports, memory drive port and
monitor port. Some specialized embedded systems also have other ports such as CAN-bus port.
II.
This may need scalable processor or configurable processor and programming logic
arrays.
III.
purpose computer for multiple tasks. Some also have real-time performance constraints that must
12
EMBEDDED SYSTEMS
be met, for reason such as safety and usability; others may have low or no performance
requirements, allowing the system hardware to be simplified to reduce costs.
2) Embedded systems are not always separate devices. Most often they are physically
built-in to the devices they control.
3) The software written for embedded systems is often called firmware, and is stored in readonly memory or Flash memory chips rather than a disk drive. It often runs with limited computer
hardware resources: small or no keyboard, screen, and little memory.
The die from an Intel 8742, an 8-bit microcontroller that includes a CPU running at 12
MHz, 128 bytes of RAM, 2048 bytes of EPROM, and I/O in the same chip.
13
EMBEDDED SYSTEMS
VARIOUS MICROCONTROLLERS
INTEL
PIC
MOTOROLO
MC 68HC11
14
EMBEDDED SYSTEMS
followed soon after. Affordable 8-bit microprocessors with 16-bit addressing also led to the first
general-purpose microcomputers from the mid-1970s on.
_______
_|
_______
\__/
<--> D0 |_|1
|_
16|_| RAM0 -->
_|
|_
<--> D1 |_|2
_|
|_
<--> D2 |_|3
_|
|_
<--> D3 |_|4
_|
(+5v) Vss |_|5
|_
12|_| Vdd (-10v)
_|
--> CLK1 |_|6
_|
--> CLK2 |_|7
_|
<-- SYNC |_|8
|__________________|
15
EMBEDDED SYSTEMS
|_
11|_| ROM
-->
|_
The first microprocessor in history, Intel 4004 was a 4-bit CPU designed for usage in
calculators, or, as we say now, designed for "embedded applications". Clocked at 740 KHz, the
4004 executed up to 92,000 single word instructions per second, could access 4 KB of program
memory and 640 bytes of RAM. Although the Intel 4004 was perfect fit for calculators and
similar applications it was not very suitable for microcomputer use due to its somewhat limited
architecture. The 4004 lacked interrupt support, had only 3-level deep stack, and used
complicated method of accessing the RAM. Some of these shortcomings were fixed in the 4004
successor - Intel 4040.
Intel C4004
740 KHz
16-pin ceramic DIP
4004 (C4004) processors in white ceramic package were produced until the second half of 1976.
This particular processor is dated 8th week of 1975. Today the C4004 with visible traces (like
the one on the picture) is the most rare and expensive version of Intel 4004.
Intel D4004
740 KHz
16-pin ceramic DIP
4004 microprocessors in plastic and ceramic (not white ceramic) packages were introduced
around 1976. This ceramic 4004 is dated 45th week of 1976.
16
EMBEDDED SYSTEMS
Intel P4004
740 KHz
16-pin plastic DIP
National Semiconductor was the only second source company for the Intel 4004. The naming
convention for the 4004 processors was "INS4004" plus one letter representing package type.
The chip on the picture is mistakenly marked as "1NS4004D".
Embedded microprocessor systems are computer chips that are incorporated into products
such as cars, fridges, traffic lights, industrial equipment, and so on. Embedded microprocessor
systems are used every day by millions of people, but these systems are not seen because, as the
name implies, they are buried inside the product or the equipment. And because they are not
seen, they do not receive as much attention from the media as does the personal computer (PC).
However, the number of embedded microprocessor system computers and their economic
importance is considerable. It was reported that as far back as 1997, around 30 million
17
EMBEDDED SYSTEMS
microprocessor chips were used by PC manufacturers, whilst close to three billion were used in
numerous embedded systems applications.
VARIOUS MICROPROCESSORS
INTEL
Zilog
4004, 4040
8080, 8085
Z8, eZ8
8086, 8088
and others
80186, 80188
80286, 80386
X86-64
Example ARM
18
EMBEDDED SYSTEMS
19
EMBEDDED SYSTEMS
6. Explain The Embedded System Architectures In Detail? [April 2010], [NOV 2012]
states that the system can be in and how it changes between them, with the goal of providing
tightly defined system behavior. This system's strength is its simplicity, and on small pieces of
software the loop is usually so fast that nobody cares that its timing is not predictable. It is
common on small devices with a stand-alone microcontroller dedicated to a simple task.
II.
interrupt to a microprocessor. The interrupt not only can came from the processor, but also from
the external components like the Memory, Graphic controller, A keyboard and can be from other
I/O devices. Events are in asynchronous in nature. But Processors are in synchronous in nature.
When interrupt occurred, the processor finds it as an interrupt and performs the required
20
EMBEDDED SYSTEMS
instructions. This is referred to as an Interrupt service Routine (ISR). Interrupt latency is the time
which the processor requires to perform the instruction by an ISR. This Interrupt latency should
be reduced. For that ultra wideband media access control (UWB MAC) devices are introduced.
These having an interrupt control system detect a set of particular instructions from the processor
core to instruction random access memory (I-RAM). The interrupt control system provides the
core with the computer executable instructions that includes a branch instruction such that the
processor can branch directly to an interrupt service routine (ISR) that provides the computer
instructions for processing the event.
III.
COOPERATIVE MULTITASKING
A type of multitasking in which the process currently controlling the CPU must offer
control to other processes. It is called cooperative because all programs must cooperate for it to
work. If one program does not cooperate, it can hog the CPU. In contrast, preemptive
multitasking forces applications to share the CPU whether they want to or not. Versions 8.0-9.2.2
of Macintosh OS and Windows 3.x operating systems are based on cooperative multitasking,
whereas UNIX, Windows 95, Windows NT, OS/2, and later versions of Mac OS are based on
preemptive multitasking.
A nonpreemptive multitasking system is very similar to the simple control loop scheme,
except that the loop is hidden in an API. The programmer defines a series of tasks, and each task
gets its own environment to run in. When a task is idle, it calls an idle routine, usually called
pause, wait, yield, nop (stands for no operation), etc.
The advantages and disadvantages are very similar to the control loop, except that adding
new software is easier, by simply writing a new task, or adding to the queue-interpreter.
IV.
system, which permits preemption of tasks, from a cooperative multitasking system wherein
processes or tasks must be explicitly programmed to yield when they do not need system
resources.
In this type of system, a low-level piece of code switches between tasks or threads based
on a timer (connected to an interrupt). This is the level at which the system is generally
considered to have an "operating system" kernel. Depending on how much functionality is
21
EMBEDDED SYSTEMS
required, it introduces more or less of the complexities of managing multiple tasks running
conceptually in parallel.
As any code can potentially damage the data of another task (except in larger systems
using an MMU) programs must be carefully designed and tested, and access to shared data must
be controlled by some synchronization strategy, such as message queues, semaphores or a nonblocking synchronization scheme.
Because of these complexities, it is common for organizations to use a real-time
operating system (RTOS), allowing the application programmers to concentrate on device
functionality rather than operating system services, at least for large systems; smaller systems
often cannot afford the overhead associated with a generic real time system, due to limitations
regarding memory size, performance, and/or battery life. The choice that a RTOS is required
brings in its own issues however as the selection must be done prior to starting to the application
development process. This timing forces developers to choose the embedded operating system
for their device based upon current requirements and so restricts future options to a large extent.
The restriction of future options becomes more of an issue as product life decreases. Additionally
the level of complexity is continuously growing as devices are required to manage many
variables such as serial, USB, TCP/IP, Bluetooth, Wireless LAN, trunk radio, multiple channels,
data and voice, enhanced graphics, multiple states, multiple threads, numerous wait states and so
on. These trends are leading to the uptake of embedded middleware in addition to a real time
operating system.
V.
KERNELS
The kernel is a program that constitutes the central core of a computer operating system.
It has complete control over everything that occurs in the system. A kernel can be contrasted
with a shell (such as bash, csh or ksh in Unix-like operating systems), which is the outermost
part of an operating system and a program that interacts with user commands. The kernel itself
does not interact directly with the user, but rather interacts with the shell and other programs as
well as with the hardware devices on the system, including the processor (also called the central
processing unit or CPU), memory and disk drives.
22
EMBEDDED SYSTEMS
They permit re-use of publicly available code for Device Drivers, Web Servers,
Firewalls, and other code.
Development systems can start out with broad feature-sets, and then the distribution can
be configured to exclude unneeded functionality, and save the expense of the memory
that it would consume.
Many engineers believe that running application code in user mode is more reliable,
easier to debug and that therefore the development process is easier and the code more
portable.
Many embedded systems lack the tight real time requirements of a control system.
Although a system such as Embedded Linux may be fast enough in order to respond to
many other applications.
23
EMBEDDED SYSTEMS
Features requiring faster response than can be guaranteed can often be placed in
hardware.
Many RTOS systems have a per-unit cost. When used on a product that is or will become
a commodity, that cost is significant.
VI.
unobtainable with the one of the above architectures. In this case an organization builds a system
to suit. In some cases, the system may be partitioned into a "mechanism controller" using special
techniques, and a "display controller" with a conventional operating system. A communication
system passes data between the two.
mission-critical aerospace and defense systems requiring real-time performance, scalability, and
high-availability facilities consistently turn to the LynxOS RTOS and the LynxOS-178 RTOS
for software certification to DO-178B.
Rich in system resources and networking services, LynxOS provides an off-the-shelf
software platform with hard real-time response backed by powerful distributed computing
(CORBA), high reliability, software certification, and long-term support options.
The LynxOS-178 RTOS for software certification, based on the RTCA DO-178B
standard, assists developers in gaining certification for their mission- and safety-critical systems.
Real-time systems programmers get a boost with LynuxWorks' DO-178B RTOS training
courses.
LynxOS-178 is the first DO-178B and EUROCAE/ED-12B certifiable, POSIXcompatible RTOS solution.
24
EMBEDDED SYSTEMS
II.
III.
Communications applications
"Five-nines" availability, CompactPCI hot swap support, and hard real-time response
LynxOS delivers on these key requirements and more for today's carrier-class systems. Scalable
kernel configurations, distributed computing capabilities, integrated communications stacks, and
fault-management facilities make LynxOS the ideal choice for companies looking for a single
operating system for all embedded telecommunications applicationsfrom complex central
controllers to simple line/trunk cards.
LynuxWorks JumpStart for Communications package enables OEMs to rapidly develop
mission-critical
communications
equipment,
with
pre-integrated,
state-of-the-art,
data
networking and porting software componentsincluding source code for easy customization.
The Lynx Certifiable Stack (LCS) is a secure TCP/IP protocol stack designed especially
for applications where standards certification is required.
IV.
the LynxOS real-time operating system provides a highly reliable option for systems designers.
For makers of low-cost consumer electronic devices who wish to integrate the LynxOS real-time
operating system into their products, we offer special MSRP-based pricing to reduce royalty fees
to a negligible portion of the device's MSRP.
25
EMBEDDED SYSTEMS
V.
LynuxWorks operating systems provide the security and reliability that their industrial
applications require.
From ISO 9001 certification to fault-tolerance, POSIX conformance, secure partitioning
and high availability, we've got it all. Take advantage of our two decades of experience.
8. Discuss the shared data problem and its remedies with example. [April 2010]
Some data is common to different processes ortasks. Examples are as follows:
Time, which is updated continuously by a process, is also used by display process in a system.
Port input data, which is received by one process and further processed and analyzed by
another process.
Memory Buffer data which is inserted by one process and further read (deleted), processed and
analyzed by another.
Assume that at an instant when the value of variable operates and during the operations
on it, only a part of the operation is completed and another part remains incomplete. At that
moment, assume that there is an interrupt.
Assume that there is another function. It also shares the same variable. The value of the
variable may differ from the one expected if the earlier operation had been completed. .
26
EMBEDDED SYSTEMS
Whenever another process sharing the same partly operated data, then shared data problem
arises.
Example:
Consider x, a 128-bit variable, b127.b0.
Assume that the operation OPsl is shift left by 2 bits to multiply it by 4 and find y = 4 x.
Let OPsl be done non-atomically in four sub-operations,
OPAsl, OPBsl, OPCsl and OPDsl
For
b31.b0 , b63.b32 ,
b95.b64 and b127.b96 ,
respectively.
Assuming at an instance OPAsl, OPBsl and OPCsl completed and OPDsl remained
incomplete.
Now interrupt I occurs at that instance.
I calls some function which uses x if x is the global variable.
It modifies x to b127.b0.
On return from interrupt, since OPDsl did not complete, OPDsl operates on
b127.b96 .
Resulting value of x is different due to the problem of incomplete operation before I
occurred.
27
EMBEDDED SYSTEMS
Using VLSI tools, a processor itself can be designed. A system specific processor (ASIP)
is the one that does not use the GPP (standard available CISC or RISC microprocessor or
microcontroller or signal processor). The processor on chip incorporates a section of the CISC or
RISC instruction set.
This specific processor may have especially configurable instruction-set for an
application. An ASIP can also be configurable. Using appropriate tools, an ASIP can be designed
and configured for the instructions needed in the following exemplary functions: DSP functions,
controller signals processing function, adaptive filtering functions and communication protocol
28
EMBEDDED SYSTEMS
implementing functions. On a VLSI chip, an embedded ASIP in a special system can be a unit
within an ASIC or SoC.
On a VLSI chip, there may be high-level components. These are components that possess
gate-level Sophistication in circuits above that of the counter, register, multiplier, floating point
operation unit and ALU. A standard source solution for synthesizing a higher-level component
by configuring FPGA core or a core of VLSI chip may be available as an Intellectual Property,
called (IP). The copyright for the synthesized design of a higher-level component for gate-level
implementation of an IP is held by the designer or designing company.
One has to pay royalty for every chip shipped. An embedded system may incorporate an
IP(s) . An IP may provide hardwired implement-able design of a transform or of an encryption
algorithm or a deciphering algorithm. An IP may provide a design for adaptive filtering of a
signal. An IP may provide full design for implementing Hyper Text Transfer Protocol (HTTP)
or File Transfer Protocol (FTP) to transmit a web page or a file on the Internet. An IP may be
designed for the PCI or USB bus controller.
A General Purpose Processor (GPP) can be embedded on a VSLI chip. Recently,
exemplary GPPs, called ARM 7 and ARM 9, which embed onto a VLSI chip, have been
developed by ARM and their enhancements by Texas Instruments.
An ARM-processor VLSI-architecture is available either as a CPU chip or for integrating
it into VLSI or SoC. ARM provides CISC functionality with RISC architecture at the core. An
application of ARM embed circuit is ICE. ICE is used for debugging an embedded system.
Exemplary ARM 9 applications are setup boxes, cable modems, and wireless devices such as
mobile handsets.
29
EMBEDDED SYSTEMS
30
EMBEDDED SYSTEMS
11. Explain in detail about Monolithic Kernel. [April 2012], [NOV 2012]
In this case, a relatively large kernel with sophisticated capabilities is adapted to suit an
embedded environment. This gives programmers an environment similar to a desktop operating
system like Linux or Microsoft Windows, and is therefore very productive for development; on
the downside, it requires considerably more hardware resources, is often more expensive, and
because of the complexity of these kernels can be less predictable and reliable.
Common examples of embedded monolithic kernels are Embedded Linux and Windows CE.
31
EMBEDDED SYSTEMS
Despite the increased cost in hardware, this type of embedded system is increasing in
popularity, especially on the more powerful embedded devices such as Wireless Routers and
GPS Navigation Systems. Here are some of the reasons:
They permit re-use of publicly available code for Device Drivers, Web Servers,
Firewalls, and other code.
Development systems can start out with broad feature-sets, and then the distribution can
be configured to exclude unneeded functionality, and save the expense of the memory
that it would consume.
Many engineers believe that running application code in user mode is more reliable,
easier to debug and that therefore the development process is easier and the code more
portable.
Many embedded systems lack the tight real time requirements of a control system.
Although a system such as Embedded Linux may be fast enough in order to respond to
many other applications.
Features requiring faster response than can be guaranteed can often be placed in
hardware.
Many RTOS systems have a per-unit cost. When used on a product that is or will become
a commodity, that cost is significant.
32
EMBEDDED SYSTEMS
12. Explain the skill required for embedded system designer. [April 2012]
An embedded system designer has to develop a product using the available tools within the given
specifications, cost and time frame. [Chapters 7 and 12 will cover the design aspects of
embedded systems.
Skills for Small Scale Embedded System Designer: Author Tim Wilmshurst in the book referred
above, has said that the following skills are needed in the individual or team that is developing a
small-scale system: Full understanding of microcontrollers with a basic knowledge of computer
architecture, digital electronic design, software engineering, data communication, control
engineering, motors and actuators, sensors and measurements, analog electronic design and IC
design and manufacture. Specific skills will be needed in specific situations. For example,
control engineering knowledge will be needed for design of control systems and analog
electronic design knowledge will be needed when designing the system interfaces. Basic aspects
of the following topics will be described in this book to prepare the designer who already has a
good knowledge of the microprocessor or microcontroller to be used. (i) Computer architecture
and organization. (ii) Memories. (iii) Memory allocation. (iv) Interfacing the memories. (v)
33
EMBEDDED SYSTEMS
Burning (a term used for porting) the executable machine codes in PROM or ROM (Section
2.3.1). (vi) Use of decoders and demultiplexers. (vii) Direct memory accesses. (viii) Ports. (ix)
Device drivers in assembly. (x) Simple and sophisticated buses. (xi) Timers. (xii) Interrupt
servicing mechanism. (xiii) C programming elements. (xiv) Memory optimization. (xv) Selection
of hardware and microcontroller. (xvi) Use of ICE (In-Circuit-Emulators), cross-assemblers and
testing equipment. (xvii) Debugging the software and hardware bugs by using test vectors. Basic
knowledge in the other areasdata communication, control engineering, motors and actuators,
sensors and measurements, analog electronic design and IC design and manufacturecan be
obtained from the standard textbooks available.
Skills for Medium Scale Embedded System Designer: C programming and RTOS
programming and program modeling skills are a must to design a medium-scale embedded
system. Knowledge of the following becomes critical.
(i) Tasks and their scheduling by RTOS.
(ii) Cooperative and preemptive scheduling.
(iii) Inter processor communication functions.
(iv) Use of shared data, and programming the critical sections and re-entrant functions. (v) Use
of semaphores, mailboxes, queues, sockets and pipes.
(vi) Handling of interrupt-latencies and meeting task deadlines.
(vii) Use of various RTOS functions.
(viii) Use of physical and virtual device drivers. A designer must have access to an RTOS
programming tool with Application Programming Interfaces (APIs) for the specific
microcontroller to be used. Solutions to various functions like memory allocation, timers, device
drivers and interrupt handing mechanism are readily available as the
APIs of the RTOS. The designer needs to know only the hardware organization and use of these
APIs. The microcontroller or processor then represents a small system element for the designer
and a little knowledge may suffice.
Skills for Sophisticated Embedded System Designer: A team is needed to co-design and solve
the high level complexities of the hardware and software design. An embedded system hardware
engineer should have full skills in hardware units and basic knowledge of C, RTOS and other
programming tools. Software engineer should have basic knowledge in hardware and a thorough
34
EMBEDDED SYSTEMS
knowledge of C, RTOS and other programming tools. A final optimum design solution is then
obtained by system integration.
QUESTION BANK
TWO MARKS
1. What is an embedded system? [April 2012]
2. What are the components of the Embedded Systems? [NOV 2011]
3. What is the Classification of an embedded system? [April 2013]
4. What is Sophisticated Embedded System?
5. What are the characteristics of an embedded system?
6. What are the advantages of embedded system?
7. What are the disadvantages of embedded system?
8. What are the various embedded system requirements?
9. What are the functional requirements of embedded system?
10. What are the temporal requirements of the embedded systems?
11. What are dependability requirements of an embedded system?
12. What is a Microprocessor?
13. What is a Microcontroller? [NOV 2012]
14. What are differences between Microprocessor and Microcontroller?
15. What are the various embedded system designs?
16. What are the complicating factors in embedded design?
17. What are the real time requirements of an embedded system?
18. Explain digital signal processing in embedded system?
19. List the various processors that are present?
20. What is the Embedded Processor? [April 2013]
21. Give the reactivitys in embedded system?
22. What are embedded cores?
23. What are hybrid chips?
24. Give the diversity of embedded computing?
25. What is a kernel? [April 2012]
26. What are the types of Kernel?
35
EMBEDDED SYSTEMS
ELEVEN MARKS
1. Describe Embedded System In Detail? [Page: 9]
2. Explain The Components, Classification And Characteristics Of Embedded System Briefly?
[NOV 2011], [April 2012], [April 2013] [Page: 11]
3. What Is A Microcontroller Explain With An Example? [NOV 2011] [Page: 13]
4. What Is A Microprocessor Explain With An Example? [NOV 2012] [Page: 14]
5. What Is An Embedded Processor? [Page: 18]
6. Explain The Embedded System Architectures In Detail? [April 2010], [NOV 2012] [Page:
21]
7. Explain Any One Of The Applications Of The Embedded Systems In Detail [Page: 25]
8. Discuss the shared data problem and its remedies with example. [April 2010]
[Page: 29]
9. Explain the Bus structure of an embedded system. [April 2010] [Page: 31]
10. Explain briefly about Interrupt [April 2010] [Page: 33]
11. Explain in detail about Monolithic Kernel. [April 2012], [NOV 2012] [Page: 35]
12. Explain the skill required for embedded system designer. [April 2012] [Page: 36]
36
EMBEDDED SYSTEMS
4. Discuss the shared data problem and its remedies with example. [April 2010]
[Ref. Page No.: 29]
5. Explain the Bus structure of an embedded system. [April 2010] [Ref. Page No.: 31]
6. Explain briefly about Interrupt [April 2010] [Ref. Page No.: 33]
7. Explain in detail about Monolithic Kernel. [April 2012], [NOV 2012] [Ref. Page No.: 35]
8. Explain the skill required for embedded system designer.[April 2012][Ref. Page No.: 36]
37
EMBEDDED SYSTEMS
Prepared By :
Mr.P.Karthikeyan,AP/CSE
Mr.B.Thiyagarajan, AP/CSE
Mrs.P.Subha Priya, AP/CSE
Verified by :
Approved by :
UNIT II
Embedded Hardware Architecture :32 Bit Microcontrollers:
ARM 2 TDMI core based 32 Bit microcontrollers and family of processors:
Register, Memory and Data transfer, Arithmetic and Logic instructions, Assembly
Language, I/O operations interrupt structure, ARM cache. ARM Bus, Embedded
systems with ARM.
Networks for Embedded systems:
Serial bus protocols: The CAN bus, and the USB bus, Parallel bus protocols: The
PCI Bus and GPIB bus,
38
EMBEDDED SYSTEMS
39
EMBEDDED SYSTEMS
Interrupt controlled
Direct memory access (DMA)
6. Give the limitations of polling technique.
The polling technique, however, has limitations.
It is wasteful of the processors time, as it needlessly checks the status of all devices all
the time.
It is inherently slow, as it checks the status of all I/O devices before it comes back to
check any given one again.
When fast devices are connected to a system, polling may simply not be fast enough to
satisfy the minimum service requirements. Priority of the device is determined
7. What do you meant by bus arbitration?
Bus Arbitration
Most processors use special control lines for bus arbitration, ie, controlling the use of the address
and data bus,
An input which the DMAC uses to request the bus
An output(s) indicating the bus status
An output indicating acceptance of the DMAC\'s bus request
8. What are the two characteristics of synchronous communication?
Bytes/frames maintain constant phase difference and should not be sent at random time
intervals. No handshaking signals are provided during the communication.
Clock pulse is required to transmit a byte or frame serially. Clock rate information is
transmitted by the transmitter.
9. What do you mean by asynchronous communication?
The most basic way of sharing data is by copying the data in question to each server. This
will only work if the data is changed infrequently and always by someone with administrative
access to all the servers in the cluster.
10. What are the characteristics of asynchronous communication?
Variable bit rate need not maintain constant phase difference
Handshaking method is used
Transmitter need not transmit clock information along with data bit stream
40
EMBEDDED SYSTEMS
41
EMBEDDED SYSTEMS
42
EMBEDDED SYSTEMS
devices were simply living on the local network. Two common solutions to this problem are
double-ended SCSI and fiber-channel.
26. Mention some I/O standard interfaces.
HSTL High Speed Transceiver Logic (Used in high speed operations)
SSTL Stub Series Terminated Logic (Used when the buses are needed to isolate from the
large no. of stubs)
43
EMBEDDED SYSTEMS
The second operand can be shifted or rotated before being used in the operation
For example, ADD R0, R1, R5, LSL #4 operates as follows: the second operand
stored in R5 is shifted left 4-bit positions (equivalent to [R5]x16), and its is then added to
the contents of R1; the sum is placed in R0
The logic operations AND, OR, XOR, and Bit-Clear are implemented by instructions
with the OP codes AND, ORR, EOR, and BIC.
For example
AND R0, R0, R1: performs R0[R0]+[R1]
The Move Negative instruction complements the bits of the source operand and places
the result in Rd.
For example, MVN R0, R3
44
EMBEDDED SYSTEMS
High code density is another major requirement since embedded systems have limited
memory due to cost and/or physical size restrictions. High code density is useful for applications
that have limited on-board memory, such as mobile phones and mass storage devices.
In addition, embedded systems are price sensitive and use slow and low-cost memory
devices. For high-volume applications like digital cameras, every cent has to be accounted for in
the design. The ability to use low-cost memory devices produces substantial savings.
Another important requirement is to reduce the area of the die taken up by the embedded
processor. For a single-chip solution, the smaller the area used by the embedded processor, the
more available space for specialized peripherals. This in turn reduces the cost of the design and
manufacturing since fewer discrete chips are required for the end product.
ARM has incorporated hardware debug technology within the processor so that software
engineers can view what is happening while the processor is executing code. With greater
visibility, software engineers can resolve issues faster, which has a direct effect on the time
to market and reduces overall development costs.
The ARM core is not a pure RISC architecture because of the constraints of its primary
applicationthe embedded system. In some sense, the strength of the ARM core is that it does
not take the RISC concept too far. In todays systems the key is not raw processor speed but total
effective system performance and power consumption.
UNIT 2
11 MARKS
1. DISCUSS THE ARM architecture in Detail ( APRIL 2013)
The ARM processor core is a key component of many successful 32-bit embedded systems.
You probably own one yourself and may not even realize it! ARM cores are widely used in
mobile phones, handheld organizers, and a multitude of other everyday portable consumer
devices. ARMs designers have come a long way from the first ARM1 prototype in 1985. Over
one billion ARM processors had been shipped worldwide by the end of 2001. The ARM
45
EMBEDDED SYSTEMS
Company bases their success on a simple and powerful original design, which continues to
improve today through constant technical innovation. In fact, the ARM core is not a single core,
but a whole family of designs sharing similar design principles and a common instruction set.
For example, one of ARMs most successful cores is the ARM7TDMI. It provides up to
120 Dhrystone MIPS1 and is known for its high code density and low power
consumption,making it ideal for mobile embedded devices. In this first chapter we discuss how
the RISC (reduced instruction set computer) design philosophy was adapted by ARM to create a
flexible embedded processor. We then introduce an example embedded device and discuss the
typical hardware and software technologies that surround an ARM processor.
46
EMBEDDED SYSTEMS
maximum throughput. Instructions can be decoded in one pipeline stage. There is no need for an
instruction to be executed by a miniprogram called microcode as on CISC processors.
3.RegistersRISC machines have a large general-purpose register set. Any register can contain
either data or an address. Registers act as the fast local memory store for all data
processing operations. In contrast, CISC processors have dedicated registers for specific
purposes.
4. Load-store architecture The processor operates on data held in registers. Separate load and
store instructions transfer data between the register bank and external memory. Memory accesses
are costly, so separating memory accesses from data processing provides an advantage because
you can use data items held in the register bank multiple times without needing multiple memory
accesses. In contrast, with a CISC design the data processing operations can act on memory
directly. These design rules allow a RISC processor to be simpler, and thus the core can operate
at higher clock frequencies. In contrast, traditional CISC processors are more complex and
operate at lower clock frequencies. Over the course of two decades, however, the distinction
between RISC and CISC has blurred as CISC processors have implemented more RISC
concepts.
47
EMBEDDED SYSTEMS
The ARM processor controls the embedded device. Different versions of the ARM
processor are available to suit the desired operating characteristics. An ARM processor
comprises a core (the execution engine that processes instructions and manipulates data)
plus the surrounding components that interface it with a bus. These components can
include memory management and caches.
Controllers coordinate important functional blocks of the system. Two commonly found
controllers are interrupt and memory controllers.
The peripherals provide all the input-output capability external to the chip and are
responsible for the uniqueness of the embedded device.
A bus is used to communicate between different parts of the device
Applications
The operating system schedules applicationscode dedicated to handling a particular
task. An application implements a processing task; the operating system controls the
environment. An embedded system can have one active application or several applications
running simultaneously.
ARM processors are found in numerous market segments, including networking,
automotive, mobile and consumer devices, mass storage, and imaging. Within each segment
48
EMBEDDED SYSTEMS
ARM processors can be found in multiple applications. For example, the ARM processor is
found in networking applications like home gateways, DSL modems for high-speed Internet
communication, and 802.11 wireless communication. The mobile device segment is the largest
application area for ARM processors because of mobile phones. ARM processors are also found
in mass storage devices such as hard drives and imaging products such as inkjet printers
applications that are cost sensitive and high volume. In contrast, ARM processors are not found
in applications that require leading-edge high performance. Because these applications tend to be
low volume and high cost, ARM has decided not to focus designs on these types of applications.
2. WHAT IS THE ARM FAMILY OF PROCESSOR?
There are currently eight product families which make up the ARM processor range:
ARM Processor Instruction Set Architecture
49
EMBEDDED SYSTEMS
The ARM Cortex-A Series is a family of applications processors for complex OS and
user applications.The Cortex-A8 and Cortex-A9 processors support the ARM, Thumb and
Thumb-2 instruction sets.
The ARM Cortex-R Series is a family of embedded processors for real-time
systems.These processors support the ARM, Thumb, and Thumb-2 instruction sets. Currently
this family comprises the Cortex-R4 and the Cortex-R4F processors
The ARM Cortex-M Series is a family of deeply embedded processors optimized for cost
sensitive applications. These processors support the Thumb-2 instruction set only. This family
comprises the Cortex-M3 , the Cortex-M1 and the Cortex-M0 processors
The ARM Cortex-M0 processor is the smallest, lowest power and most
energy-efficient ARM processor available. The exceptionally small silicon area,
low power and minimal code footprint of the processor enables developers to
achieve 32-bit performance at an 8-bit price point, bypassing the step to 16-bit
devices.
50
EMBEDDED SYSTEMS
The ARM7 family offers up to 130MIPs (Dhrystone2.1) and incorporates the Thumb 16bit instruction set. The family consists of the ARM7TDMI, ARM7TDMI-S and ARM7EJ-S
processors, each of which was developed to address different market requirements:
Integer processor
acceleration
Cached core with Memory Management Unit (MMU) supporting operating systems
including Windows CE, Palm OS, Symbian OS and Linux
Applications
Two-way pagers
ARM7 family
Wide operating system and RTOS support - including Windows CE, Palm OS, Symbian
OS, Linux and market-leading RTOS
51
EMBEDDED SYSTEMS
Digital consumer products Set-top boxes, home gateways, games consoles, MP3 audio,
MPEG4 video
ARM922 Features
8-entry write buffer avoids stalling the processor when writes to external memory are
performed
52
EMBEDDED SYSTEMS
suited for applications requiring a mix of DSP and microcontroller performance. The family
includes the ARM926EJ-S, ARM946E-S and ARM968E-S processor macrocells, each of which
has been developed to address different application requirements. They include signal processing
extensions to enhance 16-bit fixed point performance using a single-cycle 32 x 16 multiplyaccumulate (MAC) unit, and implement the 16-bit Thumb instruction set giving excellent code
density, maximising savings on system cost. The ARM926EJ-S processor also includes ARM
Jazelle technology which enables the direct execution of Java bytecodes in hardware.
Jazelle technology, memory management unit (MMU), variable size instruction and data
caches (4K - 128K), instruction and data tightly coupled memory (TCM) interfaces
Variable size instruction and data cache (0K- 1M), instruction and data TCM(0 - 1M),
and memory protection unit for embedded applications.
Applications
Imaging
Desktop printers, still picture cameras, digital video cameras
Storage
HDD and DVD drives
Automotive
Power train, infotainment, ABS, body control systems
Networking
VoIP, Wireless LAN, xDSL
ARM9E Family
32-bit RISC processor with ARM, Thumb and DSP instruction sets
53
EMBEDDED SYSTEMS
16-entry write buffer avoids stalling the processor when writes to external memory are
performed
Flexible soft IP delivery, synthesizable to the latest 0.18m, 0.15m, 0.13m silicon
processes.
Hand-held products
54
EMBEDDED SYSTEMS
Features:
32-bit performance-optimized processor core implementing the ARM, Thumb, DSP, and
Java ISAs (v5TEJ)
-
Full MMU support for Windows CE, Linux, Palm OS, Symbian OS, and Java OS
Full MPU support for a broad range of real time operating systems
Support for optional vector floating point and embedded trace coprocessors
Benefits:
55
EMBEDDED SYSTEMS
Single development toolkit for reduced development costs and shorter development cycle
time
Excellent real-time debug support for SoC designers via optional ETM10RV macrocell
56
EMBEDDED SYSTEMS
suitable for embedded 3D-graphics applications. These processors feature AXI interfaces
compatible with the latest AMBATM 3 AXITM specification, and offering higher system bus
bandwidth with fewer bus layers and rapid timing closure.
High Performance Processors for Automotive, Data Storage, Imaging and Embedded
Control
The ARM1156T2-S and ARM1156T2F-S processors incorporate the latest ARM Thumb2 technology for even higher code density and instruction set efficiency. Thumb-2 technology
uses 31 percent less memory than pure 32-bit code to reduce system cost, while at the same time
delivering up to 38 percent better performance than existing Thumb technology-based solutions.
These processors also feature optional parity protection for caches and Tightly Coupled
Memories (TCM), and non- maskable interrupts, making them ideal for embedded control
applications where high reliability or high availability are paramount.
The ARM1156T2F-S processor includes an integrated floating point coprocessor - ideal
for embedded control applications developed from mathematical models. Both processors feature
an enhanced Memory Protection Unit (MPU) and offer an ideal upgrade path for embedded
control applications currently using ARM946E-S, ARM966E-S or older 16-bit processors.
These processors feature AMBA 3 AXI specification interfaces, offering higher system
bus bandwidth with fewer bus layers and rapid timing closure.
Processors for Network Infrastructure, Consumer, and Automotive Infotainment
The award-winning ARM1136J-S and ARM1136JF-S processors, feature the ARMv6
instruction set with media extensions, ARM Jazelle technology, ARM Thumb code compression,
and optional floating point coprocessor. As with all ARM11 family processors, media processing
extensions offer up to 1.9x acceleration of media-processing tasks such as MPEG4 encode,
instruction and data cache sizes are configurable, and optional Tightly Coupled Memories can be
added to accelerate interrupt handling and data-processing. These processors feature AMBA 2
AHB interfaces compatible with a wide range of system IP and peripherals.
57
EMBEDDED SYSTEMS
ARM Thumb instruction set reduces memory bandwidth and size requirements by up to
35%
Thumb-2 core technology for enhanced performance, energy efficiency and code density
(ARM1156T2-S and ARM1156T2F-S cores)
58
EMBEDDED SYSTEMS
All ARM11 cores are delivered as ARM- Synopsys Reference Methodology compliant
deliverables which significantly reduce the time to generate a specific technology
implementation of the core and to generate a complete set of industry standard views and
models
59
EMBEDDED SYSTEMS
Two operand lengths are used in moving data between the memory and the processor
registers
Bytes (8 bits) and words (32 bits)
When a byte is loaded from memory into a processor register or stored from a register
into the memory
It always located in the low-order byte position of the register
Register Structure
Saved copies of the Status register are also available in the Supervisor and Interrupt
modes
60
EMBEDDED SYSTEMS
An instruction specifies a conditional execution code (Condition), the OP code, two or three
registers (Rn, Rd, and Rm), and some other information
A distinctive and somewhat unusual feature of ARM processors is that all instructions are
conditionally executed
Depending on a condition specified in the instruction
The instruction is executed only if the current state of the processor condition code flag
satisfies the condition specified in bits b31-b28 of the instruction
Thus the instructions whose condition is not meet the processor condition code
flag are not executed
One of the conditions is used to indicate that the instruction is always executed
Pre-indexed mode
The effective address of the operand is the sum of the contents of the base register Rn
indexed mode, and then the effective address is written back into Rn
Post-indexed mode
61
EMBEDDED SYSTEMS
The effective address of the operand is the contents of Rn. The offset is then added to
this address and the result is written back into Rn
The operand must be within the range of 4095 bytes forward or backward from the
updated PC.
62
EMBEDDED SYSTEMS
63
EMBEDDED SYSTEMS
64
EMBEDDED SYSTEMS
mem32 [r1]:= r0
Other forms of addressing all build on this form, adding immediate or register off-sets to
the base address. In all cases it is necessary to have an ARM register loaded with an address
which is near to the desired transfer address, so we will begin by looking at ways of getting
memory addresses into a register.
Initializing an address pointer
To load or store from or to a particular memory location, an ARM register must be
initialized to contain the address of that location, or, in the case of single register transfer
instructions, an address within 4 Kbytes of that location.
If the location is close to the code being executed it is often possible to exploit the fact
that the program counter, r15, is close to the desired address. A data processing instruction can
be employed to add a small offset to r15, but calculating the appropriate offset may not be that
straightforward. However, this is the sort of tricky calculation that assemblers are good at, and
instruction in the assembly source code but does not correspond directly to a particular ARM
instruction. Instead, the assembler has a set of rules which enable it to select the most appropriate
ARM instruction or short instruction sequence for the situation in which the pseudo instruction is
used. (In fact, ADR is always assembled into a single ADD or SUB instruction.)As an example,
consider a program which must copy data from TABLE 1 toTABLE2, both of which are near to
the code: ARM assemblers have an inbuilt 'pseudo instruction', ADR which makes this easy. A
pseudo instruction looks like a normal
65
EMBEDDED SYSTEMS
Here we have introduced labels (COPY, TABLE 1 and TABLE2) which are simply
names given to particular points in the assembly code. The first ADR pseudo instruction causes
r1 to contain the address of the data that follows TABLE1; the second ADR likewise causes r2
to hold the address of the memory starting at TABLE2.Of course any ARM instruction can be
used to compute the address of a data item in memory, but for the purposes of small programs
the ADR pseudo instruction will do what we require.
Single register load and store instructions
These instructions compute an address for the transfer using a base register, which should
contain an address near to the target address, and an offset which may bean other register or an
immediate value. We have just seen the simplest form of these instructions, which does not use
an offset
LDR
r0
[r1]
STR
r0
[r1]
The notation used here indicates that the data quantity is the 32-bit memory word
addressed by r1. The word address in r1 should be aligned on a 4-byte boundary, so the two least
significant bits of r1 should be zero. We can now copy the first word from one table to the other.
We could now use data processing instructions to modify both base registers ready for the
next transfer:
66
EMBEDDED SYSTEMS
Note that the base registers are incremented by 4 (bytes), since this is the size of a word.
If the base register was word-aligned before the increment, it will be word-aligned afterwards
too.
All load and store instructions could use just this simple form of register-indirect
addressing. However, the ARM instruction set includes more addressing modes that can make
the code more efficient.
Base plus offset addressing
If the base register does not contain exactly the right address, an offset of up to4 Kbytes
may be added (or subtracted) to the base to compute the transfer address:
LDR
r0,
[r1, #4]
+ 4]
This is a pre-indexed addressing mode. It allows one base register to be used to access a
number of memory locations which are in the same area of memory.
Sometimes it is useful to modify the base register to point to the transfer address. This
can be achieved by using pre-indexed addressing with auto-indexing, and allows the program to
walk through a table of values:
LDR
r0,
r0:= mem32[r]
[r1, #4]!
+ 4]; r1:= r1
+4
The exclamation mark indicates that the instruction should update the base register after
initiating the data transfer. On the ARM this auto-indexing costs no extra time since it is
67
EMBEDDED SYSTEMS
performed on the processor's data path while the data is being fetched from memory. It is exactly
equivalent to preceding a simple register-indirect load with a data processing instruction that
adds the offset (4bytes in this example) to the base register, but the time and code space cost of
the extra instruction are avoided.
Another useful form of the instruction, called post-indexed addressing, allows the base to
be used without an offset as the transfer address, after which it is auto-indexed:
LDR
r0, [r1], #4
Here the exclamation mark is not needed, since the only use of the immediate offset is as
a base register modifier. Again, this form of the instruction is exactly equivalent to a simple
register-indirect load followed by a data processing instruction, but it is faster and occupies less
code space.
Using the last of these forms we can now improve on the table copying program example
introduced earlier:
The load and store instructions are repeated until the required number of values has been
copied into TABLE2, and then the loop is exited. Control flow instructions are required to
determine the loop exit; they will be introduced shortly.
In the above examples the address offset from the base register was always an immediate
value. It can equally be another register, optionally subject to a shift operation before being
68
EMBEDDED SYSTEMS
added to the base, but such forms of the instruction are less useful than the immediate offset
form.
As a final variation, the size of the data item which is transferred may be a single
unsigned 8-bit byte instead of a 32-bit word. This option is selected by adding a letter B onto the
opcode:
LDBR
r0, [r1]
; r0:=mem8 [r1]
In this case the transfer address can have any alignment and is not restricted to a4-byte
boundary, since bytes may be stored at any byte address. The loaded byte is placed in the bottom
byte of r0 and the remaining bytes in r0 are filled with zeros. All but the oldest ARM processors
also support signed bytes, where the top bit of the byte indicates whether the value should be
treated as positive or negative, and signed and unsigned 16-bit half-words;
Multiple register data transfers
Where considerable quantities of data are to be transferred, it is preferable to move
several registers at a time. These instructions allow any subset (or all) of the 16 registers to be
transferred with a single instruction. The trade-off is that the available addressing modes are
more restricted than with a single register transfer instruction. A simple example of this
instruction class is:
Since the transferred data items are always 32-bit words, the base address (r1)should be
word-aligned.
The transfer list, within the curly brackets, may contain any or all of r0 to r15. The order
of the registers within the list is insignificant and does not affect the order of transfer or the
values in the registers after the instruction has executed. It is normal practice, however, to
specify the registers in increasing order within the list.
Note that including r15 in the list will cause a change in the control flow, sincer15 is the
PC. We will return to this case when we discuss control flow instructions and will not consider it
further until then.
69
EMBEDDED SYSTEMS
The above example illustrates a common feature of all forms of these instructions: the
lowest register is transferred to or from the lowest address, and then the other registers
are transferred in order of register number to or from consecutive word addresses above
the first. However there are several variations on how the first address is formed, and
auto-indexing is also available (again by adding a '!'After the base register).
Stack addressing
The addressing variations stem from the fact that one use of these instructions is to
implement stacks within memory. A stack is a form of last-in-first-out store which supports
simple dynamic memory allocation, that is, memory allocation where the address to be used to
store a data value is not known at the time the program is compiled or assembled. An example
would be a recursive function, where the depth of recursion depends on the value of the
argument. A stack is usually implemented as a linear data structure which grows up (an
Ascending stack) or down (a descending stack) memory as data is added to it and shrinks back as
data is removed. A stack pointer holds the address of the current top of the stack, either by
pointing to the last valid data item pushed onto the stack (a full stack), or by pointing to the
vacant slot where the next data item will be placed (an empty stack).
The above description suggests that there are four variations on a stack, representing all
the combinations of ascending and descending full and empty stacks. The ARM multiple register
transfer instructions support all four forms of stack:
Full ascending: the stack grows up through increasing memory addresses and the base
register points to the highest address containing a valid item.
Empty ascending: the stack grows up through increasing memory addresses and the base
register points to the first empty location above the stack.
Full descending: the stack grows down through decreasing memory addresses and the
base register points to the lowest address containing a valid item.
Empty descending: the stack grows down through decreasing memory addresses and the
base register points to the first empty location below the stack.
Block copy addressing
Although the stack view of multiple register transfer instructions is useful, there are
occasions when a different view is easier to understand. For example, when these instructions are
used to copy a block of data from one place in memory to another amechanistic view of the
70
EMBEDDED SYSTEMS
addressing process is more useful. Therefore the ARM assembler supports two different views of
the addressing mechanism, both of which map onto the same basic instructions, and which can
be used interchangeably. The block copy view is based on whether the data is to be stored above
or below the address held in the base register and whether the address incrementing or
decrementing begins before or after storing the first value. The block copy views shows how
each variant stores three registers into memory and how the base register is modified if autoindexing is enabled. The base register value before the instruction is r9, and after the autoindexing it is r9'.
To illustrate the use of these instructions, here are two instructions which copy eight
words from the location r0 points to the location r1 points to:
LDMIA r0! {R2-R9}
STMIA r1, {r2-r9}
After executing these instructions r0 has increased by 32 since the '!' causes it to autoindex across eight words, whereas r1 is unchanged. If r2 to r9 contained useful values, we could
preserve them across this operation by pushing them onto a stack:
STMFD r13!
{R2-R9}
LDMIA r0!
{R2-R9}
STMIA r1,
{R2Rr9}
LDMFD r13!
{R2-R9}
Here the 'FD 'postfix on the first and last instructions signifies the full descending stack
address mode as described earlier. Note that auto-indexing is almost always specified for stack
operations in order to ensure that the stack pointer has a consistent behavior.
The load and store multiple register instructions are an efficient way to save and restore
processor state and to move blocks of data around in memory. They save code space and operate
up to four times faster than the equivalent sequence of single Register.
71
EMBEDDED SYSTEMS
Register load or store instructions (a factor of two due to improved sequential behavior and
another factor of nearly two due to the reduced instruction count). This significant advantage
suggests that it is worth thinking carefully about how data is organized in memory in order to
maximize the potential for using multiple register data transfer instructions to access it.
These instructions are, perhaps, not pure 'RISC' since they cannot be executed in a single
clock cycle even with separate instruction and data caches, but other RISC architectures are
beginning to adopt multiple register transfer instructions in order to increase the data bandwidth
between the processor's registers and the memory.
72
EMBEDDED SYSTEMS
The ARM multiple register transfer instructions are uniquely flexible in being able to
transfer any subset of the 16 currently visible registers.
In ARM processors, there are two instructions for loading and storing multiple operands
They are called Block transfer instructions
All of the forms of pre- and post-indexing with and without writeback are available
They operate on a Base register Rn specified in the instruction and offset is always 4
LDMIA R10!, {R0,R1,R6,R7}
IA: Increment After corresponding to post-indexing
The second operand can be shifted or rotated before being used in the operation
For example, ADD R0, R1, R5, LSL #4 operates as follows: the second operand
stored in R5 is shifted left 4-bit positions (equivalent to [R5]x16), and its is then added to
the contents of R1; the sum is placed in R0
73
EMBEDDED SYSTEMS
For example
AND R0, R0, R1: performs R0[R0]+[R1]
The Move Negative instruction complements the bits of the source operand and places
the result in Rd.
For example, MVN R0, R3
Conditional branch instructions contain a signed 24-bit offset that is added to the updated
contents of the Program Counter to generate the branch target address
Offset is a signed 24-bit number. It is shifted left two-bit positions (all branch
targets are aligned word addresses), signed extended to 32 bits, and added to the updated
PC to generate the branch target address
The updated points to the instruction that is two words (8 bytes) forward from the
branch instruction
The BEQ instruction (Branch if Equal to 0) causes a branch if the Z flag is set to 1
74
EMBEDDED SYSTEMS
The arithmetic and logic instructions affect the condition code flags only if explicitly
specified to do so by a bit in the OP-code field. This is indicated by appending the suffix
S to the OP-code
For example, the instruction ADDS R0, R1, R2 set the condition code flags
But ADD R0, R1, R2 does not
75
EMBEDDED SYSTEMS
The ARM assembly language has assembler directives to reserve storage space, assign
numerical values to address labels and constant symbols, define where program and data
blocks are to be placed in memory, and specify the end of the source program text
The AREA directive, which uses the argument CODE or DATA, indicates the beginning
of a block of memory that contains either program instructions or data
The ENTRY directive specifies that program execution is to begin at the following LDR
instruction
In the data area, which follows the code area, the DCD directives are used to label and
initialize the data operands
When a number of registers are used in a program, it is convenient to use symbolic names
for them that relate to their usage
The RN directive is used for this purpose
For example, COUNTER RN 3 establishes the name COUNTER for register R3
76
EMBEDDED SYSTEMS
The register names R0 to R15, PC (for R15), and LR( for R14) are predefined by the
assembler
R14 is used for a link register (LR)
An alternative way of loading the address into register R2 is also provided in the
assembly language
The pseudo-instruction ADR Rd, ADDRESS holds the 32- bit value ADDRESS into Rd
This instruction is not an actual machine instruction
The assembler chooses appropriate real machine instructions to implement
pseudo-instructions
For example,
The combination of the machine instruction LDR R2, POINTER and the data
declaration directive POINTER DCD NUM1 is one way to implement the pseudoinstruction ADR R2, NUM1
Subroutines
The return address is loaded into register R14, which acts as a link register
When subroutines are nested, the contents of the link register must be saved on a stack by
the subroutine.
Register R13 is normally used as the pointer for this stack
Example
Byte-Sorting Program
77
EMBEDDED SYSTEMS
Byte-Sorting Program
78
EMBEDDED SYSTEMS
It is up to the system designer who can decide which hardware peripheral can produce which
interrupt request. By using an interrupt controller we can connect multiple external interrupts to
one of the ARM interrupt requests and distinguish between them. There is a standard design for
assigning interrupts adopted by system designers:
IRQs are normally assigned to general purpose interrupts like periodic timers.
FIQ is reserved for one single interrupt source that requires fast response time, like
Interrupt Latency
It is the interval of time between from an external interrupt signal being raised to the first
fetch of an instruction of the ISR of the raised interrupt signal. System architects must balance
between two things, first is to handle multiple interrupts simultaneously, second is to minimize
the interrupt latency. Minimization of the interrupt latency is achieved by software handlers by
two main methods, the first one is to allow nested interrupt handling so the system can respond
to new interrupts during handling an older interrupt. This is achieved by enabling interrupts
immediately after the interrupt source has been serviced but before finishing the interrupt
handling. The second one is the possibility to give priorities to different interrupt sources; this is
achieved by programming the interrupt controller to ignore interrupts of the same or lower
priority than the interrupt being handled if there is one.
IRQ and FIQ exceptions
Both exceptions occur when a specific interrupt mask is cleared in the CPSR. The ARM
processor will continue executing the current instruction in the pipeline before handling the
interrupt. The processor hardware go through the following standard procedure:
The processor changes to a specific mode depending on the received interrupt.
The previous mode CPSR is saved in SPSR of the new mode.
The PC is saved in the LR of the new mode.
Interrupts are disabled, either IRQ or both IRQ and FIQ.
The processor branches to a specific entry in the vector table.
Enabling/Disabling FIQ and IRQ exceptions is done on three steps; at first loading the
contents of CPSR then setting/clearing the mask bit required then copy the updated contents back
to the CPSR.
79
EMBEDDED SYSTEMS
Interrupt stack
Exception handling uses stacks extensively because each exception has a specific mode
of operation, so switching between modes occurs and saving the previous mode data is required
before switching so that the core can switch back to its old state successfully. Each mode has a
dedicated register containing a stack pointer. The design of these stacks depends on some factors
like operating system requirements for stack design and target hardware physical limits on size
and position in memory. Most of ARM based systems has the stack designed such that the top of
it is located at high memory address. A good stack design tries to avoid stack overflow because
this causes instability in embedded systems.
In the following figure we have two memory layouts which show how the stack is placed in
memory:
The first is the traditional stack layout. The second layout has the advantage that when overflow
occurs, the vector table remains untouched so the system has the chance to correct itself.
Interrupt handling schemes
Here we introduce some interrupt handing schemes with some notes on each scheme
about its advantages and disadvantages.
Non-nested interrupt handling
This is the simplest interrupt handler. Interrupts are disabled until control is returned back
to the interrupted task. So only one interrupt can be served at a time and that is why this scheme
is not suitable for complex embedded systems which most probably have more than one interrupt
source and require concurrent handling. Figure 5 shows the steps taken to handle an interrupt:
Initially interrupts are disabled, when IRQ exception is raised and the ARM processor
disables further IRQ exceptions from occurring. The mode is changed to the new mode
80
EMBEDDED SYSTEMS
depending on the raised exception. The register CPSR is copied to the SPSR of the new mode.
Then the PC is set to the correct entry in the vector table and the instruction there will direct the
PC to the appropriate handler. Then the context of the current task is saved a subset of the
current mode non banked register. Then the interrupt handler executes some code to identify the
interrupt source and decide which ISR will be called. Then the appropriate ISR is called. And
finally the context of the interrupted task is restored, interrupts are enabled again and the control
is returned to the interrupted task.
81
EMBEDDED SYSTEMS
data on the IRQ stack, so all registers saved on the IRQ stack have to be transferred to task stack.
The part of the task stack used in this process is called stack frame. The main disadvantage of
this interrupt handling scheme is that it doesnt differ between interrupts by priorities, so lower
priority interrupt can block higher priority interrupts.
82
EMBEDDED SYSTEMS
When an interrupt signal is raised, a fixed amount of comparisons with the available set
of priority levels is done, so the interrupt latency is deterministic but at the same point this could
be considered a disadvantage because both high and low priority interrupts take the same amount
of time.
Prioritized simple interrupt handling summery:
Handle multiple interrupts with a priority assignment mechanism.
Low interrupt latency.
Deterministic interrupt latency.
Time taken to get to a low priority ISR is the same as for high priority ISR.
Other schemes
There are some other schemes for handling interrupts, designers have to choose the suitable one
depending on the system being designed.
Re-entrant interrupt handler:
The basic difference between this scheme and the nested interrupt handling is that
interrupts are re-enabled early on the re-entrant interrupt handler which can reduce interrupt
latency. The interrupt of the source is disabled before re-enabling interrupts to protect the system
from getting infinite interrupt sequence. This is done by a using a mask in the interrupt
83
EMBEDDED SYSTEMS
controller. By using this mask, prioritizing interrupts is possible but this handler is more
complex.
Prioritized standard interrupt handler:
It is the alternative approach of prioritized simple interrupt handler; it has the advantage
of low interrupt latency for higher priority interrupts than the lower priority ones. But the
disadvantage now is that the interrupt latency in nondeterministic.
Prioritized grouped interrupt handler:
This handler is designed to handle large amount of interrupts by grouping interrupts
together and forming a subset which can have a priority level. This way of grouping reduces the
complexity of the handler since it doesnt scan through every interrupt to determine the priority.
If the prioritized grouped interrupt handler is well designed, it will improve the overall system
response times dramatically, on the other hand if it is badly designed such that interrupts are not
well grouped, then some important interrupts will be dealt as low priority interrupts and vice
versa. The most complex and possibly critical part of such scheme is the decision on which
interrupts should be grouped together in one subset.
AMBA-AHB interfaces the memory, external DRAM (dynamic RAM controller and onchip I/O devices
AMBA-AHB connects to 32-bit data and 32-bit address lines at high speed
84
EMBEDDED SYSTEMS
Switches ARM CPU communication with the AMBA bus to APB bus.
ARM processor based microcontroller has a single data bus in AMBA-AHB that
connects to the bridge, which integrate the bridge onto the same integrated circuit as the
processor to reduce the number of chips required to build a system and thus the system
cost.
The bridge communicates with the memory through a AMBA-AHB, a dedicated set of
wires that transfer data between these two systems.
A separate APB I/O bus connects the bridge to the I/O devices.
ARM BUS
I2C
touch screen
85
EMBEDDED SYSTEMS
SDIO
USB
CONCLUSION
We learnt
ARM bus two types AMBA-AHB and AMBA-APB.
AHB connects high speed memory
APB connects the external peripherals to system memory bus through a bridge
86
EMBEDDED SYSTEMS
functionality, and consequently the CISC instructions are more complicated. Figure 1.1
illustrates these major differences. The RISC philosophy is implemented with four major design
rules:
1. InstructionsRISC processors have a reduced number of instruction classes. These classes
provide simple operations that can each execute in a single cycle. The compiler or programmer
synthesizes complicated operations (for example, a divide operation) by combining several
simple instructions. Each instruction is a fixed length to allow the pipeline to fetch future
instructions before decoding the current instruction. In contrast, in CISC processors the
instructions are often of variable size and take many cycles to execute.
2. Pipelinesthe processing of instructions is broken down into smaller units that can be
executed in parallel by pipelines. Ideally the pipeline advances by one step on each cycle for
maximum throughput. Instructions can be decoded in one pipeline stage. There is no need for an
instruction to be executed by a mini program called microcode as on CISC processors.
3. RegistersRISC machines have a large general-purpose register set. Any register can contain
either data or an address. Registers act as the fast local memory store for all data processing
operations. In contrast, CISC processors have dedicated registers for specific purposes.
87
EMBEDDED SYSTEMS
lower clock frequencies. Over the course of two decades, however, the distinction between RISC
and CISC has blurred as CISC processors have implemented more RISC concepts.
CAN BUS
CAN (Controller Area Network) is a serial bus system, which was originally developed
for automotive applications in the early 1980's.
The CAN protocol was internationally standardized in 1993 as ISO 11898-1 and
comprises the data link layer of the seven layer ISO/OSI reference model.
CAN provide two communication services: the sending of a message (data frame
transmission) and the requesting of a message (remote transmission request, RTR).
The equivalent of the CAN protocol in human communication are e.g. the Latin
characters. CAN users still have to define the language/grammar and the
words/vocabulary to communicate?
CAN provides
*A multi-master hierarchy, which allows building intelligent and
redundant systems.
*Broadcast communication. A sender of information transmits to all
devices on the bus. All receiving devices read the message and then decide if it is
relevant to them.
*Sophisticated error detecting mechanisms and re-transmission of faulty
messages.
88
EMBEDDED SYSTEMS
CAN PROTOCOL
1. PRINCIPLES OF DATA EXCHANGE
It is easy to add stations to an existing CAN network without making any hardware or
software modifications to the present stations as long as the new stations are purely
receivers.
This allows for a modular concept and also permits the reception of multiple data and the
synchronization of distributed processes.
Data transmission is not based on the availability of specific types of stations allowing
simple servicing and upgrading of the network.
In real-time processing the urgency of messages to be exchanged over the network can
differ greatly.
The priority, at which a message is transmitted compared to another less urgent message,
is specified by the identifier of each message.
89
EMBEDDED SYSTEMS
Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved by
each station observing the bus level bit for bit. This happens in accordance with the
wired-and mechanism, by which the dominant state overwrites the recessive state.
Transmission requests are handled in order of their importance for the system as a whole.
The CAN protocol supports two message frame formats, the only essential difference
being in the length of the identifier.
The CAN base frame supports a length of 11 bits for the identifier and the CAN
extended frame supports a length of 29 bits for the identifier.
For error detection the CAN protocol implements three mechanisms at the message level:
Cyclic Redundancy Check (CRC)
Frame check
ACK errors
The CAN protocol also implements two mechanisms for error detection at the bit level:
90
EMBEDDED SYSTEMS
Monitoring: Each station that transmits also observes the bus level and thus
detects differences between the bit sent and the bit received.
Bit stuffing: The bit representation used by CAN is "Non Return to Zero (NRZ)"
coding. The synchronization edges are generated by means of bit stuffing. This
stuff bit has a complementary value, which is removed by the receivers.
CAN hardware implementations cover the lower two layers of the OSI reference model while
various software solutions (higher layer protocols) cover the layers three to seven.
CAN protocol define the data link layer and part of the physical layer in the OSI model,
which consists of seven layers. The International Standards Organization (ISO) defined a
standard, which incorporates the CAN specifications as well as a part of physical layer:
the physical signaling, which comprises bit encoding and decoding (Non-Return-to- Zero,
NRZ) as well as bit timing and synchronization.
The CAN physical medium is a two-wire bus line with common return terminated at both
ends by resistors. Differential signal is used for better immunity. The following figure
shows a transmit signal from a CAN controller, the differential signal emitted on the line
and the receive signal received by the CAN controller to monitor the CAN bus.
A typical CAN bus in a factory automation application is a single line bus with stubs to
connect equipments such as PLC, Sensors, Drives etc as illustrated by the figure below :
91
EMBEDDED SYSTEMS
CAN DESIGN
USB BUS
Introduction to the USB
USB (Universal Serial Bus) is as its name suggests, based on serial type architecture.
However, it is an input-output interface much quicker than standard serial ports. Serial
architecture was used for this type of port for two main reasons:
Serial architecture gives the user a much higher clock rate than a parallel interface because a
parallel interface does not support too high frequencies (in a high speed architecture, bits
circulating on each wire arrive with lag, causing errors);
USB standards
So, from 1995, the USB standard has been developed for connecting a wide range of devices.
The USB 1.0 standard offers two modes of communication:
The USB 1.1 standards provide several clarifications for USB device manufacturers but does not
change anything in the speed.
92
EMBEDDED SYSTEMS
The USB 2.0 standards makes it possible to obtain speeds which can reach 480 Mbit/s
If there is no logo, the best way of determining if something is a low or high speed USB
is to consult the product documentation insofar as the connectors are the same.
Compatibility between USB 1.0, 1.1 and 2.0 is assured. However, the use of a USB 2.0
device in a low speed USB port (i.e. 1.0 or 1.1) will limit the speed to 12Mbit/s maximum.
Furthermore, the operating system is likely to display a message explaining that the speed will be
restricted.
Types of connectors
There are two types of USB connectors:
Connectors known as type A, where the shape is rectangular and generally used for less
bandwidth intensive devices (keyboard, mouse, webcam, etc.);
Connectors known as type B, where the shape is square and mainly used for high speed
devices (external hard disks, etc.);
93
EMBEDDED SYSTEMS
The USB standard allows devices to be chained by using a bus or star topology. So,
devices
can
either
be
connected
one
to
another
or
branched.
Branching is done using boxes called "hubs" comprising of a single input and several outputs.
Some are active (supplying electric energy), others passive (power supplied by the computer).
Communication between the host (computer) and devices is carried out according to
a protocol (communication language) based on the token ring principle. This means that
bandwidth is temporarily shared between all connected devices. The host (computer) issues a
signal to begin the sequence every millisecond (ms), the time interval during which it will
simultaneously give each device the opportunity to "speak". When the host wants to
communicate with a device, it transmits a token (a data packet, containing the address of the
device coded over 7 bits) designating a device, so it is the host that decides to "talk" with the
devices. If the device recognizes its address in the token, it sends a data packet (between 8 and
255 bytes) in response, if not it passes the packet to the other connected devices. Data is
exchanged in this way is coded according to NRZI coding.
Since the address is coded over 7 bits, 128 devices (2^7) can simultaneously be
connected to a port of this type. In reality, it is advisable to reduce this number to 127 because
the 0 address is a reserved address.
Due to the maximum length of the cable between two devices of 5 meters and a
maximum number of 5 hubs (supplied), it is possible to create a chain 25 meters in length.
USB ports support hot plug and play. So, devices can be connected without turning off
the computer (hot plug). When a device is connected to the host it detects the addition of a new
item thanks to a change in the tension between the D+ and D- wires. At this time, the computer
sends an initialization signal to the device for 10ms, then it supplies the current using
the GND and VBUS wires (up to 100mA). The device is then supplied with electric current and
temporarily takes over the default address (0 addresses). The following stage consists of
supplying it with its definitive address (this is the listing procedure). To do so, the computer
interrogates devices already connected to know their addresses and allocates a new one, which
94
EMBEDDED SYSTEMS
identifies it by return. The host, having all the necessary characteristics is then able to load the
appropriate driver.
Expansion bus to a processor bus. Devices connected to the PCI bus appear to the
processor as they were directly connected to the processor bus. A low cost bus, truly
processor independent.
Growing demand for bus bandwidth to support high speed disks, graphic and video
devices, and specialized needs of multiprocessor systems.
The PCI Local Bus is a high performance 32-bit or 64-bit bus with multiplexed address and data
lines.
The bus is intended for use as an interconnect mechanism between highly integrated peripheral
controller components, peripheral add-in boards and processor/memory systems.
PCI Features
The PCI component and add-in card interface is processor independent enabling an efficient
transition to future processor generations and use with multiple processor architectures.
A transparent 64-bit extension of the 32-bit data and address buses is defined doubling the bus
bandwidth and offering forward and backward compatibility of 32-bit and 64-bit PCI
peripherals.
95
EMBEDDED SYSTEMS
A forward and backward compatible 66 MHz specification is also defined doubling the
capabilities of the 33 MHz definition.
Configuration registers are specified for PCI components and add-in cards. A system with
embedded auto-configuration software offers true ease-of-use by automatically configuring PCI
add-in cards at power on. PCI specifies one interrupt line for a single-function device and up to 4
interrupt lines for a multi-function device.
PCI Local Bus Overview
96
EMBEDDED SYSTEMS
GPIB BUS
GPIB Description [IEEE488]
GPIB SYSTEM
The IEEE-488 interface bus, also known as the General Purpose Interface Bus "GPIB" is an 8 bit
wide byte serial, bit parallel interface system which incorporates:
5 control lines
3 handshake lines
8 bi-directional data lines.
The entire bus consists of 24 lines, with the remaining lines occupied by ground wires.
Additional features include: TTL logic levels (negative true logic), the ability to communicate in
a number of different language formats, and no minimum operational transfer limit. The
maximum data transfer rate is determined by a number of factors, but is assumed to be 1Mb/s.
Devices exist on the bus in any one of 3 general forms:
1. Controller
2. Talker
3. Listener
A single device may incorporate all three options, although only one option may be
active at a time. The Controller makes the determination as to which device becomes active on
the bus. The GPIB can handle only 1 active controller on the bus, although it may pass
97
EMBEDDED SYSTEMS
operation to another controller. Any number of active listeners can exist on the bus with an
active talker as long as no more then 15 devices are connected to the bus. The controller
determines which devices become active by sending interface messages over the bus to a
particular instrument. Each individual device is associated with a 5 bit BCD code which is
unique to that device. By using this code, the controller can coordinate the activities on the bus
and the individual devices can be made to talk, listen (un-talk, un-listen) as determined by the
controller. A controller can only select a particular function of a device, if that function is
incorporated within the device; for example a listen only device can not be made to talk to the
controller. The Talker sends data to other devices. The Listener receives the information from the
Talker. In addition to the 3 basic functions of the controller, talker, and listener the system also
incorporates a number of operational features, such as; serial poll, parallel poll, secondary talk
and listen addresses, remote/local capability, and a device clear (trigger). Device dependent
messages are moved over the GPIB in conjunction with the data byte transfer control lines.
These three lines (DAV, NRFD, and NDAC) are used to form a three wire interlocking
handshake which controls the passage of data. The active talker would control the DAV line
(Data Valid) and the listener(s) would control the NRFD (Not Ready for Data), and the
NDAC (Not Data Accepted) line. In the steady state mode the talker will hold DAV high (no
data available) while the listener would hold NRFD high (ready for data) and NDAC low (no
data accepted. After the talker placed data on the bus it would then take DAV low (data valid).
The listener(s) would then send NRFD low and send NDAC high (data accepted). Before the
talker lifts the data off the bus, DAV will be taken high signifying that data is no longer valid.
If the ATN line (attention) is high while this process occurs the information is considered data (
a device dependent message), but with the "ATN line low the information is regarded as an
interface message; such as listen, talk, un-listen or un-talk. The other five lines on the bus
(ATN included) are the bus management lines. These lines enable the controller and other
devices on the bus to enable, interrupt, flag, and halt the operation of the bus. All lines in the
GPIB are tri-state except for SQR, NRFD, and NDAC which are open-collector. The
standard bus termination is a 3K resistor connected to 5 volts in series with a 6.2K resistor to
ground - all values having a 5% tolerance.
98
EMBEDDED SYSTEMS
The standard also allows for identification of the devices on the bus. Each device should
have a string of 1 or 2 letters placed some where on the body of the device (near or on the GPIB
connector). These letters signify the capabilities of the device on the GPIB bus.
C Controller
T Talker
L Listener
AH Acceptor Handshake
SH Source Handshake
DC Device Clear
DT Device Trigger
RL Remote Local
PP Parallel Poll
TE Talker Extended
LE Listener Extended
99
EMBEDDED SYSTEMS
UNIT II
TWO MARKS
1. Give the summary of I/O devices used in embedded system
2. Define bus.
3. What are the classifications of I/O devices?
4. Give some examples for serial input I/O devices.
5. Give the steps for accomplishing input output data transfer
6. Give the limitations of polling technique.
7. What do you meant by bus arbitration?
8. What are the two characteristics of synchronous communication?
9. What do you mean by asynchronous communication?
10. What are the characteristics of asynchronous communication?
11. What are the three ways of communication for a device?
12. Expand a) SPI b) SCI
13. What are the features of SPI?
14. Define software timer.
15. What are the forms of timer?
16. Define RTC
17. What is I2C?
18. What are the bits in I2C corresponding to?
19. What is a CAN bus? Where is it used?
20. What is USB? Where is it used? [November 2012]
21. What are the features of the USB protocol?
22. What are the four types of data transfer used in USB?
23. Explain briefly about PCI and PCI/X buses. (or) List any two parallel buses used in
embedded Systems [April/May 2014]
24. Mention some advanced bus standard protocols;
25. What do you meant by high speed device interfaces?
26. Mention some I/O standard interfaces.
27. WHAT IS THE ARM BUS ARCHITECTURE? [ April/may 2012]
28. What are the types of Interrupt handler?
100
EMBEDDED SYSTEMS
UNIT 2
11 MARKS
1. Discuss the arm architecture in detail (April 2013)[ref. Page no. :45]
2. What is the arm family of processor?
3. What are the registers and memory access processes in arm? [April 2013][Ref. Page no.: 59]
4. How the data transferred in arm using instructions? [November 2012][Ref. Page no.: 64]
5. What are the load/store multiple operands in arm processor?
6. Classify the instructions set of arm and explain [April/May 2012][Ref. Page no.:73]
6. Explain the arithmetic instructions of arm?
7. What are the logic instructions of arm?
8. Explain the branch instructions in detail?
9. Explain the assembly language of arm processor?
10. What is pseudo-instructions?
11. Explain the I/O operations interrupt structure
12. What is arm cache? [November 2012][Ref. Page no.: 84]
13. Explain arm bus in detail? [November 2012] [Ref. Page no.: 84]
14. Explain embedded systems with arm?[November 2011] [Ref. Page no.:45]
15. What are the serial bus protocols? [November 2014] [Ref. Page no.:86]
16. Explain the parallel bus protocols? [November 2011] [Ref. Page no.:93]
101
EMBEDDED SYSTEMS
102
EMBEDDED SYSTEMS
Prepared By :
Mr.P.Karthikeyan,AP/CSE
Mr.B.Thiyagarajan, AP/CSE
Mrs.P.Subha Priya, AP/CSE
Verified by :
Approved by :
UNIT III
Software Development:
Embedded Programming in C and C++ - Source Code Engineering Tools for Embedded C/C++ Program Modeling Concepts in Single and Multiprocessor Systems - Software Development
Process - Software Engineering Practices in the Embedded Software Development Hardware /
Software Co-design in an Embedded System.
103
EMBEDDED SYSTEMS
104
EMBEDDED SYSTEMS
105
EMBEDDED SYSTEMS
New value in the calling function will be returned from the called function.
13. Write the syntax for function pointer.
Syntax:
void *<function_name> (function arguments)
14. Define queue.
A structure with a series of elements.
Uses FIFO mode.
It is used when an element is not directly accessed using pointer and index but only
through FIFO.
Two pointers are used for insertion and deletion.
15. Define stack.
A structure with a series of elements which uses LIFO mode.
An element can be pushed only at the top and only one pointer is used for POP.
Used when an element is not accessible through pointer and index, but only through
LIFO.
16. Define List.
Each element has a pointer to its next element.
Only the first element is identifiable and it is done using list-top pointer (header).
Other element has no direct access and is accessed through the first element.
17. What is Object oriented programming?
An object-oriented programming language is used when there is a need for re-usability of
defined objects or a set of objects that are common for many applications.
18. What are the advantages of OOPs?
Data encapsulation
Reusable software components
Inheritance
19. What are the characteristics of OOPs?
An identity reference to a memory block
A state data, field and attributes
A behavior methods to manipulate the state of the object
106
EMBEDDED SYSTEMS
107
EMBEDDED SYSTEMS
Poor in Multitasking.
UML is designed to meet some very specific objectives so that it can truly be a standard
that addresses the practical needs of the software development community. Any effort to be all
things to all people is doomed to fail, so the UML authors have taken care to establish clear
boundaries for the features of the UML.
The goals of UML
The OMG knows that the success of UML hinges on its ability to address the widely
diverse real-world needs of software developers. The standard will fail if it is too rigid or too
relaxed, too narrow in scope or too all-encompassing, too bound to a particular technology or so
vague that it cannot be applied to real technologies. To ensure that the standard will, in fact, be
both practical and durable, the OMG established a list of goals.
29. Write down the uses of DFGs and CDFGs.[November 2012]
Data-flow Graph is a technique for gathering information about the possible set of
values calculated at various points in a computer program. A program's control flow graph
(CFG) is used to determine those parts of a program to which a particular value assigned to a
variable might propagate. The information gathered is often used by compilers when optimizing
a program. A canonical example of a data-flow analysis is reaching definitions.
108
EMBEDDED SYSTEMS
UNIT III
11 MARKS
1. Specify the C++ features that suits embedded program. [April/May 2014]
An object oriented language is used when there is a need for reusability of the defined
object or set of objects that are common within a program between many applications. When a
large program is to be made, an object-oriented language offers many advantages. Data
encapsulation, design of reusable software components and inheritance are the advantages
derived from the OOPs.
An object-oriented language provides for defining the objects and methods that manipulate the
objects modifying their definitions. It provides for the data and methods for encapsulation. An
object can be characterized by the following:
An identity, a reference to a memory block that holds its state and behavior.
In an object- oriented language like Smalltalk, C++ or Java, logical groups (also known
as classes) are first made. Each group defines the data and the methods of using the data.
Each group has internal user-level fields for the data and the methods of processing that
data at these fields.
Each group can then create many objects by copying the group and making it functional.
Each object is functional.
Each object can interact with other objects to process the user's data.
The language provides for formation of classes by the definition of a group of objects
having similar attributes and common behavior.
109
EMBEDDED SYSTEMS
Embedded Programming in C+ +
Embedded system codes can optimized when using an OOp language by the following:
Declare private as many classes as possible. It helps in optimizing the generated codes.
Use char, int and boolean (scalar data types) in place of the objects (reference data types)
as arguments and use local variables as much as feasible.
A special compiler for an embedded system can facilitate the disabling of specific
features provided in C++.
Embedded C++ is a version of C++ that provides for a selective disabling of the above
features so that there is a less runtime overhead and less runtime library.
The solutions for the library functions in an embedded C++ compiler are also reentrant.
So using embedded C++ compilers or the special compilers make the C++ a significantly
more powerful coding language than C for embedded systems.
GNU Compiler
GNU C/C++ compilers (called gcc) find extensive use in the C++ environment in
embedded software development.
Embedded C++ is a new programming tool with a compiler that provides a small runtime
library.
When there is a less runtime overhead and when the less runtime library using solutions
are available. Selectively removed (de-configured) features could be template, run time
type identification, multiple inheritance, exceptional handling, virtual base class, I/O
streams and foundation classes.
110
EMBEDDED SYSTEMS
An embedded system (C++ compiler (other than gcc) is Diab compiler from Diab data. It
also provides the target (embedded System processors) specific optimization codes. The run- line
analysis tools check the expected run time error and give a profile that is visually interactive.
Embedded C++ is a C++ version, which makes large program development simpler by
providing object oriented programming features of using an object, which binds state and
behavior and which is defined by an instance of a class.
Diab compiler has two special features processor specific code optimization and run time
analysis tools for finding expected run time errors.
2.
Introduction
Application programs are typically developed, compiled, and run on host
system
Embedded programs are targeted to a target processor (different from the
development/host processor and operating environment) that drives a device
or controls
What tools are needed to develop, test, and locate embedded software into the
target processor and its operating environment?
Distinction
Host: Where the embedded software is developed, compiled, tested,
debugged, optimized, and prior to its translation into target device. (Because
the host has keyboards, editors, monitors, printers, more memory, etc. for
development, while the target may have not of these capabilities for
developing the software.)
Target: After development, the code is cross-compiled, translated crossassembled, linked (into target processor instruction set) and located into the
target
Cross-Compilers
Native tools are good for host, but to port/locate embedded code to target, the
host must have a tool-chain that includes a cross-compiler, one which runs on
the host but produces code for the target processor
Cross-compiling doesnt guarantee correct target code due to (e.g., differences
in word sizes, instruction sizes, variable declarations, library functions)
Cross-Assemblers and Tool Chain
111
EMBEDDED SYSTEMS
A source code engineering tool is of great help for source-code development, compiling
and cross compiling. The tools are commercially available for embedded C /C++ code
engineering, testing and debugging.
The features of a typical tool are comprehension, navigation and browsing editing debugging
configuring (disabling and enabling the C++ features). A tool for C and C++ is Sniff+. It is from
112
EMBEDDED SYSTEMS
Wind River systems. A version SNIFF+ PRO code as well as debug module. Main features of
the tool are as follows:
It searches and lists the definitions symbols and hierarchy of the classes, and class
inheritance trees.
It searches and lists the dependencies of symbols and defined symbols, variables,
functions (methods) and other symbols.
It finds the full effect of any code change on the source code.
It searches and lists the dependencies and hierarchy of included header files
It navigates to and fro between the overridden and overriding methods. [Overriding
method is method in daughter class with same name and same number and types of
arguments as in the parent class. Overridden method is the method of the parent class,
which has been redefined at the daughter class.
It browses the information encapsulation of variables among the members and browses
through the public, private and protected visibility of the members.
The embedded software designer for sophisticated applications uses source code engineering
tool for program coding, profiling, testing and debugging of embedded software design.
113
EMBEDDED SYSTEMS
3.
A multiprocessor system uses two or more processors for faster execution of the (i) Program
functions, (ii) tasks or (iii) single instruction multiple data instructions
A large complex program
Partitioned into the tasks or sets of instructions (or processes or threads) and the ISRs.
The tasks and ISRs can run concurrently on different processors and by some mechanism
the tasks can communicate with each other
Static scheduling
114
EMBEDDED SYSTEMS
Means that a compiler compiles such that the codes are run on different processors or processing
units as per the schedule decided and this schedule remains static during the program run even if
a processor waits for the others to finish the scheduled processing.
The Multiprocessor System memory interface Models
Share the same address space through a common bus (tight coupling)
Partition the program into tasks or sets of instructions between the various processors
Schedule the instructions over the available processor times and resources so that there is
optimum performance.
Schedule the instructions, SIMDs, MIMDs, and VLIWs within each process and
scheduling them for each processor
115
EMBEDDED SYSTEMS
Static scheduling issue [For example, when the performance is not affected and when the
processing actions are predictable and synchronous.]
Dynamic scheduling issues [For example, when the performance is affected when there
are interrupts and when the services to the tasks are asynchronous. It is also relevant
when there is preemptive scheduling as that is also asynchronous.]
Schedule each task so that it is executed on different processors and synchronizes the
tasks by some inter processor communication mechanism
When an SMID or MIMD or VLIW instruction has different data (for example, different
coefficients in Filter example
Each task is processed on different processors (tightly coupled processing) for different
data.
TMS320C6 employs two identical sets of four units and a VLIW instruction word can be
within four and thirty-two bytes.
TMS320C6 has instruction level parallelism when a compiler schedules such that the
processors run the different instruction elements into the different units in parallel.
116
EMBEDDED SYSTEMS
Method 3
A compiler schedules the various instructions of the tasks among the processors at an
instance.
Performance cost
Performance cost is more if there is idle time left from the available time.
If one task needs to send a message to another and the other waits (blocks) till the
message is received, performance cost is proportional to the waiting period.
A multiprocessor system uses two or more processors for faster execution of the (i) Program
functions, (ii) tasks or (iii) single instruction multiple data instructions
Partitioning of the processes and scheduling of processes on multiple processor can be static or
dynamic.
4.
117
EMBEDDED SYSTEMS
Overview
A largely growing body of software development organizations implement process
methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on
'process models' to obtain contracts.
The international standard for describing the method of selecting, implementing and
monitoring the life cycle for software is ISO 12207.
A decades-long goal has been to find repeatable, predictable processes that improve
productivity and quality. Some try to systematize or formalize the seemingly unruly task of
writing software. Others apply project management techniques to writing software. Without
project management, software projects can easily be delivered late or over budget. With large
numbers of software projects not meeting their expectations in terms of functionality, cost, or
delivery schedule, effective project management appears to be lacking.
Organizations may create a Software Engineering Process Group (SEPG), which is the
focal point for process improvement. Composed of line practitioners who have varied skills, the
group is at the center of the collaborative effort of everyone in the organization who is involved
with software engineering process improvement.
Software development activities
Requirements analysis
The most important task in creating a software product is extracting the requirements or
requirements analysis. Customers typically have an abstract idea of what they want as an end
result, but not what software should do. Incomplete, ambiguous, or even contradictory
requirements are recognized by skilled and experienced software engineers at this point.
Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gleaned from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of
118
EMBEDDED SYSTEMS
unclear requirements at the start of development. If the development is done externally, this
document can be considered a legal document so that if there are ever disputes, any ambiguity of
what was promised to the client can be clarified.
Domain Analysis is often the first step in attempting to design a new piece of software,
whether it is an addition to existing software, a new application, a new subsystem or a whole
new system. Assuming that the developers (including the analysts) are not sufficiently
knowledgeable in the subject area of the new software, the first task is to investigate the socalled "domain" of the software. The more knowledgeable they are about the domain already, the
less work required. Another objective of this work is to make the analysts, who will later try to
elicit and gather the requirements from the area experts, speak with them in the domain's own
terminology, facilitating a better understanding of what is being said by these experts. If the
analyst does not use the proper terminology it is likely that they will not be taken seriously, thus
this phase is an important prelude to extracting and gathering the requirements.
Specification
Specification is the task of precisely describing the software to be written, possibly in a
rigorous way. In practice, most successful specifications are written to understand and fine-tune
applications that were already well-developed, although safety-critical software systems are
often carefully specified prior to application development. Specifications are most important for
external interfaces that must remain stable. A good way to determine whether the specifications
are sufficiently precise is to have a third party review the documents making sure that the
requirements and Use Cases are logically sound.
Architecture
The architecture of a software system or software architecture refers to an abstract
representation of that system. Architecture is concerned with making sure the software system
will meet the requirements of the product, as well as ensuring that future requirements can be
addressed. The architecture step also addresses interfaces between the software system and other
software products, as well as the underlying hardware or the host operating system.
Design, implementation and testing
119
EMBEDDED SYSTEMS
Implementation is the part of the process where software engineers actually program the
code for the project.
Software testing is an integral and important part of the software development process.
This part of the process ensures that bugs are recognized as early as possible.
Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the authoring of an API, be
it external or internal.
Deployment and maintenance
Deployment starts after the code is appropriately tested, is approved for release and sold
or otherwise distributed into a production environment.
Software Training and Support is important because a large percentage of software
projects fail because the developers fail to realize that it doesn't matter how much time and
planning a development team puts into creating software if nobody in an organization ends up
using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a
part of the deployment phase, it is very important to have training classes for new clients of your
software.
Maintenance and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. It may be
necessary to add code that does not fit the original design to correct an unforeseen problem or it
may be that a customer is requesting more functionality and code can be added to accommodate
their requests. It is during this phase that customer calls come in and you see whether your
testing was extensive enough to uncover the problems before customers do
Models
Iterative processes
120
EMBEDDED SYSTEMS
Iterative development prescribes the construction of initially small but ever larger
portions of a software project to help all those involved to uncover important issues early before
problems or faulty assumptions can lead to disaster. Iterative processes are preferred by
commercial developers because it allows a potential of reaching the design goals of a customer
who does not know how to define what they want.
Agile software development
Agile software development processes are built on the foundation of iterative
development. To that foundation they add a lighter, more people-centric viewpoint than
traditional approaches. Agile processes use feedback, rather than planning, as their primary
control mechanism. The feedback is driven by regular tests and releases of the evolving software.
Interestingly, surveys have shown the potential for significant efficiency gains over the
waterfall method. For example, a survey, published in August 2006 by VersionOne and Agile
Alliance and based on polling more than 700 companies claims the following benefits for an
Agile approach.
XP: Extreme Programming
Extreme Programming (XP) is the best-known iterative process. In XP, the phases are
carried out in extremely small (or "continuous") steps compared to the older, "batch" processes.
The (intentionally incomplete) first pass through the steps might take a day or a week, rather than
the months or years of each complete step in the Waterfall model. First, one writes automated
tests, to provide concrete goals for development. Next is coding (by a pair of programmers),
which is complete when all the tests pass, and the programmers can't think of any more tests that
are needed. Design and architecture emerge out of refactoring, and come after coding. Design is
done by the same people who do the coding. (Only the last feature - merging design and code - is
common to all the other agile processes.) The incomplete but functional system is deployed or
demonstrated for (some subset of) the users (at least one of which is on the development team).
At this point, the practitioners start again on writing tests for the next most important part of the
system.
121
EMBEDDED SYSTEMS
Waterfall processes
The waterfall model shows a process, where developers are to follow these steps in order:
1. Requirements specification (AKA Verification or Analysis)
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation (AKA deployment)
7. Maintenance
After each step is finished, the process proceeds to the next step, just as builders don't revise
the foundation of a house after the framing has been erected.
There is a misconception that the process has no provision for correcting errors in early steps
(for example, in the requirements). In fact this is where the domain of requirements management
comes in which includes change control.
This approach is used in high risk projects, particularly large defense contracts. The problems
in waterfall do not arise from "immature engineering practices, particularly in requirements
analysis and requirements management." Studies of the failure rate of the DOD-STD-2167
specification, which enforced waterfall, have shown that the more closely a project follows its
process, specifically in up-front requirements gathering, the more likely the project is to release
features that are not used in their current form. Often the supposed stages are part of review
between customer and supplier, the supplier can, in fact, develop at risk and evolve the design
but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts
engineering burdens from engineers to customers who may have other skills.
Other models
Capability Maturity Model Integration
122
EMBEDDED SYSTEMS
The Capability Maturity Model Integration (CMMI) is one of the leading models
and based on best practice. Independent assessments grade organizations on how well
they follow their defined processes, not on the quality of those processes or the software
produced. CMMI has replaced CMM.
ISO 9000
ISO 9000 describes standards for formally organizing processes with
documentation.
ISO 15504
ISO 15504, also known as Software Process Improvement Capability
Determination (SPICE), is a "framework for the assessment of software processes". This
standard is aimed at setting out a clear model for process comparison. SPICE is used
much like CMMI. It models processes to manage, control, guide and monitor software
development. This model is then used to measure what a development organization or
project team actually does during software development. This information is analyzed to
identify weaknesses and drive improvement. It also identifies strengths that can be
continued or integrated into common practice for that organization or team.
Six sigma
Six sigma is a methodology to manage process variations that uses data and
statistical analysis to measure and improve a company's operational performance. It
works by identifying and eliminating defects in manufacturing and service-related
processes. The maximum permissible defects are 3.4 per one million opportunities.
However, Six Sigma is manufacturing-oriented and needs further research on its
relevance to software development.
Test Driven Development
Test Driven Development (TDD) is a useful output of the Agile camp but some
suggest that it raises a conundrum. TDD requires that a unit test be written for a class
before the class is written. It might be thought, then, that the class firstly has to be
"discovered" and secondly defined in sufficient detail to allow the write-test-once-andcode-until-class-passes model that TDD actually uses. This would be actually counter to
Agile approaches, particularly (so-called) Agile Modeling, where developers are still
123
EMBEDDED SYSTEMS
encouraged to code early, with light design. However, to get the claimed benefits of TDD
a full design down to class and responsibilities (captured using, for example, Design By
Contract) is not necessary. This would count towards iterative development, with a
design locked down, but not iterative design - as heavy refactoring and re-engineering
might negate the usefulness of TDD.
Formal methods
Formal methods are mathematical approaches to solving software (and hardware) problems
at the requirements, specification and design levels. Examples of formal methods include the BMethod, Petri nets, RAISE and VDM. Various formal specification notations are available, such
as the Z notation. More generally, automata theory can be used to build up and validate
application behavior by designing a system of finite state machines.
Finite state machine (FSM) based methodologies allow executable software specification and
by-passing of conventional coding (see virtual finite state machine or event driven finite state
machine).
Formal methods are most likely to be applied in avionics software, particularly where the
software is safety critical. Software safety assurance standards, such as DO178B demand formal
methods at the highest level of categorization (Level A).
Formalization of software development is creeping in, in other places, with the application of
Object Constraint Language (and specializations such as Java Modeling Language) and
especially with Model-driven architecture allowing execution of designs, if not specifications.
Another emerging trend in software development is to write a specification in some form of
logic (usually a variation of FOL), and then to directly execute the logic as though it were a
program. The OWL language, based on Description Logic, is an example. There is also work on
mapping some version of English (or another natural language) automatically to and from logic,
and executing the logic directly. Examples are Attempt to Controlled English, and Internet
Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems
124
EMBEDDED SYSTEMS
that support bidirectional English-logic mapping and direct execution of the logic is that they can
be made to explain their results, in English, at the business or scientific level.
The Government Accountability Office, in a 2003 report on one of the Federal Aviation
Administrations air traffic control modernization programs, recommends following the agencys
guidance for managing major acquisition systems by
5.
125
EMBEDDED SYSTEMS
Re-use - This is probably the most misunderstood practice. We have found that although proper
design can maximize re-use, two principles need to be instilled in all of your software engineers
if you want to maximize re-use:
A well designed late product is not necessarily better than an on-time mediocre design.
If you think you can do it faster by starting from scratch, than by understanding the existing
code, come back when you understand the existing code.
Maximize Tool Usage - Very few projects allocate time up front to evaluate what tools could be
made or bought that will reduce the time to market. The tools could be used for modeling,
automatic code generation, testing or any number of other areas.
Continuously verify quality - Poor performance and poor reliability are common results of an
inadequate focus on software quality. Rational places and emphasis on quality throughout the
project lifecycle, with testing conducted in each iteration. This is in contrast to a more traditional
approach that leaves the testing of integrated software until late in the project's lifecycle.
Manage change - A key challenge when developing software-intensive systems is coordinating
the work of multiple developers organized into different teams sometimes located at different
sites working on multiple iterations, releases, products, and platforms. By establishing
repeatable procedures for managing changes to software and other development artifacts, you
minimize chaos; maximize efficient allocation of resources, and ensuring your freedom to
change.
Embedded software development has evolved into a large-scale, globally distributed endeavor,
posing significant engineering management challenges. Embedded projects now involve huge
teams of developers, outsourcers, third-party software technology vendors, chipset partners and
even open source. However, software development methods and practices are largely the same as
ten years ago, especially in the areas of integration and testing. As a result, companies are
struggling with the challenge of managing, integrating and verifying a vast array of components
from many different sources. As a short-term fix, software managers add more engineers and
resources but with limited effectiveness and at very high cost. Often, they still end up delivering
software releases late and with compromised quality.
126
EMBEDDED SYSTEMS
The growing complexity of embedded software development requires a new more reliable and
scalable approachone that adopts early developer testing practices and implements automated
software verification to prevent and detect more defects sooner. The objective is to have all
developers and integrators create reusable tests that can be shared and automated throughout the
development cycle. This strategy replaces ad hoc testing with continuous automated testing to
ensure the on-time delivery of fully tested and properly functioning products
The market for sophisticated embedded software-based products is exploding. As the industry
evolves to support an ever growing range of capabilities and features, the underlying
microprocessors become smaller and faster, and the software content just keeps multiplying.
A few years ago, a typical embedded application included a few thousand lines of monolithic
code developed by a few developers at a single location. Todays embedded application may
incorporate millions of lines of code developed by more than a hundred developers. It has
become a complex software platform comprising a huge number of software components
brought together from various sources and locations.
In the past, the embedded software industry was driven by technical competence, meaning that
smart technical guys somehow always came through. There has never really been a push to
invest in processes and technologies to address this rapid increase in complexity. Now, in the
race to beat the competition, product developers and manufacturers face greater time-to-market
127
EMBEDDED SYSTEMS
pressures and tighter product release schedules. Yet they have more code to manage, limited
ability to properly test it, and less time to find and fix problems. This is a recipe for disaster.
Its very apparent that the current approaches and technologies that were sufficient in the last
decade are no longer adequate. Software methods, practices and technology simply have not
evolved in response to these new complex integration issues.
Possibly the most alarming observation is the relative time and resources devoted to quality
assurance (QA) or product testing. In many companies, time spent on software coding or
implementation is relatively short, while integration activities can take twice as long. However,
product testing efforts are truly daunting, taking 5-10 times as long as implementation, while
staffed with very large teams that continue to grow.
At many companies, integration testing is merely a smoke test or sanity test to confirm
viable software build by manually executing a rudimentary set of tests. Even when integration
testing is more extensive, the test coverage is limited by the time-consuming nature of manual
testing. Often the first time all embedded software components are extensively tested as an
integrated whole is during QA or production testing.
As a result, QA engineers usually uncover large volumes of defects. A hiatus ensues as managers
redirect developers from other work to isolate, characterize and debug large numbers of critical
and serious defects. Engineers try in vain to salvage a release schedule but they know the odds
are stacked against them. By catching defects late, developers are fixing bugs when theyre the
most difficult, time-consuming and expensive to resolve. With so many critical and serious
defects, software managers inevitably not only miss their delivery schedule, but also find it
difficult to predict new delivery dates. Worse yet, they cannot be sure that the code they
ultimately release is high quality and free from costly or dangerous errors
128
EMBEDDED SYSTEMS
129
EMBEDDED SYSTEMS
health of releases. Managers must be able to pinpoint trouble spots, and make decisions based on
real data or metrics.
An Automated, Test-Driven Strategy
To achieve these objectives, the mantra needs to be Automate, Automate, Automate. Then,
reuse and automate the tests whenever code has changed or at various integration points
throughout the development cycle. This strategy sounds conceptually simple but it does
nonetheless require a process change involving adoption of new methods, implementation of
automated infrastructure, and a change in mentality regarding the importance of developer
testing. Lets examine this strategy more closely, looking at certain test-driven software practices
and the role of an embedded software verification platform.
Due to the complexity of todays embedded software, developers need to actively participate in
the verification of their code. As the creators and architects of software components, only
developers truly understand the inner workings of their code. Following a best practice from
Test-Driven Development (TDD), developers would ideally create tests up front before
implementing code. Developing tests in advance has the added benefit of fleshing out your
design, and especially aids in designing for testability. By thinking about testing up front, youll
take into account and implement facilities to access internal APIs, data structures or other
information that aid in testing.
Thus, the first role of an embedded software verification platform is to assist developers in
creating reusable, automated tests quickly and easily by providing specialized tools and
techniques. For example, the verification platform might enable developers to quickly break
dependencies by simulating missing code with a GUI, simple scripts or C/C++ code. Or perhaps
the verification platform would support recording and playback to automate a series of manual
test operations.
An embedded software verification platform also provides value at this stage by enabling
developers to validate their tests before code is available. For API-level testing, a software
verification platform can execute and verify tests by simulating or modeling APIs through simple
130
EMBEDDED SYSTEMS
scripts, C/C++ code, or a GUI. This provides developers with a very simple, quick means to
execute tests and feed them canned responses to validate them. For example, if code-under-test
depends on the return values of another application interface, the developer can dynamically
mock-up the desired return values his new approach succeeds only if developers and integrators
create and deliver automated tests that are reusable by anyone, and if the tests can be aggregated
and automated in large-scale testing. To do this requires that a common test framework and test
guidelines be used by all software developers, integrators and testers.
The first key is the software verification platform, which serves as the common test framework
that supports, manages and automates tests from all of the developers and integrators. With the
diversity of embedded software components, this means that the test framework should ideally
be flexible enough to support various testing strategies. Depending on the type of embedded
software component, certain approaches may be more suitable. Hard real-time code may
require tests written in native code to be directly built into the target; soft real-time
applications can be exercised remotely from the host, possibly using a scripting language;
network protocols might have internal state machines that should be verified through white-box
techniques; data-centric APIs may require facilities to efficiently enter complex data.
Secondly, the development team must conform to a level of uniformity when it creates tests. For
example, guidelines might require that tests be written to be self-contained, i.e., not dependent on
the preceding execution of other tests. Standard entry and exit criteria would guarantee that tests
enter and leave the target in a consistent, known state, enabling tests to be executed in any
sequence. All tests would leverage the same error handling and recovery mechanisms. Internal
policies and conventions would establish naming conventions, archiving and maintenance
policies, and the standard languages for implementing tests.
131
EMBEDDED SYSTEMS
132
EMBEDDED SYSTEMS
collected
much
earlier
in
the
development
cycle.
Even if this strategy is applied incrementally or selectively to certain development teams, the
impact can be dramatic. A greater volume of defects can be caught and prevented before product
test resulting in shorter cycles and fewer resources required in product test. This, along with
increased visibility and predictability into software health and delivery schedules, will lead to a
higher quality product, on time. These are all tangible benefits that can transform a companys
embedded software engineering into a true competitive advantage.
6.
function is called a software and hardware co design. Successful co design fits really well
into the preferred function. Today it has become a compulsion to blend the software and
hardware design, as the conventional methodologies are not that effective today. All the
items which contain a chip memory and a set of executable instructions or programs in order
to monitor its functioning are known as hardware and software co design.
Focus of co Design
The emphasizes of co design is on the area of system specification, hardware software
portioning, architectural design, and the iteration In between the software and hardware as the
design proceeds to next stage. This task is completed by the hardware and software integration.
133
EMBEDDED SYSTEMS
The new and old integrated circuits are finding their place in the new designs in the form of
entrenched cores in a mixed fashion. Hardware and software co design makes it possible to make
handy devices which can be carried by individuals however for these systems one does not have
to stay in touch with the computer in order to run software applications. The most common
example of hardware and software co design is embedded systems. The objective of the co
design is to combine CPU memory and programs to control physical operations.
A computer system which has been specifically designed to perform different functions,
however which faces real time computing restriction is known as embedded systems. Embedded
systems can be controlled by digital signal processing and micro controllers. When ever you see
software guiding the hardware it is an example of embedded system. Software and hardware co
design is a broader horizon which incorporates all the embedded systems. There are today
unlimited examples of the embedded systems like modern Robot Guitar for tuning the strings.
Embedded systems deal with the complex GUI, which is more like the desktop computers. It is
the rise of embedded systems that we are able to use touch screen devices. The key of embedded
systems is that any hardware on which specific purpose software is fixed or stamped is an
embedded system. Embedded systems have many distinct features like they consume less
electricity. On the contrary the proceeding speed of these systems is also low and the capability
to store data is also low.
Examples of Hardware Co Systems
The applications of the hardware software co design have many applications ranging
from the everyday items to the special purpose machines. The common purpose examples
include television, automobiles, GPS, microwaves, thermostats, network routers, game consoles
and automobiles. Some special purpose examples include ATM machines, kiosks, aircraft,
satellites, sensing, consumer electronics, smart phones, industrial automation, avionics, medical
and IT hardware. The best example of co design technology is multi core processors, I Phone and
PS- 3. Therefore the examples of the hardware and software co design include all the intelligent
devices .these systems can be configured for personalized uses. Let us examine a simple example
of a MP3 player. It has a large memory which is capable of storing unlimited songs. Songs are
stored in digital compressed form. The CPU scampers the program in main memory. The audio
134
EMBEDDED SYSTEMS
present in the form of an audio and raw audio is generated in the form of digital signals. This
information is then displayed on the screen with the help of software working in the memory.
The hardware and software co design method is used for the implementation of the MP3 audio
decoder which is helpful in real time specification of MP3 player. The recent development in this
field can be seen in telecommunications.
QUESTION BANK
2 - MARKS
135
EMBEDDED SYSTEMS
1. Specify the C++ features that suits embedded program. [April/May 2014]
[Ref. Page No. :109]
2.Write short note on software tool for embedded program.[April/May 2014][Ref.
Page No.:111]
3.Discuss in detail with multiprocessor system. [November 2011][Ref. Page
No.:114]
136
EMBEDDED SYSTEMS
1. Specify the C++ features that suits embedded program. [April/May 2014]
[Ref. Page No. :109]
2.Write short note on software tool for embedded program.[April/May 2014]
[Ref. Page No.:111]
3.Discuss in detail with multiprocessor system. [November 2011]
[Ref. Page No.:114]
4.Explain embedded software develop process and tools.(November 2011]
[Ref. Page No.:117]
137
EMBEDDED SYSTEMS
Prepared By :
Mr.P.Karthikeyan,AP/CSE
Mr.B.Thiyagarajan, AP/CSE
Mrs.P.Subha Priya, AP/CSE
Verified by :
Approved by :
UNIT IV
Real Time Operating Systems: Tasking Models, Task States, Services and Transitions Real- Time Scheduling Algorithms: Round-Robin, FIFO, Priority-Based Preemptive
Scheduling - Rate-Monotonic Scheduling - Priority Inversion and Priority Ceiling Deadlocks Process Synchronization IPC - Shared Memory, Memory Locking,
Memory Allocation - Signals Semaphore Flag or mutex as Resource key Message
Queues Mailboxes Pipes Virtual Sockets.
138
EMBEDDED SYSTEMS
UNIT IV
2 MARKS
1. What is an rtos?
RTOS is an OS for Embedded system for response time and event controlled processes.
2. What are rtos basic services?( April-2013)
RTOS Services:
Basic OS functions
Time management
Predictability
Priorities Management
IPC
139
EMBEDDED SYSTEMS
Kernel
140
EMBEDDED SYSTEMS
ISR Functions
Memory Functions
IPC Functions
141
EMBEDDED SYSTEMS
A readily available RTOS package provides the above functions and a lot of time is saved for
coding the same.
11. What are the options in rtos?
There are various options for RTOS. They are as follows:
Own RTOS.
C/OS-II.
In a waterfall model, one supposes that all these phases are consecutive. In practice, this is
never possible. Most developments end up being chaotic, with all the phases being executed
simultaneously. Adopting a pragmatic approach, the methodology used should just be a
framework to guide producing the correct documents, whilst performing appropriate reviews and
audits at the right time.
142
EMBEDDED SYSTEMS
143
EMBEDDED SYSTEMS
Bounded-Buffer Problem
Dining-Philosophers Problem
144
EMBEDDED SYSTEMS
Through preemption
Rollback
Killing Process
145
EMBEDDED SYSTEMS
146
EMBEDDED SYSTEMS
147
EMBEDDED SYSTEMS
Semaphores can be used to deal with the n-process critical section problem. It can be also used to
solve various synchronization problems.
The classic definition of wait
wait (S){
while (S<=0)
;
S--;
}
The classic definition of signal
signal (S){
S++ ;}
33. What is a semaphore?
Semaphores -- software, blocking, OS assistance solution to the mutual exclusion
problem basically a non-negative integer variable that saves the number of wakeup signals sent
so they are not lost if the process is not sleeping another interpretation we will see is that the
semaphore value represents the number of resources available
34. Give the semaphore related functions.(November-2011)
A semaphore enforces mutual exclusion and controls access to the process critical
sections. Only one process at a time can call the function fn.
SR Program: A Semaphore Prevents the Race Condition.
SR Program: A Semaphore Prevents Another Race Condition.
148
EMBEDDED SYSTEMS
35. When the error will occur when we use the semaphore?
i. When the process interchanges the order in which the wait and signal operations on the
semaphore mutex.
ii. When a process replaces a signal (mutex) with wait (mutex).
iii. When a process omits the wait (mutex), or the signal (mutex), or both.
36. Differentiate counting semaphore and binary semaphore.
Binary Semaphore:
The general-purpose binary semaphore is capable of addressing the requirements of both
forms of task coordination: mutual exclusion and synchronization.
A binary semaphore can be viewed as a flag that is available (full) or unavailable
(empty).
Counting semaphores are another means to implement task synchronization and mutual
exclusion.
Counting Semaphore:
The counting semaphore works like the binary semaphore except that it keeps track of the
number of times a semaphore is given. Every time a semaphore is given, the count is
incremented; every time a semaphore is taken, the count is decremented. When the count reaches
zero, a task that tries to take the semaphore is blocked. As with the binary semaphore, if a
semaphore is given and a task is blocked, it becomes unblocked. However, unlike the binary
semaphore, if a semaphore is given and no tasks are blocked, then the count is incremented. This
means that a semaphore that is given twice can be taken twice without blocking.
149
EMBEDDED SYSTEMS
150
EMBEDDED SYSTEMS
151
EMBEDDED SYSTEMS
CPU utilization
Throughput
Turnaround time
Waiting time
Response time
152
EMBEDDED SYSTEMS
153
EMBEDDED SYSTEMS
The ready tasks are dispatched to execution in the order determined by their priority
154
EMBEDDED SYSTEMS
In real-time systems the priority of a task is derived from its temporal requirements, not
its importance to the correct functioning of the system or its integrity
11 MARKS
155
EMBEDDED SYSTEMS
We should be able to implement SSAD without knowing the RTOS used. However,
commercial RTOS vendors have made certain choices and you just have to work with the
possibilities and limitations of products actually available.
All products are different in terms of the choices made. This means that an SSAD will
largely depend on the RTOS chosen. This also means that porting the application to another
RTOS environment is just an illusion, even if the RTOS is POSIX compliant.
Scheduling Policies:
The scheduler is one of the basic parts of an OS. It has the function of switching from one
task, thread or process to another. As this activity constitutes overhead, it should be done as
quickly as possible. To understand scheduling, it has to be understood that each task has different
states. At least 3 states are needed to allow an OS to run smoothly: running, blocked and ready.
A task is running if it is using a processor to execute the task code. If it has to wait for
another system resource, then the task is blocked (waiting for I/O, memory, etc.) once the
missing resources that the task wants to run have been allocated to it. As different tasks probably
want to run simultaneously and only as many tasks can run as there are available processors,
what is needed is a waiting for run queue. A task in this queue is considered ready. The queue
is called the ready list. In a symmetrical multiprocessor system, there is only one queue for all
the processors. In other architectures, you have one queue per processor.
If there is more than one task in the ready queue, you need a decision-making algorithm
determining which task can use the processor first. This is also called the scheduling policy.
There are probably as many policies as there are engineers inventing them. Therefore we
have to limit ourselves to the ones that are actually of use in RT systems.
In all RT systems, a deadline-driven scheduling policy is required. However this is still
under development and is not currently commercially available.
A pre-emptive priority scheduling policy is a minimum requirement. You cannot develop
a hard predictable system without it. If you apply RMS, then each task should have a different
priority level.
156
EMBEDDED SYSTEMS
In more complex systems, only part of the system is hard real-time, with other parts being
soft or non-real time. The soft real-time parts should be designed like the hard RT part, with the
fact that not all the needed processor power will always be available being taken into account.
The same scheduling policy applies. In the non-RT part, a more general purpose OS (GPOS)
approach may be desirable. In GPOS systems, the philosophy is maximum usage of all system
resources. This philosophy is at odds with the RT requirement of being predictable. If you want
to give each task an equal share of the processor, a round robin scheme is more appropriate. The
non real-time part of a complex system should therefore be capable of using an RRS. Most
RTOSs implement this when you put more than one task on the same priority level. Other
RTOSs have an RRS explicitly defined for certain priority ranges.
Conclusion: an RTOS should always support pre-emptive priority scheduling. For
complex applications, where for some parts of the system a more GPOS-oriented philosophy is
needed, RRS or some other mechanisms might be useful.
2. What is a Task? Explain the Various Task States?
Tasks
Tasks = Code + Data + State (context)
Task State is stored in a Task Control Block (TCB) when the task is not running on the processor
Task states
Executing: running on the CPU
Ready: could run but another one is using the CPU
Blocked: waits for something (I/O, signal, resource, etc.)
157
EMBEDDED SYSTEMS
Release (arrival) time - r(i,j): The release time of the jth instance of the i-th task
Phase: (i): The release time of the first instance of the i-th task.
Response time: Time span between task activation and its completion
Absolute deadline - d(i,j): The instant by which the jth instance of the i-th task must
complete
Relative deadline D(i): The maximum allowable response time for the task
Period - p(i): The minimum length of intervals between the release times of consecutive
tasks.
158
EMBEDDED SYSTEMS
Execution time e(i): The (maximum) amount of time required to complete the
execution of the i-th task when it executes alone and has all the resources it requires.
3. Explain Round Robin Scheduling Briefly And What Is FIFO? Explain Its Working In
Detail?
The ROUND ROBIN SCHEDULING ALGORITHM is designed especially for the time
sharing systems. A small unit of time called a time quantum is defined. A time quantum is
generally from ten to hundred milli seconds. The ready queue is treated as a circular queue. The
CPU scheduler goes around the ready queue, allocating the CPU to each process for a time
interval of up to one time quantum.
159
EMBEDDED SYSTEMS
To implement the round robin scheduling, we keep the ready queue as a FIFO queue of
the processes. New processes are added to the tail of the ready queue. The CPU scheduler picks
the first process from the ready queue, sets a timer to interrupt after one time quantum in a row.
If a process CPU burst exceeds one time quantum, that process is preempted and is put back in
the ready queue. The RR scheduling algorithm is preemptive
//Round Robin calls for the distribution of the processing time equitably among all processes
requesting the processor. Run process for one time slice, then move to back of queue. Each
process gets equal share of the CPU. Most systems use some variant of this.
FIFO
This is a Non-Preemptive scheduling algorithm. FIFO strategy assigns priority to processes in the
order in which they request the processor. The process that requests the CPU first is allocated the
CPU first. When a process comes in, add its PCB to the tail of ready queue. When running
process terminates, dequeue the process (PCB) at head of ready queue and run it.
Consider the example with P1=24, P2=3, P3=3
160
EMBEDDED SYSTEMS
Comments: While the FIFO algorithm is easy to implement, it ignores the service time request
and all other criteria that may influence the performance with respect to turnaround or waiting
time.
Problem: One Process can monopolize CPU
Solution: Limit the amount of time a process can run without a context switch. This time is
called a time slice.
4. What is Preemptive Priority Based Scheduling and Explain Rate Monotonic Scheduling
in Detail? (April-2013)
With a preemptive priority based scheduler, each task has a priority and the kernel
insures that the CPU is allocated to the highest priority task that is ready to run. This scheduling
method is preemptive in that if a task that has a higher priority than the current task becomes
ready to run, the kernel immediately saves the current tasks's context and switches to the context
of the higher priority task.
The Wind kernel has 256 priority levels(0-255). Priority 0 is the highest and priority 255
is the lowest. Tasks are assigned a priority when created; however, while executing, a task can
change its priority using taskPrioritySet().
Example: Preemptive Priority Based Scheduling
One of the arguments to taskSpawn() is the priority at which the task is to execute:
id = taskSpawn(name, priority, options, stacksize, function, arg1,.. , arg10);
By varying the priority(0-255) of the task spawned, you can affect the priority of the task.
Priority 0 is the highest and priority 255 is the lowest.The Note the priority of a task is relative to
the priorities of other tasks. In other words, the task priority number itself has no particular
significance by itself.
In addition a task's priority can be changed after its spawned using the following routine:
161
EMBEDDED SYSTEMS
In the example below, there are three tasks with different priorities(HIGH,MID,LOW). The
result of running the program is that the task with the highest priority, "taskThree" will run to
completion first, followed by the next highest priority task, "taskTwo", and the finally the task
with the lowest priority which is "taskOne."
Rate Monotonic Scheduling
The Rate Monotonic Scheduling Algorithm (RMS) is important to real-time systems
designers because it allows one to guarantee that a set of tasks is schedulable. A set of tasks is
said to be schedulable if all of the tasks can meet their deadlines. RMS provides a set of rules
which can be used to perform a guaranteed schedulability analysis for a task set. This analysis
determines whether a task set is schedulable under worst-case conditions and emphasizes the
predictability of the system's behavior. It has been proven that:
RMS is an optimal static priority algorithm for scheduling independent, preemptible,
periodic tasks on a single processor.
RMS is optimal in the sense that if a set of tasks can be scheduled by any static priority
algorithm, then RMS will be able to schedule that task set. RMS bases it schedulability analysis
on the processor utilization level below which all deadlines can be met.
RMS calls for the static assignment of task priorities based upon their period. The shorter
a task's period, the higher its priority. For example, a task with a 1 millisecond period has higher
priority than a task with a 100 millisecond period. If two tasks have the same period, then RMS
does not distinguish between the tasks. However, RTEMS specifies that when given tasks of
equal priority, the task which has been ready longest will execute first. RMS's priority
assignment scheme does not provide one with exact numeric values for task priorities. For
example, consider the following task set and priority assignments:
TASK
PERIOD(in milliseconds)
PRIORITY
100
Low
50
Medium
162
EMBEDDED SYSTEMS
50
Medium
25
High
RMS only calls for task 1 to have the lowest priority, task 4 to have the highest priority,
and tasks 2 and 3 to have an equal priority between that of tasks 1 and 4. The actual RTEMS
priorities assigned to the tasks must only adhere to those guidelines.
Many applications have tasks with both hard and soft deadlines. The tasks with hard
deadlines are typically referred to as the critical task set, with the soft deadline tasks being the
non-critical task set. The critical task set can be scheduled using RMS, with the non-critical tasks
not executing under transient overload, by simply assigning priorities such that the lowest
priority critical task (i.e. longest period) has a higher priority than the highest priority non-critical
task. Although RMS may be used to assign priorities to the non-critical tasks, it is not necessary.
In this instance, schedulability is only guaranteed for the critical task set.
5. What Is Priority Inversions? (November-2011)
Priority inversion is a problematic scenario in scheduling when a higher priority task is
indirectly preempted by a lower priority task effectively "inverting" the relative priorities of the
two tasks.
This violates the priority model that high priority tasks can only be prevented from
running by higher priority tasks and briefly by low priority tasks which will quickly complete
their use of a resource shared by the high and low priority tasks.
Example of a priority inversion
Consider there is a task L, with low priority. This task requires resource R. Consider that
L is running and it acquires resource R. Now, there is another task H, with high priority. This
task also requires resource R. Consider H starts after L has acquired resource R. Now H has to
wait until L relinquishes resource R.
163
EMBEDDED SYSTEMS
Everything works as expected up to this point, but problems arise when a new task M
starts with medium priority during this time. ` Since R is still in use (by L), H cannot run. Since
M is the highest priority unblocked task, it will be scheduled before L. Since L has been
preempted by M, L cannot relinquish R. So M will run till it is finished, then L will run - at least
up to a point where it can relinquish R - and then H will run. Thus, in above scenario, a task with
medium priority ran before a task with high priority, effectively giving us a priority inversion.
In some cases, priority inversion can occur without causing immediate harmthe
delayed execution of the high priority task goes unnoticed, and eventually the low priority task
releases the shared resource. However, there are also many situations in which priority inversion
can cause serious problems. If the high priority task is left starved of the resources, it might lead
to a system malfunction or the triggering of pre-defined corrective measures, such as a watch dog
timer resetting the entire system.
Priority inversion can also reduce the perceived performance of the system. Low priority
tasks usually have a low priority because it is not important for them to finish promptly (for
example, they might be a batch job or another non-interactive activity). Similarly, a high priority
task has a high priority because it is more likely to be subject to strict time constraintsit may
be providing data to an interactive user, or acting subject to real time response guarantees.
Because priority inversion results in the execution of the low priority task blocking the high
priority task, it can lead to reduced system responsiveness, or even the violation of response time
guarantees.
A similar problem called deadline interchange can occur within earliest deadline first
scheduling (EDF).
Solutions
The existence of this problem has been known since the 1970s, but there is no fool-proof
method to predict the situation. There are however many existing solutions, of which the most
common ones are:
Disabling all interrupts to protect critical sections
164
EMBEDDED SYSTEMS
When disabled interrupts are used to prevent priority inversion, there are only two
priorities: preemptible, and interrupts disabled. With no third priority, inversion is
impossible. Since there's only one piece of lock data (the interrupt-enable bit),
misordering locking is impossible, and so deadlocks cannot occur. Since the critical
regions always run to completion, hangs do not occur. Note that this only works if all
interrupts are disabled. If only a particular hardware device's interrupt is disabled, priority
inversion is reintroduced by the hardware's prioritization of interrupts. A simple
variation, "single shared-flag locking" is used on some systems with multiple CPUs. This
scheme provides a single flag in shared memory that is used by all CPUs to lock all interprocessor critical sections with a busy-wait. Interprocessor communications are
expensive and slow on most multiple CPU systems. Therefore, most such systems are
designed to minimize shared resources. As a result, this scheme actually works well on
many practical systems. These methods are widely used in simple embedded systems,
where they are prized for their reliability, simplicity and low resource use. These schemes
also require clever programming to keep the critical sections very brief, under 100
microseconds in practical systems. Many software engineers consider them impractical in
general-purpose computers.
A priority ceiling
With priority ceilings, the shared mutex process (that runs the operating system
code) has a characteristic (high) priority of its own, which is assigned to the task locking
the mutex. This works well, provided the other high priority task(s) that tries to access the
mutex does not have a priority higher than the ceiling priority.
Priority inheritance
Under the policy of priority inheritance, whenever a high priority task has to wait
for some resource shared with an executing low priority task, the low priority task is
temporarily assigned the priority of the highest waiting priority task for the duration of its
own use of the shared resource, thus keeping medium priority tasks from pre-empting the
(originally) low priority task, and thereby effecting the waiting high priority task as well.
Once the resource is released, the low priority task continues at its original priority level.
165
EMBEDDED SYSTEMS
166
EMBEDDED SYSTEMS
First Fit
First fit just starts at the front of the list of free storage and grabs the first block which is
"big enough". If it is "too big" it "splits" the block, returning you a pointer to the front part of the
block and returning the tail of the block back to the free pool.
First-fit has lousy performance. It requires that you may have to skip over blocks that are
too small, thus wasting time, and it tends to split big blocks, thus increasing memory
fragmentation. The original C allocators were not only first-fit, but they had to scan the entire
heap from start to finish, skipping over the already-allocated blocks. In a modern machine,
where you might have a gigabyte of allocation in tens of thousands of blocks, this is guaranteed
to maximize your page faulting behavior. So it has truly lousy allocation performance and
fragments memory badly. It is considered a truly losing algorithm.
Best Fit
"Best fit" tries to find a block that is "just right". The problem is that this requires
keeping your free list in sorted order, so you can see if there is a really good fit, but you still have
to skip over all the free blocks that are too small. As memory fragments, you get more and more
small blocks that interfere with allocation performance, and deallocation performance requires
that you do the insertion properly in the list. So again, this allocator tends to have truly lousy
performance.
Quick Fit
The idea here is that you keep a "cache" of free blocks of storage rooted in their sizes.
Sizes at this level are always multiples of some basic allocation granularities, such as DWORD.
Like most algorithms that work well, it is based on patterns of observed behavior. The L1 and
L2 caches rely on what is called "locality of reference" to in effect prefect and cache data that is
very likely to be used in the near future. LRU page replacement is based on the fact that a page
which hasn't been used in a long time is unlikely to be used in the near future. Working set is
based on the fact that, like caches, the pages you used most recently are likely to be the pages
you are most likely to use in the future. QuickFit is based on the observed premise that most
167
EMBEDDED SYSTEMS
programs allocate only a small number of discrete sizes of objects. You might allocate and free
objects of type A hundreds of times a second, but you will actually be doing this a lot.
QuickFit relies on lazy coalescing. If you free a block of size n, you are very likely, in the near
future, to allocate a block of size n, because what you really did was free an object of type A
(sizeof(A) == n) and you are therefore fairly likely in the near future to allocate a new object of
type A. So instead of returning the block to the general heap, and possibly coalescing it with
nearby blocks, you just hang onto it, keeping it in a list of blocks of size n. The next time you
allocate an object of size n, the allocator looks on the free list[n] to see if there are any blocks
laying around to be reallocated, and if one is, your allocation is essentially instantaneous. Only
if the list is empty do you revert to one of the slower algorithms.
In QuickFit, coalescing is done before you decide to ask the operating system for more storage.
First you run a coalesce pass, and then see if you now have a big enough block. If you don't,
then you get more space from the system.
7. Explain The Concept Deadlock in Detail?
A set of processes is deadlocked if each process in the set is waiting for an event that only
another process in the set can cause (including itself).
Waiting for an event could be:
Hold and wait: processes request resources incrementally, and hold on to what they've
got.
168
EMBEDDED SYSTEMS
Circular wait: circular chain of waiting, in which each process is waiting for a resource
held by the next process in the chain.
ignore the problem altogether ie. ostrich algorithm it may occur very infrequently, cost of
detection/prevention etc may not be worth it.
Deadlock Prevention
Difference from avoidance is that here, the system itself is build in such a way that there are no
deadlocks.
Make sure atleast one of the 4 deadlock conditions is never satisfied.
This may however be even more conservative than deadlock avoidance strategy.
Attacking preemption
o
never grant exclusive access. but this may not be possible for several resources.
make all the requests at the beginning. All or nothing policy. If you feel, retry. eg.
2-phase locking
Make sure that the requests are issued in the correct order so that there are no
cycles
169
EMBEDDED SYSTEMS
present
in
the
resource
graph.
To avoid deadlocks, we try to make only those transitions that will take you from one
safe state to another. We avoid transitions to unsafe state (a state that is not deadlocked,
and is not safe)
eg.
Total # of instances of resource = 12
(Max, Allocated, Still Needs)
P0 (10, 5, 5)
P1 (4, 2, 2)
P2 (9, 2, 7)
Free = 3
170
EMBEDDED SYSTEMS
- Safe
while () {
Temp[j]=Available[j] for all j
Find an i such that
a) Done[i] = False
b) Still_Needs[i,j] <= Temp[j]
if so {
Temp[j] += Allocated[i,j] for all j
Done[i] = TRUE}
}
else if Done[i] = TRUE for all i then state is safe
else state is unsafe
}
Detection and Recovery
Is there a deadlock currently?
171
EMBEDDED SYSTEMS
check if there is a cycle in the resource graph. for each node N in the graph do
DFS (depth first search) of the graph with N as the root In the DFS if you come
back to a node already traversed, then there is a cycle. }
m resources, n processes
Invariant = Sum(Cij) + Aj = Ej
Overview
Check
of
matrix,
deadlock
and
find
detection
row
such
algorithm,
at
Ri
<
A.
If such a process is found, add Ci to A and remove process i from the system.
Keep doing this till either you have removed all processes, or you cannot remove
any
other
process.
Whatever
is
remaining
is
deadlocked.
Basic idea, is that there is atleast 1 execution which will undeadlock the system
Recovery
172
through preemption
rollback
Take away the resource from the process currently having it.
EMBEDDED SYSTEMS
Later on, you can restart this process from a check pointed state where it
may need to reacquire the resource.
killing processes
where possible, kill a process that can be rerun from the beginning without
illeffects
Critical-Section Problem
Producer-Consumer Problem:
Producer Process: produces information
Consumer Process: consumes the information
173
EMBEDDED SYSTEMS
2. Progress - If no process is executing in its critical section and there exist some processes
that wish to enter their critical section, then the selection of the processes that will enter
the critical section next cannot be postponed indefinitely.
3. Bounded Waiting - A bound must exist on the number of times that other processes are
allowed to enter their critical sections after a process has made a request to enter its
critical section and before that request is granted.
Classical Problems of Synchronization
Bounded-Buffer Problem
Dining-Philosophers Problem
Bounded-Buffer Problem
174
EMBEDDED SYSTEMS
Readers-Writers Problem
Readers only read the data set; they do not perform any updates
Problem allow multiple readers to read at the same time. Only one single writer can
access the shared data at the same time.
Shared Data
175
Data set
EMBEDDED SYSTEMS
Dining-Philosophers Problem
Shared data
While (true) {
176
EMBEDDED SYSTEMS
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
}
9. Explain Inter Process Communication Briefly?
Inter-process communication (IPC) is a set of interfaces, which is usually programmed in
other for a programmer to communicate between a series of processes. This allows the running
of programs concurrently in an operating system.
There are quite a number of methods used in inter-process communications. They are:
Pipes: This allows the flow of data in one direction only. Data from the output is usually
buffered until the input process receives it which must have a common origin.
Named Pipes: This is a pipe with a specific name. It can be used in processes that do not
have a shared common process origin. Example is FIFO where the data is written to a pipe is
first named.
Message queuing: This allows messages to be passed between messages using either a
single queue or several message queues. This is managed by the system kernel. These messages
are co-ordinated using an application program interface (API)
Semaphores: This is used in solving problems associated with synchronization and
avoiding race conditions. They are integers values which are greater than or equal to zero
177
EMBEDDED SYSTEMS
Shared Memory: This allows the interchange of data through a defined area of memory.
Semaphore value has to be obtained before data can get access to shared memory.
Sockets: This method is mostly used to communicate over a network, between a client
and a server. It allows for a standard connection which I computer and operating system
independent.
Mutual exclusion processes has a shortcoming which is the fact that it wastes the
processor time.
There are primitive interprocesses that block instead of wasting the processor time.
Some of these are:
Sleep and Wakeup
SLEEP is a system call that causes the caller to block, that is, be suspended until another
process wakes it up. The WAKEUP call has one parameter, the process to be awakened.
The Producer-Consumer Problem
In this case, two processes share a common, fixed-size buffer. One of the processes puts
information into the buffer, and the other one, the consumer, takes it out. This could be easy
with 3 or more processes in which one wakeup waiting bit is insufficient, another patch could be
made, and a second wakeup waiting bit is added of 8 or 32 but the problem of race condition will
still be there.
Events Counter
This involves programming a program without requiring mutual exclusion. Event
counters value can only increase and never decrease. There are three operations defined on an
event counter for example, E:
1.
178
EMBEDDED SYSTEMS
2.
3.
of items that the producer discussed above has put into the buffer since the program started
running. The other one out, counts the cumulative number of items that the consumer has
removed from the buffer so far. Therefore, it is clear that in must be greater than or equal to out,
but not more that the size of the buffer. This is method that works with pipes discussed above.
Monitors
This is about the best way of achieving mutual exclusion.
A Monitor is a collection of procedures, variables, and data structures that are grouped
together in a special kind of module or package. The monitor uses the wait and signal. The
"WAIT" is to indicate to the other process that the buffer is full and so causes the calling process
to block and allows the process that was earlier prohibited to enter the process at this point.
"SIGNAL" will allow the other process to be awakened by the process that entered during the
"WAIT".
10. What is the Concept behind Shared Memory?
Shared memory is memory that is accessible to a number of processes. By several orders
of magnitude, it is the quickest way of sharing information among a set of processes. Keep in
mind that shared memory is available on all operating systems. Only the calls will be different.
Shared memory is persistent. It does not go away when no program is referencing it. This can
be a good thing, but it can tie up system resources.
shmget system call. Gets or creates a shared memory segment. The call has the following
format:
#include <sys/types.h>
179
EMBEDDED SYSTEMS
#include <sys/ipc.h>
#include <sys/shm.h>
int shmget ( key_t key, size_t size, int shmflg)
Returns shared memory ID if successful and -1 if error.
Key Returns a unique key if successful and (key_t) -1 if it fails. It fails if the path does
not exist.
size is used when creating the shared memory segment to specify the size. If the shared
memory segment exists, it may be 0 or used to specify the minimum size of the shared
memory. The size of the shared memory you request is less than or equal to the amount
you actually get. That is, due to the fact that shared memory is allocated in pages, so, the
actual amount of shared memory allocated may be bigger than the size requested.
shmflg are flags specifying options for this command. Right-most 9 bits are
permissions. (Same bits as in open) SHM_R and SHM_W for owner and these shifted 3
bits to the right for group and these shifted 6 bits to the right for other. Also have
IPC_CREAT and IPC_EXCL bits. These are similar to O_CREAT and O_EXCL for the
file system. There are additional flags that are not as general. For example, on Solaris,
there is the ability to make the shared memory dynamically resizable.
shmat system call. Attaches the shared memory segment to our process. This is separate from
shmget because there is a limit on the number of shared memory segments to which we can
attach. This is a system-imposed limit. (Let's try and figure this out when I do an example.) So,
if you are dealing with a large number of shared memory segments, a good strategy would be to
get the IDs for all that we need and then attach only to those shared memory segments that we
are actively using. We can detach from a shared memory segment.
The system call shmat is defined as follows:
#include <sys/types.h>
180
EMBEDDED SYSTEMS
#include <sys/ipc.h>
#include <sys/shm.h>
void *shmat ( int shmid, const void *shmaddr, int shmflg );
Returns a pointer to the shared memory segment or -1 if error.
shmid is the shared memory ID
shmaddr should be NULL. This argument can allow you to specify the address to
associate with the shared memory. For modern computers, it is hard to find a reason for
using this argument. Do no specify an address unless you have a very good reason.
shmflg are flags for this call. The only one that we will care about is SHM_RDONLY.
This makes the shared memory segment read only. This is like opening a file to be read
only. So, if we don't want read only shared memory, this argument will be set to zero.
shmdt detaches a shared memory segment from a process. There is a limit to how many
shared memory segments you may attach to. shmdt is used so that another segment may
be attached. The format of this call is as follows:
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
int shmdt (const void *shmaddr );
shmaddr is the address of the shared memory segment.
Returns 0 if successful and -1 if fails.
shmctl performs a bunch of utility functions on shared memory. Its description follows:
181
EMBEDDED SYSTEMS
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
int shmctl ( int shmid, int cmd, struct shmid_ds *buf)
Returns 0 if successful and -1 if fails.
cmd is the command that we wish to have executed.
IPC_RMID removes the shared memory segment when no one is using it.
IPC_STAT gets data associated with shared memory segment into buf
IPC_SET allows 3 fields in buf to be changed.
buf is used by certain commands. The most often used command is IPC_RMID.
182
EMBEDDED SYSTEMS
Memory locking applies to a process's address space. Only the pages mapped into a
process's address space can be locked into memory. When the process exits, pages are removed
from the address space and the locks are removed.
Two functions, mlock and mlockall, are used to lock memory. The mlock function allows
the calling process to lock a selected region of address space. The mlockall function causes all of
a process's address space to be locked. Locked memory remains locked until either the process
exits or the application calls the corresponding munlock or munlockall function.
Memory locks are not inherited across a fork and all memory locks associated with a
process are unlocked on a call to the exec function or when the process terminates.
For most realtime applications the following control flow minimizes program complexity and
achieves greater determinism by locking the entire address into memory.
1. Perform nonrealtime tasks, such as opening files or allocating memory
2. Lock the address space of the process calling mlockall function
3. Perform realtime tasks
4. Release resources and exit
The memory-locking functions are as follows:
FUNCTION
DESCRIPTION
mlock
mlockall
munlock
munlockall
183
EMBEDDED SYSTEMS
The mlock function locks all pages defined by the range addr to addr+len-1 (inclusive).
The area locked is the same as if the len argument were rounded up to a multiple of the next page
184
EMBEDDED SYSTEMS
size before decrementing by 1. The address must be on a page boundary and all pages mapped by
the specified range are locked. Therefore, you must determine how far the return address is from
a page boundary and align it before making a call to the mlock function.
Use the sysconf(_SC_PAGE_SIZE) function to determine the page size. The size of a
page can vary from system to system. To ensure portability, call the sysconf function as part of
your application or profile when writing applications that use the memory-locking functions. The
sys/mman.h header file defines the maximum amount of memory that can be locked. Use the
getrlimit function to determine the amount of total memory.
Exercise caution when you lock memory; if your processes require a large amount of
memory and your application locks memory as it executes, your application may take resources
away from other processes. In addition, you could attempt to lock more virtual pages than can be
contained in physical memory.
Locked space is automatically unlocked when the process exits, but you can also
explicitly unlock space. The munlock function unlocks the specified address range regardless of
the number of times the mlock function was called. In other words, you can lock address ranges
over multiple calls to the mlock function, but can remove the locks with a single call to the
munlock function. Space locked with a call to the mlock function must be unlocked with a
corresponding call to the munlock function.
12. What are Signals Related IPC Functions?
One way for messaging is to use an OS function signal ( ). It is provided in Unix, Linux
and several RTOs. Unix and Linux OSes use signals profusely and have 31 different types of
signals for the various events. The task or process sending the signal uses a function signal ( )
having an integer number n in the argument. A signal is function, which executes a software
interrupt instruction INT n or SWI n.
A signal provides the shortest communication. The signed ( ) sends a output n for a
process, which enables the OS to unmask a signal mask of a process or task as per the n. The task
is called signal handler and has coding similar to the ones in an ISR. The handler runs in a way
185
EMBEDDED SYSTEMS
similar to a highest priority ISR. An ISR runs on an hardware interrupt provided that the
interrupt is not masked. The handler runs on the signal provided that the signal is not masked.
The signal ( ) forces the OS to first run a signaling process or task called signal handler.
When there is return from the signaled or forced task or process, the process, which sent the
signal, runs the codes as happens on a return from an ISR. A signal mask is the software
equivalent of the flag at a register that sets on masking hardware interrupt. Unless masked by a
signal masked, the signal allows the execution of an ISR.
An integer number (for example n) represents each signal and that number associates a
function (or process or task) signal handler, an equivalent of the ISR. The signal handler has a
function called whenever a process communicates that number.
A signal handler is not called by a code. When the signal is sent from the process, OS
interrupts the process execution and calls the function for signal handling. On return from the
signal hander, the process continues as before.
For example, signal (5). The signal mask of a signal handler 5 is reset. The signal handler
and connect function associate the number 5. The function represented by number 5 is forced run
by the signal handler.
An advantage of using it is that unlike semaphores it takes the shortest possible CPU time
to force a handler to run. The signals are the interrupts that can be used as the IPC function of
synchronizing.
A signal is unlike the semaphore. The semaphore has use as a token or resources key to
let another task process block, or which locks a resource to a particular task process for a given
section of the codes. A signal is just an interrupt that is shared and used by another interruptservicing process. A signal raised by one process forces another process (signal handler) to
interrupt and catch that signal in case the signal is not masked (use of that signal handler is not
disabled). Signals are to be handler only for forcing the run is very high priority processes as it
may disrupt the usual schedule and priority inheritance mechanism. It may also cause reentrancy
problems.
186
EMBEDDED SYSTEMS
Semaphore Flag
The OS system for semaphore as notice or token for an event occurrence.
Semaphore facilitates IPC for notifying (through a scheduler) a waiting task section
change to the running state upon event at presently running code section at an ISR or
task. A semaphore as binary semaphore is a token or resources key. The OS also provides
for mutex access to a set of codes in a task (or thread or process). The use of mutex is
such that the priority inversion problem is not solved in some OSes while it is solved in
other OSes. The OS also provides for counting semaphores. The OS may provide for
POSIX standard P and V semaphores which can be used for notifying event occurrence
or as mutex or for counting. The timeout can be defined in the argument with wait
187
EMBEDDED SYSTEMS
function for the semaphore IPC. The error pointer can also be defined in the arguments
for semaphore IPC function.
The following are the functions, which are generally provided in an OS, for example,
COS-II for the semaphores.
1. OSSemCreate, a semaphore function to create the semaphore in an event control
block (ECB). Initialize it with an initial value.
2. OSSemPost, a function which sends the semaphore notification to ECB and it
value increments on event occurrence (used in ISRs as well as tasks).
3. OSSemPend, a function, which waits the semaphore from an event, and its value
decrements on taking note of that event occurrence (used in tasks not in ISRs).
4. OSSemAccept, a function, which reads and returns the present semaphore value
and if it shows occurrence of an event (by non-zero value) then it takes note of
that and decrements that value (no wait; used in ISRs as well as tasks).
5. OSSemQuery, a function, which queries the semaphore for an event occurrence or
non-occurrence by reading its value and returns the present semaphore value, and
returns pointer to the data structure OSSemdata. The semaphore value does not
decrease. The OSSemData points to the present value and table of the tasks
waiting for the semaphore (used in tasks).
Mutex as Resource Key
An OS, using a mutex blocks a critical section in a task on taking the mutex by another
tasks critical section other task unlocks on releasing the mutex. The mutex wait by unlocking
task can be for a specified timeout.
There is a function in kernel called lock ( ). It locks a process to be resources till that process
executes unlock ( ). A wait loop creates and when wait is over the other process waiting for the
lock starts. Use of lock ( ) and unlock ( ) involves litte overhead compared to uses of
OSSemPend ( ) and OSSenPost ( ) when using a mutex. Overhead means number of operations
needed for blocking one process and starting another. However, a resource of high priority
should not lock the other processes by blocking an already running task in the following
188
EMBEDDED SYSTEMS
situation. Suppose a task is running and a little is left for its completion. The running time left for
it is less compared with the time that would be taken in blocking it and context switching. There
is an innovative concept of spin locking in certain OS schedulers. A spin lock is a powerful tool
in the situation described before. The scheduler locking process for a task I waits in a loop to
cause the blocking of the running task first for a time interval t, then for (t-t), then (t-2t) and so
on. When this time interval spin-downs to 0, the task that requested the lock of the processor
now unlocks the running task I and blocks it from further running. The request is now granted to
task J to unblock and start running provided that task is of higher priority. A spin lock does not
let a running task to be blocked instantly, but first successively tries with or without decreasing
the trial periods before finally blocking a task. A spin-lock obviates need of context-switching by
pre-emption and use of mutex function-calls to OS.
14. Explain Message Queue in Detail?
Some OSes do not distinguish, or make little distinction, between the use of queues, pipes
and mailboxes during the message communication among processes, while other OSes regard the
use of queues as different.
A message queue is an IPC with the following features.
1. An OS provides for inserting and deleting the message pointers or messages.
2. Each queue for the message or message-pointers needs initialization (creation) before
using functions in kernel for the queue.
3. Each created queue has an ID.
4. Each queue has a user-definable size (upper limits for number of bytes).
5. When an OS call is to insert a message into the queue, the bytes are as per the pointed
number of bytes. For example, for an integer or float variables as pointer, there will be 4
bytes inserted per call. If the pointer is for an array of eight integers, then 32bytes will be
inserted into the queue. When a message-pointer is inserted into queue, the 4 bytes
inserts, assuming 32-bit addresses.
6. When a queue becomes full, there is error handling function to handle that.
The OS functions for a queue, for example, in COS-II, can be as follows:
189
EMBEDDED SYSTEMS
190
EMBEDDED SYSTEMS
A mobile phone LCD display task is an example that uses the message mailboxes as an
IPC. In the mailbox, when the time and data message from a clock-process arrives, the time is
displayed at side corner on top line. When the message from another task to display a phone
number, it is displayed the number at middle at a line. When the message from another task to
display the signal strength at antenna, it is displayed at the vertical bar on the left.
Another example of using a mailbox is the mailbox for an error-handling task, which
handles the different error logins from other tasks.
The following may be the provisions at an OS for IPC functions when using the mailbox.
1. A task may put into mailbox only a pointer to the message-block or number of message
bytes as per the OS provisioning.
2. There are three types of the mailbox provisions.
A queue may be assumed a special case of a mailbox with provision for multiple messages or
message pointers. An Os can provide for queue from which a read (deletion) can be on a FIFO
basic or alternatively an OS can provide for the multiple mailbox messages with each message
having a priority parameter. The read (deletion) can then only be on priority basic in case
mailbox messages has multiple messages with priority assigned to high priority ones. Even if the
messages are inserted in a different priority, the deletion is as per the assigned priority parameter.
An OS may provision for mailbox and queue separately. A mailbox will permit one message
pointer per box and the queue will permit multiple messages or messages pointers. COS-II
RTOS is an example of such an OS.
The RTOS functions for mailbox for the use by the tasks can be the following:
1. OSMBoxcreate creates a box and initializes the mailbox contents with an NULL pointer.
2. OSMBoxPost sends (writes) a message to the box.
3. OSMBoxWait (pend) waits for a mailbox message, which is read when received.
4. OSMBoxAccept reads the current message pointer after checking the presence yes or no
(no wait).
5. OSMBoxQuery queries the mailbox when read and not needed later.
191
EMBEDDED SYSTEMS
An ISR can post (but not wait) into the mailbox of a task.
16. What is Pipes? How it is used in Real Time Operating System?
The OS pipe functions are unlike message queue functions. The difference is that pipe
functions are similar to the ones used for devices such as file.
A message-pipe is a device for inserting (writing) and deleting from the between two
given interconnected tasks or two sets of tasks. Writing and reading from a pipe is like using
a C command fwrite with a file name to write into a named file, and fread with a file name to
read from a named file. Pipes are also like Java PipeInputOutputStreams.
1. One task using the function fwrite in a sets of tasks, can insert (write) to pipe at the
back pointer address, *pBACK.
2. Another task using the function fread in a set of tasks can delete (read) from a pipe at
the front pointer address, *pFRONT.
3. In a pipe there may be no fixed number of bytes per message but there is end-pointer.
A pipe can therefore be inserted limited of bytes and have a variable number of bytes
per messages between the initial and final pointers.
4. Pipe is unidirectional. One thread or task inserts into it and the other one deletes from
it.
An example of the need for messaging and thus for IPC using a pipe is a network stack.
The OS functions for pipe are the following:
i.
ii.
Open ( ) for opening the device to enable its use from beginning of its
allocated buffer, its use is with options and restrictions (or permissions)
defined at the time of opening.
iii.
iv.
Write ( ) function for inserting (writing) from the bottom of the empty
memory spaces in the buffer allocated to it.
192
EMBEDDED SYSTEMS
v.
Read ( ) function for deleting (reading) from the pipe from the bottom of
the unread memory spaces in the buffer filled after writing into the pipe.
vi.
Close ( ) for closing the device the enable its use from beginning of its
allocated buffer only after opening it again.
193
EMBEDDED SYSTEMS
Checksum is sum of the bytes to enable the checking of the erroneous data
transfer. For remote communication, the address, for example, IP address is
also required in the header.
2. There may be the need of using a connection-oriented protocol, for example,
TCP. Connection-oriented protocol means a protocol, which provides that
there must first a connection establishment between the source and
destination, and then the actual transfer of data stream can take place. At end,
there must be connection termination.
Socket provides a devices-like mechanism for bi-direction communication. It provides
for using a protocol between the source and destination processes for transferring the bytes; it
provides for establishing and closing a connection between the source and destination processes
using a protocol for transferring the bytes; it may provide for listening from multiple sources or
multicasting to multiple destinations. Two tasks at two distinct places are locally interconnect
through the sockets. Multiple tasks at multiple distinct places interconnect through the sockets to
a socket at a server process. The client and server sockets can run on the same CPU or at distant
CPUs on the Internet.
Sockets can be using different domain. For example, a socket domain can be TCP,
another socket domain may be UDP, the card and host example socket domains are different.
The use of a socket of IPC is analogous to the use of sockets for an Internet connection
between the browser and web server. A socket provides a bi-directional transfer of messages and
may also send protocol header. The transfer is between two or between the multiple clients and
server-process. Each socket may have the task source address (similar to a network or IP
address) and a port (similar to a process or thread) number. The source and destination sets of
tasks (addresses) may be on the same computer or on a network.
18. Describe the functions of an RTOS and when it is necessary.(April/May2012)(November-2011)(November-2012)
A Real-Time Operating System (RTOS) is a computing environment that reacts to input
within a specific time period. A real-time deadline can be so small that system reaction appears
instantaneous. The term real-time computing has also been used, however, to describe "slow
real-time" output that has a longer, but fixed, time limit.
194
EMBEDDED SYSTEMS
Time management
Task management
Interrupt handling
Memory management
Exception handling
Task synchronization
Task scheduling
Time management
A high resolution hardware timer is programmed to interrupt the processor at fixed rate
Time interrupt Each time interrupt is called a system tick (time resolution):
Normally, the tick can vary in microseconds (depend on hardware)
The tick may be selected by the user
All time parameters for tasks should be the multiple of the tick
System time = 32 bits
One tick = 1ms: your system can run 50 days
One tick = 20ms: your system can run 1000 days = 2.5 years
One tick = 50ms: your system can run 2500 days= 7 year
Time interrupt routine
Save the context of the task in execution
Increment the system time by 1, if current time > system lifetime, generate a timing error
Update timers(reduce each counter by 1)
A queue of timers
Activation of periodic tasks in idling state
Schedule again - call the scheduler
195
EMBEDDED SYSTEMS
The RTOS performs few tasks, thus ensuring that the tasks will always be executed before
the deadline
The RTOS drops or reduces certain functions when they cannot be executed within the time
constraints ("load shedding")
196
EMBEDDED SYSTEMS
The RTOS monitors resources and can interrupt background processes as needed to ensure
real-time execution
The RTOS anticipates potential requests and frees enough of the system to allow timely
reaction to the user's request
The RTOS keeps track of how much of each resource (CPU time per timeslice, RAM,
communications bandwidth, etc.) might possibly be used in the worst-case by the currentlyrunning tasks, and refuses to accept a new task unless it "fits" in the remaining un-allocated
resources.
197
EMBEDDED SYSTEMS
a) Then the ISR during execution then can post one or more outputs for the events and messages
into the mailboxes or queues.
b) The ISR must be short and it must simply puts post the messages for another task.
c)This task runs the remaining codes whenever it is scheduled.
d)RTOS schedules only the tasks (processes) and switches the contexts between the tasks only.
e)ISR executes only during a temporary suspension of a task.
QUESTION BANK
UNIT-IV
TWO MARKS
1. What is an rtos?
2. What are rtos basic services?( April-2013)
3. Why we need rtos?
4. What are the occasions where we no need rtos?
5.What are rtos task scheduling models?(April-2013)
6. What are the features of control flow strategy?
7. What are the features of data flow strategy?
8. What are the features of control data flow strategy?
9. What are basic functions of rtos?
198
EMBEDDED SYSTEMS
199
EMBEDDED SYSTEMS
200
EMBEDDED SYSTEMS
201
EMBEDDED SYSTEMS
202
EMBEDDED SYSTEMS
Prepared By :
Mr.P.Karthikeyan,AP/CSE
Mr.B.Thiyagarajan, AP/CSE
Mrs.P.Subha Priya, AP/CSE
Verified by :
Approved by :
UNIT V
Study of Micro C/OS-II or Vx Works: RTOS System Level Functions Task Service
Functions Time Delay Functions Memory Allocation Related Functions Semaphore
Related Functions Mailbox Related Functions Queue Related Functions Case
Studies of Programming with RTOS.
203
EMBEDDED SYSTEMS
Own RTOS
C/ OS-II
Vx Works
2. What is MUCOS?(November-2011)
C/OS-II is Free Open-source RTOS designed by Jean J. Labrosse in 1992.
C/OS-II is intended for Non-commercial use.
C/OS-II codes are in C and few CPU specific modules are in ASSY.
C/OS-II code Port on MANY Processors that are commonly used in ES design.
3. What are the various features of C/OS-II?
C/OS-II is a Scalable OS.
C/OS-II uses Pre-emptive Scheduler (for multitasking).
C/OS-II has System level functions.
C/OS-II has Task service functions.
C/OS-II has Task delay functions.
204
EMBEDDED SYSTEMS
Os_cfg.h
Os_tick.c
Os_cpu_c.c
Os_cpu-a.s12
205
Ucos.ii.h
Ucos.ii.c
Os_core.c
Os_time.c
Os_task.c
Os_mem.c
Os_sem.c
Os_q.c
EMBEDDED SYSTEMS
7. What is Vx Works?
VxWorks is a real-time operating system made and sold by Wind River Systems of
Alameda, California, USA. Intel acquired Wind River Systems on July 17, 2009. VxWorks is
designed for use in embedded systems. Unlike "self-hosting" systems such as Unix, VxWorks
development is done on a "host" machine running Linux, Unix, or Microsoft Windows, crosscompiling target software to run on various "target" CPU architectures.
8. What are the features of Vx Works?
The various features of Vx Works are as follows:
SCSI support
exception handling
symbolic debugging
message queues
Also vxworks has interrupt latency<4.33 microsecs while psos its higher.
Other
then
these
both
work
in
same
manner
and
follow
same
architecture.
206
EMBEDDED SYSTEMS
207
EMBEDDED SYSTEMS
208
EMBEDDED SYSTEMS
QS_KEY
WM_KEYUP,
WM_KEYDOWN,
WM_SYSKEYUP,
or
QS_MOUSE
WM_MOUSEMOVE
message
or
mouse-button
message
QS_MOUSEBUTTON
mouse-button
message
(WM_LBUTTONUP,
QS_POSTMESSAGE - A posted message (other than those listed here) is in the queue.
209
EMBEDDED SYSTEMS
210
EMBEDDED SYSTEMS
Multitasking
Interrupt handling
211
EMBEDDED SYSTEMS
there are no tasks pending on it, the message queue sends events to the registered task. To
request that the message queue stop sending events, the registered task calls msgQEvStop( )
24. How is the real time system are structured?
Real-time systems are often structured using a client-server model of tasks. In this model,
server tasks accept requests from client tasks to perform some service, and usually return a reply.
The requests and replies are usually made in the form of inter task messages.
25. How does the Vx Work Exception Handler works?
The default exception handler suspends the task that caused the exception, and saves the
state of the task at the point of the exception. The kernel and other tasks continue uninterrupted.
A description of the exception is transmitted to the Tornado development tools, which can be
used to examine the suspended task.
26. Comparison of taskLock( ) and intLock( )
When using taskLock( ), consider that it will not achieve mutual exclusion. Generally, if
interrupted by hardware, the system will eventually return to your task. However, if you block,
you lose task lockout. Thus, before you return from the routine, taskUnlock( ) should be called.
When a task is accessing a variable or data structure that is also accessed by an ISR, you
can use intLock( ) to achieve mutual exclusion. Using intLock( ) makes the operation "atomic"
in a single processor environment. It is best if the operation is kept minimal, meaning a few lines
of code and no function calls. If the call is too long, it can directly impact interrupt latency and
cause the system to become far less deterministic.
27. How is wind scheduler enabled and disabled?
The wind scheduler can be explicitly disabled and enabled on a per-task basis with the
routines taskLock( ) and taskUnlock( ). When a task disables the scheduler by calling
taskLock( ), no priority-based preemption can take place while that task is running.
212
EMBEDDED SYSTEMS
If the task explicitly blocks or suspends, the scheduler selects the next highest-priority
eligible task to execute. When the preemption-locked task unblocks and begins running again,
preemption is again disabled.
28. What are the routines that can be called by Task Switch Hooks?
vxLib - vxTas( )
213
EMBEDDED SYSTEMS
unsigned int OSTimeGet (void)To find present counts when system time is
read.
33.Define TCB?(April\May-2012)
A Process Control Block (PCB, also called Task Control Block or Task Struct) is a data
structure in the operating system kernel containing the information needed to manage a particular
process. The PCB is "the manifestation of a process in an operating system".
34.Goals of embedded software?
An embedded system is a computer system with a dedicated function within a larger mechanical
or electrical system, often with real-time computing constraints. It is embedded as part of a
complete device often including hardware and mechanical parts.
UNIT V
11MARKS
1. Explain the System-Level Functions in detail? (November-2011)
The system level functions are,
Void OSInit (void) - at the beginning prior to OS start ()
Void OSStart (void) - after OS Init () and task creating functions
Void OSTickInit (void) to initialize system timer ticks.
Void OSIntEnter (void) just after the start of ISR codes.
Void OSIntExit (void) before return form the ISR codes.
OS- enter- critical macro to disable all interrupts.
214
EMBEDDED SYSTEMS
the
system
clock
ticks
and
interrupts
at
regular
interval
as
per
215
EMBEDDED SYSTEMS
section. Its use is compulsory to let the OS kernel quit the section and enable the
interrupts to the system. It returns no parameter.
8. Locking OS scheduler. OSSschedlock () disables preemption by a higher-priority task.
This function inhibits preemption by higher-priority task, but does not interrupt. If an
interrupts occurs then locking enables return of OS control to that task, which executes
this functions. The control returns to the task after any ISR completes.
9. Unlocking OS scheduler. OSSchedUnlock () enables preemption by higher priority task.
Enables return of OS control to the high priority task after the execution of
OSSchedUnlock. In case of any interrupts occurring after executing OSSchedUnlock and
after the end of the ISR, the higher-priority task, which is ready will execute on return
from the ISR.
2. What are the Task Service Functions? Explain in detail?
These functions are used to create task, suspend and resume, and time settling and retrieving
functions.
Unsigned byte OS task create () must call before running a task.
Unsigned byte OS task suspend () - called for blocking a task.
Unsigned byte OS task resume () called for resuming a blocked task.
Void OS time set () = when system time is to be set.
Unsigned int OS time get (void) find present count when time is read.
216
EMBEDDED SYSTEMS
functions. Total number of tasks that MUCOS manages can be up to 64. Mucos task priority
is also the task identifier. There is no task ID-defining function in MUCOS because each task
has to be assigned a distinct priority.
If the maximum number if user tasks is eight, then OS_MAX_TASKS is 24 (including
eight system-level tasks and 8 lowest priority system-tasks), the priority must be set between
8 and 15, because MUCOS will assign priorities 16 to 23 to the 8 lowest priority system
level tasks. The priorities 0 to 7 or 16 to 23 will then be for MUCOS internal uses.
OS_LOWEST_PRIO and OS_MAX_TASKS are user-defined constants in preprocessor
codes that are needed for configuring the MUCOS for the user applications. Defining
unnecessarily 20 user tasks that are actually 4 task are created by the user is to be avoided
because more OS_MAX_TASKS means unnecessarily higher memory space allocation by
the system to the user tasks.
Tasks parameters passing PA:
a) *task pointer is a pointer to the codes of task being created.
b) *pmdata is pointer for and optional message data reference passed to the task. If
none, we assign it as NULL.
c) *taskStackPointer is a pointer to the stack of task being created.
d) taskPriority is a task priority and must be within 8 to 15, if macro
OS_LOWEST_PRIO sets the lowest priority equal to 23
Returning RA: The lowest priority of any task OS_LOWEST_PRIO is 23. For the
application program, task priority assigned must be wthin 8 to 15. The function
OSTaskCreate () returns the following:
i.
ii.
iii.
OS_PRIO_INVALID,
if
priority
value
that
passed
is
more
than
the
OS_PRIO_LOWEST;
iv.
OS_NO_MORE_TCB returns, when no more memory block for the task control is
available.
217
EMBEDDED SYSTEMS
A task can create other tasks, but an ISR is not allowed to create a task. An exemplary
use is in creating a task, Task1_connect, for a connection task. OSTaskCreate(Task1_connect,
void(*) 0, (void*)*Task1_connectstack[100],10)
Task parameter passed as arguments are as follows.
a) Task1_Connect, a pointer to the codes of Task1_Connect for task being created.
b) The pointer for an optional message data reference passed to task is NULL.
c) *Task1_Connect is a pointer to the stack of TASk1_Connect and it is given size = 100
addresses in the memory.
d) Taskpriority is task priority allotted at 10, the highest but two that can be allocated. It will
generate error parameters, OS_NO_ERR = true in case creation and exists.
OS_PRIO_INVALID
true,
if
passed
priority
parameter
is
higher
than
218
EMBEDDED SYSTEMS
resume and must be within 8 to 15 when OS_LOWEST_PRIO is 23 and number of usertasks =8.
Returning RC: the function OStaskResume () returns the OS_NO_ERR when the blocking
succeeds. OS_PRIO_INVALID, if priority value that passed is more than 23, the
OS_LOWEST_PRIO constant value. OS_TASK_RESUME_PRIO, if priority value that
passed already resumed. OS_TASK_NOT_SUSPENDED, if attempting to resume a not
suspended (blocked) task.
An exemplary use is in un=blocking Task1_Connect of priority = Task1_connect
_priority is as follows:
OSTaskResume (Task1_Connect_priority). Tasks parameter passed as arguments is 10, as
Task1_Connect_priority = 10. The following error parameter will be returned by the taskresuming function.
a) OS_NO_ERR = true, when the un-blocking succeeds and task of priority 8 reaches
the running state.
b) OS_PRIO_INVALID = false, as 8 is a valid priority and is not more than
OS_LOWEST_PRIO.
c) OS_LOWEST_PRIO = 23.
d) OS_TASK_RESUME_PRIO = false, as priority value that passed already resumed.
e) OS_TASK_NOT_SUSPENDED = false, when attempting to resume a task that was
not suspended.
4. Setting time is system clock. Function void OSTimeSet (unsigned int count) returns no
value. Passing parameter, PD as argument is given next.
219
EMBEDDED SYSTEMS
PD: It passes a 32-bit integer for the count (set the number of ticks for the current time that
will increment after each system clock tick in the system)
An exemplary use is a function OSTimeSet (to preset the time). The function OSTimeSet
(0) sets the present count =0. Caution: it is suggested that OSTimeSet function should be
used before the OSTickInit function and only once then never be used within a task function,
as some other functions that rely on the timer will malfunction. Let the OS timer clock count
continue to be used as in a free running counter. There is little need later on of using the set
time function. This is because at any instant, the time can be read using a get function and at
any other instant, it can be defined again by adding a value to this time.
5. Getting time of system clock. Function unsigned int OSTimeGet (void) returns current
number of ticks as and unsigned integer. The passing parameter as argument is none.
RE: Returns 32-bit integer, current number of ticks at the system clock.
3. Explain the Time Delay Functions in detail? (November-2011)(April/May-2012)
MUCOS time delay functions for the tasks are
Void OStimeDly () - to delay a task by count 1 value.
Unsigned byte OStimeDly resume () - to resume a task a preset delay.
Void OStimeDly HMSM () time delay to block a task.
1. Delaying by defining a time delay by number of clock ticks. Function void OSTimeDly
(unsigned short delaycount) delays task by (delayCount -1) ticks of system clock. It
returns no parameter.
Task parameter passing PF: a 16=bit integer, delay count, to delay a task at least till the
system clock count inputs(ticks) equals to (delayCount -1)+ count, where count is the present
number of ticks at system-clock.
An exemplary use as a function in a task is OSTimeDly (10,000). It delays that task for the
least 100000 ms if system clock ticks after every 10ms.
220
EMBEDDED SYSTEMS
OS_TIME_INVALID_MINUTES,
and
OS_TIME_INVALID_MILLI,
221
EMBEDDED SYSTEMS
if
the
Task parameter passed PH: (a) to (c) hr, mn, sec and ms are the delay times in hours,
minutes, seconds and milliseconds by which task delays before resuming.
An exemplary use is using OSTimeDlyHMSM (0, 0, 0, 999) function in the codes of a
task. It delayed that task by 9990ms. The function delayed that task for at least 10 ms if
system clock ticks after every 10ms. (if delay is defined as 9,000,000ms, the
OSTimeDlyResume shall not be able to resume this task when asked. Number of ticks
must be less than 65,535, which means maximum delay can be 655,350ms if system
clock ticks every 10ms.
222
EMBEDDED SYSTEMS
Task parameters passing PI: MEMTYPE is the data type according to the memory,
whether 16-bit or 32-bit CPU memory addresses are there. For example, 16=bit in
68HC11 and 8051.
i.
ii.
iii.
iv.
*memErr is a pointer of the address to hold the error codes. At the address
*memErr the following global error code variables change from false to true.
OS_NO_ERR = true when creation succeeds. OS_MEM_INVALID_BLKS =
true, when at least two blocks are not passed as arguments.
v.
vi.
ii.
The function OSMemGet ( ) passes the error code pointer *memErr so that later it
returns one of the following. OS_NO_ERR, when memory block returns to the
memory partition, or OS_MEM_FULL, when memory block cannot be put into the
memory partition as it is full.
223
EMBEDDED SYSTEMS
ii.
4. Putting a memory block into a partition. Function unsigned byte OSMemput (OS_MEM
*memCBPointer, void *memBlock) returns a memory block pointed by *memBlock,
which memory control block points by *memCBpointer.
Returning RL: The function OSMemPut ( ) returns error codes for one of the
following: either
i.
ii.
OS_MEM_FULL, when the memory block cannot be put into the memory
partition as it is full.
ii.
224
EMBEDDED SYSTEMS
225
EMBEDDED SYSTEMS
states. The tasks now become ready for running (they run if no other higher-priority task
is ready). The tasks also become ready after a predefined timeout. SemFlag or SemKey or
SemCount decrements and if it becomes 0 then it makes the semaphore pending again
and the other tasks using OSSemPend ( ) have to wait for its release.
Running RN: The function OSSemPend ( ) when a semaphore is pending, then suspends
till>0 (release) and decrements the semVal on unblocking that task SemVal = 1. The
following macros return true.
i.
ii.
OS_TIMEOUT returns true, if semaphore did not release(did not become >0)
during the ticks defined for the timeout.
iii.
iv.
ii.
Passes argument for the number of timer ticks for the timeout. Tasks unblocks
after the delay is equal to (timeout -1) ticks even when the semaphore is not
released. It prevents infinite wait. It must pass 0 if this provision is not used.
iii.
3. Check for availability of an IPC after a semaphore release. Function unsigned short
OSSemAccept (OS_Event *eventPointer) checks for a semaphore value at ECB and
whether it is greater than 0. An unassigned 16-bit value is retrieved and then
decremented.
226
EMBEDDED SYSTEMS
Returning RO: The function OSSemAccept ( ) decrements the semVal if>0 and returns
the pre decremented value as an unsigned 16-bit number. It returns 0 if semVal was 0 and
pending when posted (released). After this, the task codes run further.
Task parameter passing PO: The OS_Event *eventPointer for the ECB that associates
with semaphore, semVal.
4.
ii.
iii.
5. Retrieve the error information for a semaphore. Function unsigned byte OSSemQuery
(OS_EVENT *eventPointer, OS_SEM_DATA *SemData) puts the data values for the
semaphore at the pointer, SemData.
227
EMBEDDED SYSTEMS
Returning RQ: After the OSSemQuery ( ) runs the SemData function and gets the
OSCnt, which is the semaphore present value (count). The semdata also gets the list of
the tasks, which are waiting for the semaphore. The list is at pointers OSEvent
Tbl [ ] and OSEventGr. The semaphore error information parameters we can find on
running the macros, OS_NO_ERR and OS_ERR_EVENT_TYPE.
i.
ii.
Task parameters passing PQ: The function OSSwmQuery ( ) passes a pointer of the
semaphore created earlier at *eventPointer and a pointer of the data structure at *SemData
for that created semaphore.
6. Explain the Mailbox-Related Functions in detail? (April-2013)
Let there be a pointer *msg to the message to be sent in the mailbox, and another
*mboxPointer for the message sending event and retrieving the message itself. MUCOS
mailbox IPC functions for the task.
1. Creating a mailbox for an IPC. Function OS_Event *OSMboxCreate (void*msg) is for
creating and ECB and RTOS and thus initializing a pointer *mboxpointer to msg. The
msg pointer is NULL, if the created mailbox initialized as empty mailbox.
Task parameters passing M1:*msg is message pointer to which *mboxPointer will initialize.
For an IPC, sending the message-pointer *mboxPointer communicates the msg.
Returning M1: The function OSMboxCreate ( ) returns a pointer to the ECB at the MUCOS
and mboxPointer at ECB points to msg.
2. Check for availability of an IPC after a message at mailbox. Function void
*OSMboxAccept (OS_EVENT *mboxPointer) checks for a mailbox message at ECB at
mboxPointer (as event pointer). The pointer for the message msg returns from the
function, if message is available, mboxPointer not pointing to NULL but to the msg.
After returning, the mailbox empties, and mboxPointer will point to NULL on emptying
228
EMBEDDED SYSTEMS
The OS_Event *mboxPointer passes as a pointer to ECB that is associated with the
mailbox.
ii.
Passes argument timeout. This resumes that the blocked task after the delay is equal
to (timeout 1) count inputs (ticks) at the system-clock timer.
iii.
Passes reference *mboxErr, a pointer that will hold the error codes.
Returning M3: The function OSmboxPend checks as well as waits for the message at
*mboxPointer and the function returns msg. After returning, the mailbox empties. *mboxPointer
will later point to NULL, because mailbox empties. When message is not available, it suspends
the tasks and blocks as long as *msgpointer is not NULL. It returns NULL pointer if the message
is not available (msgPointer pointing to NULL). The following macros will the return true.
229
EMBEDDED SYSTEMS
i.
ii.
OS_TIMEOUT returns true, if mailbox message does not succeed during the
ticks defined for the timeout >0:
iii.
OS_ERR_PEND_ISR returns true, if this function call was from the ISR;
iv.
4. Send a message for an IPC through mailbox. Function unsigned byte OSMboxPost
(OS_EVENT *msgPointer, void *msg) sends mailbox message at ECB event pointer,
*msgPointer. The message sent is at msg, as well as at mboxPointer after the posting.
Task parameters passing M4: The OS_Event *msgPointer passes as a pointer to ECB that
associates with the message. The pointer msg passes to the mailbox address *msgPointer.
Returning M4: The function OSMboxPost ( ) sends the message and then returns the error
code on running the macros as follows:
i.
ii.
iii.
5. Finding mailbox data and retrieving the error information for a mailbox. Function
unsigned
byte
OSMboxQuery
(OS_EVENT
*msgPointer,
OS_MBOX_DATA
*mboxData) checks for a mailbox data and places that at mboxData. It also finds the error
information parameters, OS_NO_ERR_EVENT_TYPE for the ECB.
Task parameter passing M5: The function OSMboxQuery ( ) passes
i.
ii.
230
EMBEDDED SYSTEMS
message. The error code macro OS_NO_ERR returns true, when message querying succeeds or
OS_ERR_EVENT_TYPE returns true, if msgPointer does not point to mailbox type msg
7. What are the Queue-Related Functions? (April/May-2012)
The message pointers can be posted into a queue by the tasks either at the back as in a queue or
at the front as in a stack. A task can thus insert a given message for deleting either in the FIFO
mode or in the LIFO mode.
The post-front function enables insertion such that the waiting task does LIFO retrieval of the
message-pointer, hence of the message.
1. Creating a queue for an IPC. OS_Event QMsgPointer =OSQCreate (void **QTop,
unsigned short qsize) is used for creating an OSs ECB for the QTop and queue is an
array of pointersat QMsgPointer. The array size can be declared as maximum 65,535 (0 th
to 65,535th element). Initially, the array QMsgPointer points to NULL.
Task parameters passing R: The **QTop passes as pointer for an array of voids. The qsize is
the size of this array (number of message pointers that the queue can insert before a read is
within 0 and 65,535)
Returning R: The function OSQCreate ( ) returns a pointer to the ECB allocated to the
queue. It is an array of voids initially, NULL if none is available.
2. Waiting for an IPC message at a queue. Function void *OSQPend (OS_Event
*QMsgPointer, unsigned short timeout, unsigned byte *Qerr) checks if a queue has a
message pending at ECB QMagPointer (QMsgPointer is not pointing to NULL). The
message pointer points to the queue from (head) at the ECB for the queue defined by
QMsgPointer. It suspends the task if no message is pending [until either ticks of the
system timer]. The queue head pointer at the ECB will later increment to point to the next
message after returning the pointer for the message.
Returning S: The function returns pointer to a queue at ECB. It also returns the following on
running the Marcos as under:
231
EMBEDDED SYSTEMS
i.
ii.
OS_TIMEOUT returns true, if queue did not get the message during the ticks defined
by the timeout
iii.
OS_ERR_PEND_ISR returns true, if this function call was from the ISR
iv.
ii.
It passes 16-bit unsigned integer argument timeout. It resumes the task after
the delay equals (timeout -1) count inputs (ticks) at the system clock.
iii.
3. Emptying the queue and eliminating all the message pointers. Functions unsigned byte
*OSQFlush (OS_EVENT *QMsgPointer) checks if a queue has a message pending at
QMSgPointer (the queue between queue front pointer and queue back pointer at the ECB.
It returns an error codes and QMsgPointer at ECB. These will later point to NULL on
return from the function.
Task parameters passing T: The OS_Event *QMsgPointer passes as pointer to the ECB that
is associated with the queue.
Returning T: After the function OSQFlush ( ) executes, the error macros returns as follows:
OS_NO_Err returns true, if the message queue flush succeeds, or OS_EVENT_TYPE returns
true, if the message queue flush succeeds, or OS_ERR_EVENT_TYPE returns true, if
QMsgPointer is not pointing to the queue message queue.
4. Sending a message pointer to the queue. The function unsigned byte OSQPost
(OS_EVENT *QMsgPointer, void *QMsg) sends a pointer of the message *QMsg. The
message pointer QMsgPointer (queue tail pointer) points to the QMsg.
Task parameters passing T: The OS_EVENT *QMsgPointer passes as pointer to the ECB
that is associated with the queue tail.
232
EMBEDDED SYSTEMS
Returning U: After the function OSQPost ( ), the message pointer *QMsg is passes for the
message to *QMsgPointer and the erro macros return the error code as follows;
i.
ii.
iii.
OS_Q_FULL returns true, when queue message cannot be posted (Qsize cannot
exceed a limit set on creating the queue.
5. Sending a message pointer and inserting it at the queue front. The function unsigned byte
OSQPostFront (OS_EVENT*QMsgPointer, void *QMsg) sends QMsg pointer to the
queue, but it is at the queue front pointer in the ECB where pointer for QMSg now stores,
pushing other message pointers backwards.
Task parameters passing V: The OS_Event *QMsgPointer passes as pointer to the ECB that
is associated with the queue. The second argument is the message QMsg address that is the
queue front address.
Returning V: After the function OSQPostFront ( ) executes the following error macros
returns as under:
i.
OS_NO_ERR returns true, if the message at the queue front is placed successfully
ii.
iii.
OS_Q_FULL returns true, if qsize was declared n and queue had n message waiting
for the read.
6. Querying to find the message and error information for the queue ECB. This function
unsigned byte OSQQuery (OS_EVENT *QMsgPointer, OS_Q_DATA *QData) checks
for a queue data and places that QData. It also finds the error information parameters, on
executing the following macros: OS_NO_ERR and OS_ERR_EVENT_TYPE.
Task parameters passing X: The function OSQQuery passes
233
i.
ii.
EMBEDDED SYSTEMS
ii.
234
EMBEDDED SYSTEMS
the safety concerns and of the strict constraints on implementation costs. To demonstrate the
applicability of the design methodology and tools an industrially relevant design: an Engine
Control Unit for a commercial vehicle is tackled. The case study is relevant because it represents
an actual product and because of its complexity. In particular, we were able to compare the
results obtained with our design methodology with the present implementation showing its
advantages both in terms of performance and design time.
Specification of the ECU
An electronic Engine Control Unit (ECU) consists of a set of sensors which periodically
measure the engine status, an electronic unit which processes data coming from the sensors and
drives the actuators, and the actuators themselves which execute the commands received from
the control unit. A control strategy is implemented in the electronic unit to optimize the fuel
injection and ignition; in particular it should minimize fuel consumption, minimize emissions of
polluting substances and maximize torque and power, when possible. These requirements are
usually competing, so the algorithm must find the best compromise for each situation.
The two main tasks of an ECU are the control of injection and ignition. The control
specifications for these two tasks are as follows:
Injection: in order to burn completely and correctly the fuel, the ratio between the air and
the fuel which go into each piston should be kept constant and close to the value 14.7 (for a
gasoline engine). This is achieved by controlling the opening time of each injector.
Ignition: in order to give the fuel enough time to burn completely, the spark should be red
in advance with respect to the instant when the piston is at its highest point. This parameter also
a affects consumption and emissions, and it is basically computed from the engine RPM.
Both injection and ignition can be adapted dynamically with a very high precision, by
processing the inputs signals coming from the sensors.
235
EMBEDDED SYSTEMS
236
EMBEDDED SYSTEMS
237
EMBEDDED SYSTEMS
f) *pmdata is pointer for and optional message data reference passed to the task. If
none, we assign it as NULL.
g) *taskStackPointer is a pointer to the stack of task being created.
h) taskPriority is a task priority and must be within 8 to 15, if macro
OS_LOWEST_PRIO sets the lowest priority equal to 23
Returning RA: The lowest priority of any task OS_LOWEST_PRIO is 23. For the
application program, task priority assigned must be wthin 8 to 15. The function
OSTaskCreate () returns the following:
v.
vi.
vii.
OS_PRIO_INVALID,
if
priority
value
that
passed
is
more
than
the
OS_PRIO_LOWEST;
viii.
OS_NO_MORE_TCB returns, when no more memory block for the task control is
available.
A task can create other tasks, but an ISR is not allowed to create a task. An exemplary
true,
if
passed
priority
parameter
is
higher
than
238
EMBEDDED SYSTEMS
3.
4.
resume and must be within 8 to 15 when OS_LOWEST_PRIO is 23 and number of usertasks =8.
Returning RC: the function OStaskResume () returns the OS_NO_ERR when the blocking
succeeds. OS_PRIO_INVALID, if priority value that passed is more than 23, the
OS_LOWEST_PRIO constant value. OS_TASK_RESUME_PRIO, if priority value that
passed already resumed. OS_TASK_NOT_SUSPENDED, if attempting to resume a not
suspended (blocked) task.
239
EMBEDDED SYSTEMS
240
EMBEDDED SYSTEMS
10.
List
out
the
semaphore
related
functions
and
explain
them.(November-
2013)(November-2012)
When a semaphore created by OS and used a resources acquiring key, it must be initialized with
1 to indicate the resources is available.
MUCOS semaphore related functions for task are,
OS event OSSemCreate () to create and initialize a semaphore
Void OSSemPend () to ckeck whether a semaphore is pending.
Unsigned short OSSemAccept () to check whether sem val>0
Unsigned byte OSSemPort () if sem val=0 or more, increments and makes a semaphore
again not Pending.
Unsigned byte OS sem query () to get semaphore information.
When a semaphore created by this OS is used as a resource-acquiring key(as matex), the
semaphore value to start with is 1, which means that resource is available and 0 will mean not
available. When a value to start with = 0 or n when using the semaphore as event-signaling flag
or counting, respectively.
2. Creating a semaphore for the IPCs. Function OS_Event OSSemCreate (unsigned short
semval) is for creating an OSs ECB (Event Control Block) for an IPC with semval
returning a pointer, which points to the ECB. A semaphore creates and initializes with the
value =semval.
Returning RM: The function OSSemCreate ( ) returns a pointer *eventPointer for the ECB
allocated to the semaphore. Null if none available.
Task parameter passing PM: A semVal between 0 and 65535 is passed. For IPC as an
event-signaling flag, SemFlag must pass 0 and as a resource-acquiring key, SemKey must
pass 1. For IPC as a counting semaphore, SemCount must be either 0 or a count-value to be
passed in the beginning.
241
EMBEDDED SYSTEMS
3. Waiting for an IPC for semaphore release. Function void OSSemPend (OS_Event
*eventPointer, unsigned short timeout, unsigned byte *SemErrPointer) is for letting a
task wait till the release event of a semaphore: SemFlag or SemKey or SemCount. The
latter is at the ECB pointed by *eventPointer. SemFlag or SemKey or SemCount
becoming greater than 0 is and event that signals the release of the tasks in the waiting
states. The tasks now become ready for running (they run if no other higher-priority task
is ready). The tasks also become ready after a predefined timeout. SemFlag or SemKey or
SemCount decrements and if it becomes 0 then it makes the semaphore pending again
and the other tasks using OSSemPend ( ) have to wait for its release.
Running RN: The function OSSemPend ( ) when a semaphore is pending, then suspends
till>0 (release) and decrements the semVal on unblocking that task SemVal = 1. The
following macros return true.
v.
vi.
OS_TIMEOUT returns true, if semaphore did not release(did not become >0)
during the ticks defined for the timeout.
vii.
viii.
v.
Passes argument for the number of timer ticks for the timeout. Tasks unblocks
after the delay is equal to (timeout -1) ticks even when the semaphore is not
released. It prevents infinite wait. It must pass 0 if this provision is not used.
vi.
4. Check for availability of an IPC after a semaphore release. Function unsigned short
OSSemAccept (OS_Event *eventPointer) checks for a semaphore value at ECB and
242
EMBEDDED SYSTEMS
v.
vi.
243
EMBEDDED SYSTEMS
7. Retrieve the error information for a semaphore. Function unsigned byte OSSemQuery
(OS_EVENT *eventPointer, OS_SEM_DATA *SemData) puts the data values for the
semaphore at the pointer, SemData.
Returning RQ: After the OSSemQuery ( ) runs the SemData function and gets the
OSCnt, which is the semaphore present value (count). The semdata also gets the list of
the tasks, which are waiting for the semaphore. The list is at pointers OSEvent
Tbl [ ] and OSEventGr. The semaphore error information parameters we can find on
running the macros, OS_NO_ERR and OS_ERR_EVENT_TYPE.
iii.
iv.
Task parameters passing PQ: The function OSSwmQuery ( ) passes a pointer of the
semaphore created earlier at *eventPointer and a pointer of the data structure at *SemData
for that created semaphore.
11.Discuss the features of Vx works?(November-2012)
The features of Vx works are
244
EMBEDDED SYSTEMS
Intel, SuperH,
2.VxWorks RTOS Kernel
Supports open source Linux and TIPC (transparent inter process communication) protocol
3.Scalability
Configuration file includes the user definitions for the needed IPC functions needed
4. Hierarchical
kernel extendibility and interfaces hierarchy includes timers, signals, TCP/IP Sockets,
queuing functions library, NFS, RPCs, Berkeley Port and Sockets, Pipes, Unix
compatible loader, language interpreter, shell, debugging tools and linking loader for
Unix.
QUESTION BANK
UNIT 5
2 MARKS
245
EMBEDDED SYSTEMS
246
EMBEDDED SYSTEMS
247
EMBEDDED SYSTEMS
UNIT II
1. Discuss the arm architecture in detail (April 2013)[ref. Page no. :45]
2. What are the registers and memory access processes in ARM? [April 2013][Ref. Page
no.: 59]
3. How the data transferred in arm using instructions? [November 2012][Ref. Page no.: 64]
4. Classify the instructions set of arm and explain [April/May 2012][Ref. Page no.:73]
5. What is arm cache? [November 2012][Ref. Page no.: 84]
6. Explain arm bus in detail? [November 2012] [Ref. Page no.: 84]
7. Explain embedded systems with arm?[November 2011] [Ref. Page no.:45]
8. What are the serial bus protocols? [November 2014] [Ref. Page no.:86]
9. Explain the parallel bus protocols? [November 2011] [Ref. Page no.:93]
248
EMBEDDED SYSTEMS
UNIT III
1. Specify the C++ features that suits embedded program. [April/May 2014]
[Ref. Page No. :109]
2.Write short note on software tool for embedded program.[April/May 2014]
[Ref. Page No.:111]
3.Discuss in detail with multiprocessor system. [November 2011]
[Ref. Page No.:114]
4.Explain embedded software develop process and tools.(November 2011]
[Ref. Page No.:117]
UNIT IV
1. What is Preemptive Priority Based Scheduling and Explain Rate Monotonic Scheduling in
Detail? (April-2013)[Ref. Page No.: 161]
2. What Is Priority Inversions? (November-2011) [Ref. Page No.:163]
3. Explain Process Synchronization (November-2012) [Ref. Page No.: 173]
4. What is the Purpose of Mailbox in Real Time Operating Systems? (April/May-2012)
[Ref. Page No.:193]
5. Explain About the Virtual Socket? (April/May-2012) [Ref. Page No.: 190]
6. Describe the functions of an RTOS and when it is necessary.(April/May-2012)(November2011)(November-2012) [Ref. Page No.: 194]
7. How the interrupt handled by the RTOS?(April-2013) [Ref. Page No.: 197]
249
EMBEDDED SYSTEMS
UNIT V
1. Explain the System-Level Functions in detail? (November-2011) [Ref. Page No. :214]
2. Explain the Time Delay Functions in detail? (November-2011)(April/May-2012) [Ref. Page
No. : 220]
3. What are the Memory Allocation-Related functions? (April-2013) (April/May-2012[Ref.
Page No. : 222]
4.What are the Semaphore-Related Functions? (November-2012) [Ref. Page No. :224]
5. Explain the Mailbox-Related Functions in detail? (April-2013) [Ref. Page No. :228]
6. What are the Queue-Related Functions? (April/May-2012) [Ref. Page No. : 231]
7. Describe the task service functions with examples.(November-2013) [Ref. Page No. :236]
8. List out the semaphore related functions and explain them.(November-2013)(November2012) [Ref. Page No. :241]
9.Discuss the features of Vx works?(November-2012) [Ref. Page No. :244]
250
EMBEDDED SYSTEMS